diff --git a/src/assets/data/baselineProfiles/aws-rds-oracle-database-12c-stig-baseline.json b/src/assets/data/baselineProfiles/aws-rds-oracle-database-12c-stig-baseline.json index 42311126..2f04e0fe 100644 --- a/src/assets/data/baselineProfiles/aws-rds-oracle-database-12c-stig-baseline.json +++ b/src/assets/data/baselineProfiles/aws-rds-oracle-database-12c-stig-baseline.json @@ -20,24 +20,24 @@ "supports": [], "controls": [ { - "title": "The DBMS must provide a mechanism to automatically terminate accounts\n designated as temporary or emergency accounts after an organization-defined\n time period.", - "desc": "Temporary application accounts could ostensibly be used in the event\n of a vendor support visit where a support representative requires a temporary\n unique account in order to perform diagnostic testing or conduct some other\n support related activity. When these types of accounts are created, there is a\n risk that the temporary account may remain in place and active after the\n support representative has left.\n\n To address this, in the event temporary application accounts are required,\n the application must ensure accounts designated as temporary in nature shall\n automatically terminate these accounts after an organization-defined time\n period. Such a process and capability greatly reduces the risk that accounts\n will be misused, hijacked, or data compromised.\n\n Note that user authentication and account management should be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP. This requirement applies to cases where it is necessary to\n have accounts directly managed by Oracle.\n\n Temporary database accounts must be automatically terminated after an\n organization-defined time period in order to mitigate the risk of the account\n being used beyond its original purpose or timeframe.", + "title": "Recovery procedures and technical system features must exist to ensure\n recovery is done in a secure and verifiable manner.", + "desc": "Application recovery and reconstitution constitutes executing an\ninformation system contingency plan comprised of activities that restore\nessential missions and business functions.\n\n Database management systems and transaction-based processing systems are\nexamples of information systems that are transaction-based. Transaction\nrollback and transaction journaling are examples of mechanisms supporting\ntransaction recovery.\n\n A DBMS may be vulnerable to use of compromised data or other critical files\nduring recovery. Use of compromised files could introduce maliciously altered\napplication code, relaxed security settings or loss of data integrity. Where\navailable, DBMS mechanisms to ensure use of only trusted files can help protect\nthe database from this type of compromise during DBMS recovery.", "descriptions": { - "default": "Temporary application accounts could ostensibly be used in the event\n of a vendor support visit where a support representative requires a temporary\n unique account in order to perform diagnostic testing or conduct some other\n support related activity. When these types of accounts are created, there is a\n risk that the temporary account may remain in place and active after the\n support representative has left.\n\n To address this, in the event temporary application accounts are required,\n the application must ensure accounts designated as temporary in nature shall\n automatically terminate these accounts after an organization-defined time\n period. Such a process and capability greatly reduces the risk that accounts\n will be misused, hijacked, or data compromised.\n\n Note that user authentication and account management should be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP. This requirement applies to cases where it is necessary to\n have accounts directly managed by Oracle.\n\n Temporary database accounts must be automatically terminated after an\n organization-defined time period in order to mitigate the risk of the account\n being used beyond its original purpose or timeframe." + "default": "Application recovery and reconstitution constitutes executing an\ninformation system contingency plan comprised of activities that restore\nessential missions and business functions.\n\n Database management systems and transaction-based processing systems are\nexamples of information systems that are transaction-based. Transaction\nrollback and transaction journaling are examples of mechanisms supporting\ntransaction recovery.\n\n A DBMS may be vulnerable to use of compromised data or other critical files\nduring recovery. Use of compromised files could introduce maliciously altered\napplication code, relaxed security settings or loss of data integrity. Where\navailable, DBMS mechanisms to ensure use of only trusted files can help protect\nthe database from this type of compromise during DBMS recovery." }, "impact": 0.5, "refs": [], "tags": { - "gtitle": "SRG-APP-000024-DB-000003", - "gid": "V-61561", - "rid": "SV-76051r3_rule", - "stig_id": "O121-C2-002000", - "fix_id": "F-67477r1_fix", + "gtitle": "SRG-APP-000144-DB-000101", + "gid": "V-61689", + "rid": "SV-76179r1_rule", + "stig_id": "O121-C2-012000", + "fix_id": "F-67603r1_fix", "cci": [ - "CCI-000016" + "CCI-000553" ], "nist": [ - "AC-2 (2)", + "CP-10 (2)", "Rev_4" ], "false_negatives": null, @@ -50,35 +50,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "If the organization has a policy, consistently enforced,\n forbidding the creation of emergency or temporary accounts, this is not a\n finding.\n\n If all user accounts are authenticated by the OS or an enterprise-level\n authentication/access mechanism, and not by Oracle, this is not a finding.\n\n Check DBMS settings, OS settings, and/or enterprise-level authentication/access\n mechanisms settings to determine if the site utilizes a mechanism whereby\n temporary or emergency accounts can be terminated after an organization-defined\n time period. If not, this is a finding.\n\n Check the profiles to see what the password_life_time is set to in the table\n dba_profiles. The password_life_time is a value stored in the LIMIT column, and\n identified by the value PASSWORD_LIFE_TIME in the RESOURCE_NAME column.\n\n SQL>select\n profile,\n resource_name,\n resource_type,\n limit\n from dba_profiles\n where upper(resource_name) like 'PASSWORD_LIFE_TIME';\n\n Verify that the user in question is assigned to a profile with the\n PASSWORD_LIFE_TIME set to the amount of time the user is expected to be using\n the password. If not, this is a finding.", - "fix": "If using database mechanisms to satisfy this requirement, use a\n profile with a distinctive name (for example, TEMPORARY_USERS), so that\n temporary users can be easily identified. Whenever a temporary user account is\n created, assign it to this profile.\n\n Create a job to lock accounts under this profile that are more than n days old,\n where n is the organization-defined time period." + "check": "Review DBMS recovery procedures and technical system features\n to determine if mechanisms exist and are in place to specify use of trusted\n files during DBMS recovery.\n\n If recovery procedures do not exist or are not sufficient to ensure recovery is\n done in a secure and verifiable manner, this is a finding.\n\n If system features exist and are not employed or not employed sufficiently,\n this is a finding.\n\n If circumstances that can inhibit a trusted recovery are not documented and\n appropriate mitigating procedures have not been put in place, this is a finding.\n\n Review the database backup strategy with the system administrator. Consider\n using Oracle RMAN with an encrypted backup to insure the backed up files can be\n trusted not to be compromised.", + "fix": "Implement DBMS recovery procedures and employ technical system\n features to specify trusted files during DBMS recovery. Test the solution and\n review the site-specific criteria to ensure that the backup and recovery\n process uses trusted files.\n\n Ensure circumstances that can inhibit a trusted recovery are documented and\n appropriate mitigating procedures have been put in place.\n\n Oracle recommends using RMAN Backup and encrypting backup files. With\n encrypted files stored on a mount point with limited access, the integrity of\n the files can be trusted.\n\n - - - - -\n Notes on Oracle Backup and Recovery Solutions\n\n When implementing a backup and recovery strategy, have the following solutions\n available:\n\n -- Recovery Manager (RMAN)\n Recovery Manager is fully integrated with the Oracle database to perform a\n range of backup and recovery activities, including maintaining an RMAN\n repository of historical data about backups. Can access RMAN through the\n command line or through Oracle Enterprise Manager.\n\n -- User-managed backup and recovery\n In this solution, perform backup and recovery with a mixture of host operating\n system commands and SQL*Plus recovery commands. Responsible for determining all\n aspects of when and how backups and recovery are done.\n\n -- Media management\n If not wanting to use RMAN with an encrypted backup, consider configuring RMAN\n to make backups to a media manager. On most platforms, to back up to and\n restore from sequential media such as tape, must integrate a media manager with\n the Oracle database. Can use Oracle Secure Backup, which supports both database\n and file system backups to tape, as the media manager. See Oracle Secure Backup\n Administrator's Guide to learn how to set up RMAN for use specifically with\n Oracle Secure Backup.\n\n These solutions are supported by Oracle and are fully documented, but RMAN is\n the preferred solution for database backup and recovery. RMAN provides a common\n interface for backup tasks across different host operating systems and offers\n several backup techniques not available through user-managed methods.\n\n -- Incremental backups:\n An incremental backup stores only blocks changed since a previous backup.\n Thus, they provide more compact backups and faster recovery, thereby reducing\n the need to apply redo during data file media recovery. If enabling block\n change tracking, then can improve performance by avoiding full scans of every\n input data file. Can use the BACKUP INCREMENTAL command to perform incremental\n backups.\n\n -- Block media recovery:\n Can repair a data file with only a small number of corrupt data blocks without\n taking it off-line or restoring it from backup. Can use the RECOVER BLOCK\n command to perform block media recovery.\n\n -- Binary compression:\n A binary compression mechanism integrated into Oracle Database reduces the size\n of backups.\n\n -- Encrypted backups:\n RMAN uses backup encryption capabilities integrated into Oracle Database to\n store backup sets in an encrypted format. To create encrypted backups on disk,\n the database must use the Advanced Security Option. To create encrypted backups\n directly on tape, RMAN must use the Oracle Secure Backup SBT interface but does\n not require the Advanced Security Option.\n\n -- Automated database duplication:\n Easily creates a copy of the database, supporting various storage\n configurations, including direct duplication between ASM databases.\n\n -- Cross-platform data conversion:\n Whether using RMAN or user-managed methods, can supplement physical backups\n with logical backups of schema objects made with Data Pump Export utility. Can\n later use Data Pump Import to re-create data after restore and recovery.\n Logical backups are mostly beyond the scope of the backup and recovery\n documentation." }, - "code": "control 'V-61561' do\n title \"The DBMS must provide a mechanism to automatically terminate accounts\n designated as temporary or emergency accounts after an organization-defined\n time period.\"\n desc \"Temporary application accounts could ostensibly be used in the event\n of a vendor support visit where a support representative requires a temporary\n unique account in order to perform diagnostic testing or conduct some other\n support related activity. When these types of accounts are created, there is a\n risk that the temporary account may remain in place and active after the\n support representative has left.\n\n To address this, in the event temporary application accounts are required,\n the application must ensure accounts designated as temporary in nature shall\n automatically terminate these accounts after an organization-defined time\n period. Such a process and capability greatly reduces the risk that accounts\n will be misused, hijacked, or data compromised.\n\n Note that user authentication and account management should be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP. This requirement applies to cases where it is necessary to\n have accounts directly managed by Oracle.\n\n Temporary database accounts must be automatically terminated after an\n organization-defined time period in order to mitigate the risk of the account\n being used beyond its original purpose or timeframe.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000024-DB-000003'\n tag \"gid\": 'V-61561'\n tag \"rid\": 'SV-76051r3_rule'\n tag \"stig_id\": 'O121-C2-002000'\n tag \"fix_id\": 'F-67477r1_fix'\n tag \"cci\": ['CCI-000016']\n tag \"nist\": ['AC-2 (2)', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"If the organization has a policy, consistently enforced,\n forbidding the creation of emergency or temporary accounts, this is not a\n finding.\n\n If all user accounts are authenticated by the OS or an enterprise-level\n authentication/access mechanism, and not by Oracle, this is not a finding.\n\n Check DBMS settings, OS settings, and/or enterprise-level authentication/access\n mechanisms settings to determine if the site utilizes a mechanism whereby\n temporary or emergency accounts can be terminated after an organization-defined\n time period. If not, this is a finding.\n\n Check the profiles to see what the password_life_time is set to in the table\n dba_profiles. The password_life_time is a value stored in the LIMIT column, and\n identified by the value PASSWORD_LIFE_TIME in the RESOURCE_NAME column.\n\n SQL>select\n profile,\n resource_name,\n resource_type,\n limit\n from dba_profiles\n where upper(resource_name) like 'PASSWORD_LIFE_TIME';\n\n Verify that the user in question is assigned to a profile with the\n PASSWORD_LIFE_TIME set to the amount of time the user is expected to be using\n the password. If not, this is a finding.\"\n tag \"fix\": \"If using database mechanisms to satisfy this requirement, use a\n profile with a distinctive name (for example, TEMPORARY_USERS), so that\n temporary users can be easily identified. Whenever a temporary user account is\n created, assign it to this profile.\n\n Create a job to lock accounts under this profile that are more than n days old,\n where n is the organization-defined time period.\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n query = %{\n SELECT PROFILE, RESOURCE_NAME, LIMIT FROM DBA_PROFILES WHERE PROFILE =\n '%s' AND RESOURCE_NAME = 'PASSWORD_LIFE_TIME'\n }\n\n user_profiles = sql.query('SELECT profile FROM dba_users;').column('profile').uniq\n\n if user_profiles.empty?\n describe 'There are no oracle user profiles, therefore this control is N/A' do\n skip 'There are no oracle user profiles, therefore this control is N/A'\n end\n end\n\n if !user_profiles.empty?\n user_profiles.each do |profile|\n unless input('emergency_profile_list').include?(profile)\n \tdescribe \"The profile #{profile} \" do\n\t subject { profile }\n\t it \"should not be in the org-defined list of profiles for emergency or temporary account management\" do\n\t expect(subject).should_not be_in(input('emergency_profile_list')) \n\t end\n end\n\tnext\n end\n password_life_time = sql.query(format(query, profile: profile)).column('limit')\n\n describe \"The oracle database account password life time for profile: #{profile}\" do\n subject { password_life_time }\n it { should cmp <= input('password_life_time') }\n end\n end\n end\nend\n", + "code": "control 'V-61689' do\n title \"Recovery procedures and technical system features must exist to ensure\n recovery is done in a secure and verifiable manner.\"\n desc \"Application recovery and reconstitution constitutes executing an\ninformation system contingency plan comprised of activities that restore\nessential missions and business functions.\n\n Database management systems and transaction-based processing systems are\nexamples of information systems that are transaction-based. Transaction\nrollback and transaction journaling are examples of mechanisms supporting\ntransaction recovery.\n\n A DBMS may be vulnerable to use of compromised data or other critical files\nduring recovery. Use of compromised files could introduce maliciously altered\napplication code, relaxed security settings or loss of data integrity. Where\navailable, DBMS mechanisms to ensure use of only trusted files can help protect\nthe database from this type of compromise during DBMS recovery.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000144-DB-000101'\n tag \"gid\": 'V-61689'\n tag \"rid\": 'SV-76179r1_rule'\n tag \"stig_id\": 'O121-C2-012000'\n tag \"fix_id\": 'F-67603r1_fix'\n tag \"cci\": ['CCI-000553']\n tag \"nist\": ['CP-10 (2)', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Review DBMS recovery procedures and technical system features\n to determine if mechanisms exist and are in place to specify use of trusted\n files during DBMS recovery.\n\n If recovery procedures do not exist or are not sufficient to ensure recovery is\n done in a secure and verifiable manner, this is a finding.\n\n If system features exist and are not employed or not employed sufficiently,\n this is a finding.\n\n If circumstances that can inhibit a trusted recovery are not documented and\n appropriate mitigating procedures have not been put in place, this is a finding.\n\n Review the database backup strategy with the system administrator. Consider\n using Oracle RMAN with an encrypted backup to insure the backed up files can be\n trusted not to be compromised.\"\n tag \"fix\": \"Implement DBMS recovery procedures and employ technical system\n features to specify trusted files during DBMS recovery. Test the solution and\n review the site-specific criteria to ensure that the backup and recovery\n process uses trusted files.\n\n Ensure circumstances that can inhibit a trusted recovery are documented and\n appropriate mitigating procedures have been put in place.\n\n Oracle recommends using RMAN Backup and encrypting backup files. With\n encrypted files stored on a mount point with limited access, the integrity of\n the files can be trusted.\n\n - - - - -\n Notes on Oracle Backup and Recovery Solutions\n\n When implementing a backup and recovery strategy, have the following solutions\n available:\n\n -- Recovery Manager (RMAN)\n Recovery Manager is fully integrated with the Oracle database to perform a\n range of backup and recovery activities, including maintaining an RMAN\n repository of historical data about backups. Can access RMAN through the\n command line or through Oracle Enterprise Manager.\n\n -- User-managed backup and recovery\n In this solution, perform backup and recovery with a mixture of host operating\n system commands and SQL*Plus recovery commands. Responsible for determining all\n aspects of when and how backups and recovery are done.\n\n -- Media management\n If not wanting to use RMAN with an encrypted backup, consider configuring RMAN\n to make backups to a media manager. On most platforms, to back up to and\n restore from sequential media such as tape, must integrate a media manager with\n the Oracle database. Can use Oracle Secure Backup, which supports both database\n and file system backups to tape, as the media manager. See Oracle Secure Backup\n Administrator's Guide to learn how to set up RMAN for use specifically with\n Oracle Secure Backup.\n\n These solutions are supported by Oracle and are fully documented, but RMAN is\n the preferred solution for database backup and recovery. RMAN provides a common\n interface for backup tasks across different host operating systems and offers\n several backup techniques not available through user-managed methods.\n\n -- Incremental backups:\n An incremental backup stores only blocks changed since a previous backup.\n Thus, they provide more compact backups and faster recovery, thereby reducing\n the need to apply redo during data file media recovery. If enabling block\n change tracking, then can improve performance by avoiding full scans of every\n input data file. Can use the BACKUP INCREMENTAL command to perform incremental\n backups.\n\n -- Block media recovery:\n Can repair a data file with only a small number of corrupt data blocks without\n taking it off-line or restoring it from backup. Can use the RECOVER BLOCK\n command to perform block media recovery.\n\n -- Binary compression:\n A binary compression mechanism integrated into Oracle Database reduces the size\n of backups.\n\n -- Encrypted backups:\n RMAN uses backup encryption capabilities integrated into Oracle Database to\n store backup sets in an encrypted format. To create encrypted backups on disk,\n the database must use the Advanced Security Option. To create encrypted backups\n directly on tape, RMAN must use the Oracle Secure Backup SBT interface but does\n not require the Advanced Security Option.\n\n -- Automated database duplication:\n Easily creates a copy of the database, supporting various storage\n configurations, including direct duplication between ASM databases.\n\n -- Cross-platform data conversion:\n Whether using RMAN or user-managed methods, can supplement physical backups\n with logical backups of schema objects made with Data Pump Export utility. Can\n later use Data Pump Import to re-create data after restore and recovery.\n Logical backups are mostly beyond the scope of the backup and recovery\n documentation.\"\n describe 'A manual review is required to ensure recovery procedures and technical system features exist to ensure\n recovery is done in a secure and verifiable manner' do\n skip 'A manual review is required to ensure recovery procedures and technical system features exist to ensure\n recovery is done in a secure and verifiable manner'\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61561.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61689.rb", "line": 1 }, - "id": "V-61561" + "id": "V-61689" }, { - "title": "System privileges granted using the WITH ADMIN OPTION must not be\n granted to unauthorized user accounts.", - "desc": "The WITH ADMIN OPTION allows the grantee to grant a privilege to\n another database account. Best security practice restricts the privilege of\n assigning privileges to authorized personnel. Authorized personnel include\n DBAs, object owners, and, where designed and included in the application's\n functions, application administrators. Restricting privilege-granting functions\n to authorized accounts can help decrease mismanagement of privileges and\n wrongful assignments to unauthorized accounts.", + "title": "The system must protect audit tools from unauthorized modification.", + "desc": "Protecting audit data also includes identifying and protecting the\n tools used to view and manipulate log data.\n\n Depending upon the log format and application, system and application log\n tools may provide the only means to manipulate and manage application and\n system log data.\n\n If the tools are compromised it could provide attackers with the capability\n to manipulate log data. It is, therefore, imperative that audit tools be\n controlled and protected from unauthorized modification.\n\n Audit tools include, but are not limited to, OS provided audit tools,\n vendor provided audit tools, and open source audit tools needed to successfully\n view and manipulate audit information system activity and records.\n\n If an attacker were to gain access to audit tools he could analyze audit\n logs for system weaknesses or weaknesses in the auditing itself. An attacker\n could also manipulate logs to hide evidence of malicious activity.", "descriptions": { - "default": "The WITH ADMIN OPTION allows the grantee to grant a privilege to\n another database account. Best security practice restricts the privilege of\n assigning privileges to authorized personnel. Authorized personnel include\n DBAs, object owners, and, where designed and included in the application's\n functions, application administrators. Restricting privilege-granting functions\n to authorized accounts can help decrease mismanagement of privileges and\n wrongful assignments to unauthorized accounts." + "default": "Protecting audit data also includes identifying and protecting the\n tools used to view and manipulate log data.\n\n Depending upon the log format and application, system and application log\n tools may provide the only means to manipulate and manage application and\n system log data.\n\n If the tools are compromised it could provide attackers with the capability\n to manipulate log data. It is, therefore, imperative that audit tools be\n controlled and protected from unauthorized modification.\n\n Audit tools include, but are not limited to, OS provided audit tools,\n vendor provided audit tools, and open source audit tools needed to successfully\n view and manipulate audit information system activity and records.\n\n If an attacker were to gain access to audit tools he could analyze audit\n logs for system weaknesses or weaknesses in the auditing itself. An attacker\n could also manipulate logs to hide evidence of malicious activity." }, "impact": 0, "refs": [], "tags": { - "gtitle": "SRG-APP-000516-DB-999900", - "gid": "V-61433", - "rid": "SV-75923r3_rule", - "stig_id": "O121-BP-022300", - "fix_id": "F-67349r1_fix", + "gtitle": "SRG-APP-000122-DB-000203", + "gid": "V-61661", + "rid": "SV-76151r1_rule", + "stig_id": "O121-C2-009700", + "fix_id": "F-67575r1_fix", "cci": [ - "CCI-000366" + "CCI-001494" ], "nist": [ - "CM-6 b", + "AU-9", "Rev_4" ], "false_negatives": null, @@ -91,35 +91,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "A default Oracle Database installation provides a set of\n predefined administrative accounts and non-administrative accounts. These are\n accounts that have special privileges required to administer areas of the\n database, such as the CREATE ANY TABLE or ALTER SESSION privilege, or EXECUTE\n privileges on packages owned by the SYS schema. The default tablespace for\n administrative accounts is either SYSTEM or SYSAUX. Non-administrative user\n accounts only have the minimum privileges needed to perform their jobs. Their\n default tablespace is USERS.\n\n To protect these accounts from unauthorized access, the installation process\n expires and locks most of these accounts, except where noted below. The\n database administrator is responsible for unlocking and resetting these\n accounts, as required.\n\n Non-Administrative Accounts - Expired and locked:\n APEX_PUBLIC_USER, DIP, FLOWS_040100*, FLOWS_FILES, MDDATA, ORACLE_OCM,\n SPATIAL_CSW_ADMIN_USR, SPATIAL_WFS_ADMIN_USR, XS$NULL\n\n Administrative Accounts - Expired and Locked:\n ANONYMOUS, CTXSTS, EXFSYS, LBACSYS, MDSYS, OLAPSYS, OEDDATA, OWBSYS,\n ORDPLUGINS, ORDSYS, OUTLN, SI_INFORMTN_SCHEMA, WK_TEST, WK_SYS, WKPROXY, WMSYS,\n XDB\n\n Administrative Accounts - Open:\n DBSNMP, MGMT_VIEW, SYS, SYSMAN, SYSTEM, SYSKM\n\n * Subject to change based on version installed\n\n Run the SQL query:\n\n From SQL*Plus:\n select grantee, privilege from dba_sys_privs\n where grantee not in ()\n and admin_option = 'YES'\n and 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\n requirement, it is expected that the DBA will maintain the list to suit local\n circumstances, adding special accounts as necessary and removing any that are\n not supposed to be in use in the Oracle deployment that is under review.)\n\n If any accounts that are not authorized to have the ADMIN OPTION are listed,\n this is a finding.", - "fix": "Revoke assignment of privileges with the WITH ADMIN OPTION from\n unauthorized users and re-grant them without the option.\n\n From SQL*Plus:\n\n revoke [privilege name] from user [username];\n\n Replace [privilege name] with the named privilege and [username] with the named\n user.\n\n Restrict use of the WITH ADMIN OPTION to authorized administrators.\n\n Document authorized privilege assignments with the WITH ADMIN OPTION in the\n System Security Plan." + "check": "Review access permissions to tools used to view or modify audit\n log data. These tools may include the DBMS itself or tools external to the\n database.\n\n If appropriate permissions and access controls are not applied to prevent\n unauthorized modification of these tools, this is a finding.", + "fix": "Add or modify access controls and permissions to tools used to\n view or modify audit log data. Tools must be modifiable by authorized personnel\n only." }, - "code": "control 'V-61433' do\n title \"System privileges granted using the WITH ADMIN OPTION must not be\n granted to unauthorized user accounts.\"\n desc \"The WITH ADMIN OPTION allows the grantee to grant a privilege to\n another database account. Best security practice restricts the privilege of\n assigning privileges to authorized personnel. Authorized personnel include\n DBAs, object owners, and, where designed and included in the application's\n functions, application administrators. Restricting privilege-granting functions\n to authorized accounts can help decrease mismanagement of privileges and\n wrongful assignments to unauthorized accounts.\"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000516-DB-999900'\n tag \"gid\": 'V-61433'\n tag \"rid\": 'SV-75923r3_rule'\n tag \"stig_id\": 'O121-BP-022300'\n tag \"fix_id\": 'F-67349r1_fix'\n tag \"cci\": ['CCI-000366']\n tag \"nist\": ['CM-6 b', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"A default Oracle Database installation provides a set of\n predefined administrative accounts and non-administrative accounts. These are\n accounts that have special privileges required to administer areas of the\n database, such as the CREATE ANY TABLE or ALTER SESSION privilege, or EXECUTE\n privileges on packages owned by the SYS schema. The default tablespace for\n administrative accounts is either SYSTEM or SYSAUX. Non-administrative user\n accounts only have the minimum privileges needed to perform their jobs. Their\n default tablespace is USERS.\n\n To protect these accounts from unauthorized access, the installation process\n expires and locks most of these accounts, except where noted below. The\n database administrator is responsible for unlocking and resetting these\n accounts, as required.\n\n Non-Administrative Accounts - Expired and locked:\n APEX_PUBLIC_USER, DIP, FLOWS_040100*, FLOWS_FILES, MDDATA, ORACLE_OCM,\n SPATIAL_CSW_ADMIN_USR, SPATIAL_WFS_ADMIN_USR, XS$NULL\n\n Administrative Accounts - Expired and Locked:\n ANONYMOUS, CTXSTS, EXFSYS, LBACSYS, MDSYS, OLAPSYS, OEDDATA, OWBSYS,\n ORDPLUGINS, ORDSYS, OUTLN, SI_INFORMTN_SCHEMA, WK_TEST, WK_SYS, WKPROXY, WMSYS,\n XDB\n\n Administrative Accounts - Open:\n DBSNMP, MGMT_VIEW, SYS, SYSMAN, SYSTEM, SYSKM\n\n * Subject to change based on version installed\n\n Run the SQL query:\n\n From SQL*Plus:\n select grantee, privilege from dba_sys_privs\n where grantee not in ()\n and admin_option = 'YES'\n and 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\n requirement, it is expected that the DBA will maintain the list to suit local\n circumstances, adding special accounts as necessary and removing any that are\n not supposed to be in use in the Oracle deployment that is under review.)\n\n If any accounts that are not authorized to have the ADMIN OPTION are listed,\n this is a finding.\"\n tag \"fix\": \"Revoke assignment of privileges with the WITH ADMIN OPTION from\n unauthorized users and re-grant them without the option.\n\n From SQL*Plus:\n\n revoke [privilege name] from user [username];\n\n Replace [privilege name] with the named privilege and [username] with the named\n user.\n\n Restrict use of the WITH ADMIN OPTION to authorized administrators.\n\n Document authorized privilege assignments with the WITH ADMIN OPTION in the\n System Security Plan.\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n dba_users = sql.query(\"select grantee from dba_sys_privs\n where admin_option = 'YES' and grantee not in (select grantee from dba_role_privs where granted_role = 'DBA');\").column('grantee').uniq\n if dba_users.empty?\n impact 0.0\n describe 'There are no oracle DBA users, control N/A' do\n skip 'There are no oracle DBA users, control N/A'\n end\n else\n dba_users.each do |user|\n describe \"oracle DBA users: #{user}\" do\n subject { user }\n it { should be_in input('allowed_dbadmin_users') }\n end\n end\n end\nend\n", + "code": "control 'V-61661' do\n title 'The system must protect audit tools from unauthorized modification.'\n desc \"Protecting audit data also includes identifying and protecting the\n tools used to view and manipulate log data.\n\n Depending upon the log format and application, system and application log\n tools may provide the only means to manipulate and manage application and\n system log data.\n\n If the tools are compromised it could provide attackers with the capability\n to manipulate log data. It is, therefore, imperative that audit tools be\n controlled and protected from unauthorized modification.\n\n Audit tools include, but are not limited to, OS provided audit tools,\n vendor provided audit tools, and open source audit tools needed to successfully\n view and manipulate audit information system activity and records.\n\n If an attacker were to gain access to audit tools he could analyze audit\n logs for system weaknesses or weaknesses in the auditing itself. An attacker\n could also manipulate logs to hide evidence of malicious activity.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000122-DB-000203'\n tag \"gid\": 'V-61661'\n tag \"rid\": 'SV-76151r1_rule'\n tag \"stig_id\": 'O121-C2-009700'\n tag \"fix_id\": 'F-67575r1_fix'\n tag \"cci\": ['CCI-001494']\n tag \"nist\": ['AU-9', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Review access permissions to tools used to view or modify audit\n log data. These tools may include the DBMS itself or tools external to the\n database.\n\n If appropriate permissions and access controls are not applied to prevent\n unauthorized modification of these tools, this is a finding.\"\n tag \"fix\": \"Add or modify access controls and permissions to tools used to\n view or modify audit log data. Tools must be modifiable by authorized personnel\n only.\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n users_allowed_access_to_audit_info = sql.query(\"SELECT GRANTEE, TABLE_NAME, PRIVILEGE\n FROM DBA_TAB_PRIVS where owner='AUDSYS';\").column('grantee').uniq\n if users_allowed_access_to_audit_info.empty?\n impact 0.0\n describe 'There are no oracle users allowed access to audit information, control N/A' do\n skip 'There are no oracle users allowed access to audit information'\n end\n else\n users_allowed_access_to_audit_info.each do |user|\n describe \"oracle users: #{user} allowed access to audit information\" do\n subject { user }\n it { should be_in input('allowed_audit_users') }\n end\n end\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61433.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61661.rb", "line": 1 }, - "id": "V-61433" + "id": "V-61661" }, { - "title": "A minimum of two Oracle redo log groups/files must be defined and\n configured to be stored on separate, archived physical disks or archived\n directories on a RAID device.", - "desc": "The Oracle redo log files store the detailed information on changes\n made to the database. This information is critical to database recovery in case\n of a database failure.", + "title": "The DBMS must automatically audit account creation.", + "desc": "Once an attacker establishes initial access to a system, they often\n attempt to create a persistent method of re-establishing access. One way to\n accomplish this is for the attacker to simply create a new account.\n\n Auditing of account creation is one method and best practice for mitigating\n this risk. A comprehensive account management process will ensure an audit\n trail documents the creation of application user accounts and, as required,\n notifies administrators and/or application owners that they exist. Such a\n process greatly reduces the risk that accounts will be surreptitiously created\n and provides logging that can be used for forensic purposes.\n\n Note that user authentication and account management should be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP.\n\n However, notwithstanding how accounts are managed, Oracle auditing should\n always be configured to capture account creation.", "descriptions": { - "default": "The Oracle redo log files store the detailed information on changes\n made to the database. This information is critical to database recovery in case\n of a database failure." + "default": "Once an attacker establishes initial access to a system, they often\n attempt to create a persistent method of re-establishing access. One way to\n accomplish this is for the attacker to simply create a new account.\n\n Auditing of account creation is one method and best practice for mitigating\n this risk. A comprehensive account management process will ensure an audit\n trail documents the creation of application user accounts and, as required,\n notifies administrators and/or application owners that they exist. Such a\n process greatly reduces the risk that accounts will be surreptitiously created\n and provides logging that can be used for forensic purposes.\n\n Note that user authentication and account management should be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP.\n\n However, notwithstanding how accounts are managed, Oracle auditing should\n always be configured to capture account creation." }, "impact": 0.5, "refs": [], "tags": { - "gtitle": "SRG-APP-000516-DB-999900", - "gid": "V-61419", - "rid": "SV-75909r1_rule", - "stig_id": "O121-BP-021600", - "fix_id": "F-67335r1_fix", + "gtitle": "SRG-APP-000026-DB-000005", + "gid": "V-61565", + "rid": "SV-76055r2_rule", + "stig_id": "O121-C2-002200", + "fix_id": "F-67481r2_fix", "cci": [ - "CCI-000366" + "CCI-000018" ], "nist": [ - "CM-6 b", + "AC-2 (4)", "Rev_4" ], "false_negatives": null, @@ -132,35 +132,39 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "From SQL*Plus:\n\n select count(*) from V$LOG;\n\n If the value of the count returned is less than 2, this is a finding.\n\n From SQL*Plus:\n\n select count(*) from V$LOG where members > 1;\n\n If the value of the count returned is less than 2 and a RAID storage device is\n not being used, this is a finding.", - "fix": "To define additional redo log file groups:\n\n From SQL*Plus (Example):\n\n alter database add logfile group 2\n ('diska:log2.log' ,\n 'diskb:log2.log') size 50K;\n\n To add additional redo log file [members] to an existing redo log file group:\n\n From SQL*Plus (Example):\n\n alter database add logfile member 'diskc:log2.log'\n to group 2;\n\n Replace diska, diskb, diskc with valid, different disk drive specifications.\n\n Replace log#.log file with valid or custom names for the log files." + "check": "Check Oracle settings (and also OS settings and/or\n enterprise-level authentication/access mechanisms settings) to determine if\n account creation is being audited. If account creation is not being audited by\n Oracle, this is a finding.\n\n If Standard Auditing is used:\n To see if Oracle is configured to capture audit data, enter the following\n SQL*Plus command:\n SHOW PARAMETER AUDIT_TRAIL\n or the following SQL query:\n SELECT * FROM SYS.V$PARAMETER WHERE NAME = 'audit_trail';\n If Oracle returns the value 'NONE', this is a finding.\n\n If Unified Auditing is used:\n To see if Oracle is configured to capture audit data including account\n creation, enter the following SQL*Plus command:\n SELECT ' Account creation is not being audited. '\n FROM dual\n WHERE (SELECT Count(*)\n FROM (select policy_name , audit_option from audit_unified_policies\n WHERE audit_option = 'CREATE USER'\n and policy_name in (select policy_name from\n audit_unified_enabled_policies where user_name='ALL USERS'))) = 0\n OR (SELECT value\n FROM v$option\n WHERE parameter = 'Unified Auditing') != 'TRUE';\n\n If Oracle returns \"no rows selected\", this is not a finding.", + "fix": "Configure Oracle to audit account creation activities.\n\n If Standard Auditing is used:\n Use this process to ensure auditable events are captured:\n ALTER SYSTEM SET AUDIT_TRAIL= SCOPE=SPFILE;\n Audit trail type can be 'OS', 'DB', 'DB,EXTENDED', 'XML' or 'XML,EXTENDED'.\n After executing this statement, it may be necessary to shut down and restart\n the Oracle database.\n\n If Unified Auditing is used:\n To ensure auditable events are captured:\n Link the oracle binary with uniaud_on, and then restart the database. Oracle\n Database Upgrade Guide describes how to enable unified auditing. Reference\n V-61625 for information on how to configure a policy to audit account creation.\n\n For more information on the configuration of auditing, refer to the following\n documents:\n \"Auditing Database Activity\" in the Oracle Database 2 Day + Security Guide:\n http://docs.oracle.com/database/121/TDPSG/tdpsg_auditing.htm#TDPSG50000\n \"Monitoring Database Activity with Auditing\" in the Oracle Database Security\n Guide:\n http://docs.oracle.com/database/121/DBSEG/part_6.htm#CCHEHCGI\n \"DBMS_AUDIT_MGMT\" in the Oracle Database PL/SQL Packages and Types Reference:\n http://docs.oracle.com/database/121/ARPLS/d_audit_mgmt.htm#ARPLS241\n Oracle Database Upgrade Guide:\n http://docs.oracle.com/database/121/UPGRD/afterup.htm#UPGRD52810" }, - "code": "control 'V-61419' do\n title \"A minimum of two Oracle redo log groups/files must be defined and\n configured to be stored on separate, archived physical disks or archived\n directories on a RAID device.\"\n desc \"The Oracle redo log files store the detailed information on changes\n made to the database. This information is critical to database recovery in case\n of a database failure.\"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000516-DB-999900'\n tag \"gid\": 'V-61419'\n tag \"rid\": 'SV-75909r1_rule'\n tag \"stig_id\": 'O121-BP-021600'\n tag \"fix_id\": 'F-67335r1_fix'\n tag \"cci\": ['CCI-000366']\n tag \"nist\": ['CM-6 b', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"From SQL*Plus:\n\n select count(*) from V$LOG;\n\n If the value of the count returned is less than 2, this is a finding.\n\n From SQL*Plus:\n\n select count(*) from V$LOG where members > 1;\n\n If the value of the count returned is less than 2 and a RAID storage device is\n not being used, this is a finding.\"\n tag \"fix\": \"To define additional redo log file groups:\n\n From SQL*Plus (Example):\n\n alter database add logfile group 2\n ('diska:log2.log' ,\n 'diskb:log2.log') size 50K;\n\n To add additional redo log file [members] to an existing redo log file group:\n\n From SQL*Plus (Example):\n\n alter database add logfile member 'diskc:log2.log'\n to group 2;\n\n Replace diska, diskb, diskc with valid, different disk drive specifications.\n\n Replace log#.log file with valid or custom names for the log files.\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n describe sql.query('select count(*) from V$LOG;').column('count(*)') do\n it { should cmp >= 2 }\n end\nend\n", + "code": "control 'V-61565' do\n title 'The DBMS must automatically audit account creation.'\n desc \"Once an attacker establishes initial access to a system, they often\n attempt to create a persistent method of re-establishing access. One way to\n accomplish this is for the attacker to simply create a new account.\n\n Auditing of account creation is one method and best practice for mitigating\n this risk. A comprehensive account management process will ensure an audit\n trail documents the creation of application user accounts and, as required,\n notifies administrators and/or application owners that they exist. Such a\n process greatly reduces the risk that accounts will be surreptitiously created\n and provides logging that can be used for forensic purposes.\n\n Note that user authentication and account management should be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP.\n\n However, notwithstanding how accounts are managed, Oracle auditing should\n always be configured to capture account creation.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000026-DB-000005'\n tag \"gid\": 'V-61565'\n tag \"rid\": 'SV-76055r2_rule'\n tag \"stig_id\": 'O121-C2-002200'\n tag \"fix_id\": 'F-67481r2_fix'\n tag \"cci\": ['CCI-000018']\n tag \"nist\": ['AC-2 (4)', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Check Oracle settings (and also OS settings and/or\n enterprise-level authentication/access mechanisms settings) to determine if\n account creation is being audited. If account creation is not being audited by\n Oracle, this is a finding.\n\n If Standard Auditing is used:\n To see if Oracle is configured to capture audit data, enter the following\n SQL*Plus command:\n SHOW PARAMETER AUDIT_TRAIL\n or the following SQL query:\n SELECT * FROM SYS.V$PARAMETER WHERE NAME = 'audit_trail';\n If Oracle returns the value 'NONE', this is a finding.\n\n If Unified Auditing is used:\n To see if Oracle is configured to capture audit data including account\n creation, enter the following SQL*Plus command:\n SELECT ' Account creation is not being audited. '\n FROM dual\n WHERE (SELECT Count(*)\n FROM (select policy_name , audit_option from audit_unified_policies\n WHERE audit_option = 'CREATE USER'\n and policy_name in (select policy_name from\n audit_unified_enabled_policies where user_name='ALL USERS'))) = 0\n OR (SELECT value\n FROM v$option\n WHERE parameter = 'Unified Auditing') != 'TRUE';\n\n If Oracle returns \\\"no rows selected\\\", this is not a finding.\"\n tag \"fix\": \"Configure Oracle to audit account creation activities.\n\n If Standard Auditing is used:\n Use this process to ensure auditable events are captured:\n ALTER SYSTEM SET AUDIT_TRAIL= SCOPE=SPFILE;\n Audit trail type can be 'OS', 'DB', 'DB,EXTENDED', 'XML' or 'XML,EXTENDED'.\n After executing this statement, it may be necessary to shut down and restart\n the Oracle database.\n\n If Unified Auditing is used:\n To ensure auditable events are captured:\n Link the oracle binary with uniaud_on, and then restart the database. Oracle\n Database Upgrade Guide describes how to enable unified auditing. Reference\n V-61625 for information on how to configure a policy to audit account creation.\n\n For more information on the configuration of auditing, refer to the following\n documents:\n \\\"Auditing Database Activity\\\" in the Oracle Database 2 Day + Security Guide:\n http://docs.oracle.com/database/121/TDPSG/tdpsg_auditing.htm#TDPSG50000\n \\\"Monitoring Database Activity with Auditing\\\" in the Oracle Database Security\n Guide:\n http://docs.oracle.com/database/121/DBSEG/part_6.htm#CCHEHCGI\n \\\"DBMS_AUDIT_MGMT\\\" in the Oracle Database PL/SQL Packages and Types Reference:\n http://docs.oracle.com/database/121/ARPLS/d_audit_mgmt.htm#ARPLS241\n Oracle Database Upgrade Guide:\n http://docs.oracle.com/database/121/UPGRD/afterup.htm#UPGRD52810\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n standard_auditing_used = input('standard_auditing_used')\n unified_auditing_used = input('unified_auditing_used')\n\n describe.one do\n describe 'Standard auditing is in use for audit purposes' do\n subject { standard_auditing_used }\n it { should be true }\n end\n\n describe 'Unified auditing is in use for audit purposes' do\n subject { unified_auditing_used }\n it { should be true }\n end\n end\n\n audit_trail = sql.query(\"select value from v$parameter where name = 'audit_trail';\").column('value')\n\n if standard_auditing_used\n describe 'The oracle database audit_trail parameter' do\n subject { audit_trail }\n it { should_not cmp 'NONE' }\n end\n end\n\n unified_auditing = sql.query(\"SELECT value FROM V$OPTION WHERE PARAMETER = 'Unified Auditing';\").column('value')\n\n if unified_auditing_used\n describe 'The oracle database unified auditing parameter' do\n subject { unified_auditing }\n it { should_not cmp 'FALSE' }\n end\n\n unified_auditing_events = sql.query(\"SELECT ' Account creation is not being audited. '\n FROM dual\n WHERE (SELECT Count(*)\n FROM (select policy_name , audit_option from audit_unified_policies\n WHERE audit_option = 'CREATE USER'\n and policy_name in (select policy_name from\n audit_unified_enabled_policies where user_name='ALL USERS'))) = 0\n OR (SELECT value\n FROM v$option\n WHERE parameter = 'Unified Auditing') != 'TRUE';\").column('Account creation is not being audited.').uniq\n\n describe 'The unified auditing data capture for account creation' do\n subject { unified_auditing_events.to_s }\n it { should_not cmp '[nil]' }\n end\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61419.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61565.rb", "line": 1 }, - "id": "V-61419" + "id": "V-61565" }, { - "title": "The DBMS must automatically audit account creation.", - "desc": "Once an attacker establishes initial access to a system, they often\n attempt to create a persistent method of re-establishing access. One way to\n accomplish this is for the attacker to simply create a new account.\n\n Auditing of account creation is one method and best practice for mitigating\n this risk. A comprehensive account management process will ensure an audit\n trail documents the creation of application user accounts and, as required,\n notifies administrators and/or application owners that they exist. Such a\n process greatly reduces the risk that accounts will be surreptitiously created\n and provides logging that can be used for forensic purposes.\n\n Note that user authentication and account management should be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP.\n\n However, notwithstanding how accounts are managed, Oracle auditing should\n always be configured to capture account creation.", + "title": "Access to external executables must be disabled or restricted.", + "desc": "The Oracle external procedure capability provides use of the Oracle\n process account outside the operation of the DBMS process. You can use it to\n submit and execute applications stored externally from the database under\n operating system controls. The external procedure process is the subject of\n frequent and successful attacks as it allows unauthenticated use of the Oracle\n process account on the operating system. As of Oracle version 11.1, the\n external procedure agent may be run directly from the database and not require\n use of the Oracle listener. This reduces the risk of unauthorized access to the\n procedure from outside of the database process.", "descriptions": { - "default": "Once an attacker establishes initial access to a system, they often\n attempt to create a persistent method of re-establishing access. One way to\n accomplish this is for the attacker to simply create a new account.\n\n Auditing of account creation is one method and best practice for mitigating\n this risk. A comprehensive account management process will ensure an audit\n trail documents the creation of application user accounts and, as required,\n notifies administrators and/or application owners that they exist. Such a\n process greatly reduces the risk that accounts will be surreptitiously created\n and provides logging that can be used for forensic purposes.\n\n Note that user authentication and account management should be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP.\n\n However, notwithstanding how accounts are managed, Oracle auditing should\n always be configured to capture account creation." + "default": "The Oracle external procedure capability provides use of the Oracle\n process account outside the operation of the DBMS process. You can use it to\n submit and execute applications stored externally from the database under\n operating system controls. The external procedure process is the subject of\n frequent and successful attacks as it allows unauthenticated use of the Oracle\n process account on the operating system. As of Oracle version 11.1, the\n external procedure agent may be run directly from the database and not require\n use of the Oracle listener. This reduces the risk of unauthorized access to the\n procedure from outside of the database process." }, - "impact": 0.5, - "refs": [], + "impact": 0, + "refs": [ + { + "ref": [] + } + ], "tags": { - "gtitle": "SRG-APP-000026-DB-000005", - "gid": "V-61565", - "rid": "SV-76055r2_rule", - "stig_id": "O121-C2-002200", - "fix_id": "F-67481r2_fix", + "gtitle": "SRG-APP-000141-DB-000093", + "gid": "V-61685", + "rid": "SV-76175r2_rule", + "stig_id": "O121-C2-011810", + "fix_id": "F-67599r1_fix", "cci": [ - "CCI-000018" + "CCI-000381" ], "nist": [ - "AC-2 (4)", + "CM-7 a", "Rev_4" ], "false_negatives": null, @@ -173,35 +177,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Check Oracle settings (and also OS settings and/or\n enterprise-level authentication/access mechanisms settings) to determine if\n account creation is being audited. If account creation is not being audited by\n Oracle, this is a finding.\n\n If Standard Auditing is used:\n To see if Oracle is configured to capture audit data, enter the following\n SQL*Plus command:\n SHOW PARAMETER AUDIT_TRAIL\n or the following SQL query:\n SELECT * FROM SYS.V$PARAMETER WHERE NAME = 'audit_trail';\n If Oracle returns the value 'NONE', this is a finding.\n\n If Unified Auditing is used:\n To see if Oracle is configured to capture audit data including account\n creation, enter the following SQL*Plus command:\n SELECT ' Account creation is not being audited. '\n FROM dual\n WHERE (SELECT Count(*)\n FROM (select policy_name , audit_option from audit_unified_policies\n WHERE audit_option = 'CREATE USER'\n and policy_name in (select policy_name from\n audit_unified_enabled_policies where user_name='ALL USERS'))) = 0\n OR (SELECT value\n FROM v$option\n WHERE parameter = 'Unified Auditing') != 'TRUE';\n\n If Oracle returns \"no rows selected\", this is not a finding.", - "fix": "Configure Oracle to audit account creation activities.\n\n If Standard Auditing is used:\n Use this process to ensure auditable events are captured:\n ALTER SYSTEM SET AUDIT_TRAIL= SCOPE=SPFILE;\n Audit trail type can be 'OS', 'DB', 'DB,EXTENDED', 'XML' or 'XML,EXTENDED'.\n After executing this statement, it may be necessary to shut down and restart\n the Oracle database.\n\n If Unified Auditing is used:\n To ensure auditable events are captured:\n Link the oracle binary with uniaud_on, and then restart the database. Oracle\n Database Upgrade Guide describes how to enable unified auditing. Reference\n V-61625 for information on how to configure a policy to audit account creation.\n\n For more information on the configuration of auditing, refer to the following\n documents:\n \"Auditing Database Activity\" in the Oracle Database 2 Day + Security Guide:\n http://docs.oracle.com/database/121/TDPSG/tdpsg_auditing.htm#TDPSG50000\n \"Monitoring Database Activity with Auditing\" in the Oracle Database Security\n Guide:\n http://docs.oracle.com/database/121/DBSEG/part_6.htm#CCHEHCGI\n \"DBMS_AUDIT_MGMT\" in the Oracle Database PL/SQL Packages and Types Reference:\n http://docs.oracle.com/database/121/ARPLS/d_audit_mgmt.htm#ARPLS241\n Oracle Database Upgrade Guide:\n http://docs.oracle.com/database/121/UPGRD/afterup.htm#UPGRD52810" + "check": "Review the System Security Plan to determine if the use of the\n external procedure agent is authorized.\n\n Review the ORACLE_HOME/bin directory or search the ORACLE_BASE path for the\n executable extproc (UNIX) or extproc.exe (Windows).\n\n If external procedure agent is not authorized for use in the System Security\n Plan and the executable file does not exist or is restricted, this is not a\n finding.\n\n If external procedure agent is not authorized for use in the System Security\n Plan and the executable file exists and is not restricted, this is a finding.\n\n If use of the external procedure agent is authorized, ensure extproc is\n restricted to execution of authorized applications.\n\n External jobs are run using the account nobody by default.\n\n Review the contents of the file ORACLE_HOME/rdbms/admin/externaljob.ora for the\n lines run_user= and run_group=.\n\n If the user assigned to these parameters is not \"nobody\", this is a finding.\n\n For versions 11.1 and later, the external procedure agent (extproc executable)\n is available directly from the database and does not require definition in the\n listener.ora file for use.\n\n Review the contents of the file ORACLE_HOME/hs/admin/extproc.ora.\n\n If the file does not exist, this is a finding.\n\n If the following entry does not appear in the file, this is a finding:\n\n EXTPROC_DLLS=ONLY:[dll full file name1]:[dll full file name2]:..\n\n [dll full file name] represents a full path and file name.\n\n This list of file names is separated by \":\".\n\n Note: If \"ONLY\" is specified, then the list is restricted to allow execution\n of only the DLLs specified in the list and is not a finding. If \"ANY\" is\n specified, then there are no restrictions for execution except what is\n controlled by operating system permissions and is a finding. If no\n specification is made, any files located in the %ORACLE_HOME%\\bin directory on\n Windows systems or $ORACLE_HOME/lib directory on UNIX systems can be executed\n (the default) and is a finding.\n\n Ensure that EXTPROC is not accessible from the listener.\n\n Review the listener.ora file. If any entries reference \"extproc\", this is a\n finding.\n\n Determine if the external procedure agent is in use per Oracle 10.x conventions.\n\n Review the listener.ora file.\n\n If any entries reference \"extproc\", then the agent is in use.\n\n If external procedure agent is not authorized for use in the System Security\n Plan and references to \"extproc\" exist, this is a finding.\n\n Sample listener.ora entries with extproc included:\n\n LISTENER =\n (DESCRIPTION =\n (ADDRESS = (PROTOCOL = TCP)(HOST = 127.0.0.1)(PORT = 1521))\n )\n EXTLSNR =\n (DESCRIPTION =\n (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC))\n )\n SID_LIST_LISTENER =\n (SID_LIST =\n (SID_DESC =\n (GLOBAL_DBNAME = ORCL)\n (ORACLE_HOME = /home/oracle/app/oracle/product/11.1.0/db_1)\n (SID_NAME = ORCL)\n )\n )\n SID_LIST_EXTLSNR =\n (SID_LIST =\n (SID_DESC =\n (PROGRAM = extproc)\n (SID_NAME = PLSExtProc)\n (ORACLE_HOME = /home/oracle/app/oracle/product/11.1.0/db_1)\n (ENVS=\"EXTPROC_DLLS=ONLY:/home/app1/app1lib.so:/home/app2/app2lib.so,\n LD_LIBRARY_PATH=/private/app2/lib:/private/app1,\n MYPATH=/usr/fso:/usr/local/packages\")\n )\n )\n\n Sample tnsnames.ora entries with extproc included:\n\n ORCL =\n (DESCRIPTION =\n (ADDRESS_LIST =\n (ADDRESS = (PROTOCOL = TCP)(HOST = 127.0.0.1)(PORT = 1521))\n )\n (CONNECT_DATA =\n (SERVICE_NAME = ORCL)\n )\n )\n EXTPROC_CONNECTION_DATA =\n (DESCRIPTION =\n (ADDRESS_LIST =\n (ADDRESS = (PROTOCOL = IPC)(KEY = extproc))\n )\n (CONNECT_DATA =\n (SERVER = DEDICATED)\n (SERVICE_NAME = PLSExtProc)\n )\n )\n\n If EXTPROC is in use, confirm that a listener is dedicated to serving the\n external procedure agent (as shown above).\n\n View the protocols configured for the listener.\n\n For the listener to be dedicated, the only entries will be to specify extproc.\n\n If there is not a dedicated listener in use for the external procedure agent,\n this is a finding.\n\n If the PROTOCOL= specified is other than IPC, this is a finding.\n\n Verify and ensure extproc is restricted executing authorized external\n applications only and extproc is restricted to execution of authorized\n applications.\n\n Review the listener.ora file.\n\n If the following entry does not exist, this is a finding:\n\n EXTPROC_DLLS=ONLY:[dll full file name1]:[dll full file name2]:...\n\n Note: [dll full file name] represents a full path and file name. This list of\n file names is separated by \":\".\n\n Note: If \"ONLY\" is specified, then the list is restricted to allow execution\n of only the DLLs specified in the list and is not a finding. If \"ANY\" is\n specified, then there are no restrictions for execution except what is\n controlled by operating system permissions and is a finding. If no\n specification is made, any files located in the %ORACLE_HOME%\\bin directory on\n Windows systems or $ORACLE_HOME/lib directory on UNIX systems can be executed\n (the default) and is a finding.\n\n View the listener.ora file (usually in ORACLE_HOME/network/admin or directory\n specified by the TNS_ADMIN environment variable).\n\n If multiple listener processes are running, then the listener.ora file for each\n must be viewed.\n\n For each process, determine the directory specified in the ORACLE_HOME or\n TNS_ADMIN environment variable defined for the process account to locate the\n listener.ora file.", + "fix": "If use of the external procedure agent is required, then\n authorize and document the requirement in the System Security Plan.\n\n If the external procedure agent must be accessible to the Oracle listener, then\n specify this and authorize it in the System Security Plan.\n\n If use of the Oracle External Procedure agent is not required:\n\n - Stop the Oracle Listener process\n - Remove all references to extproc in the listener.ora and tnsnames.ora files\n - Alter the permissions on the executable files:\n UNIX - Remove read/write/execute permissions from owner, group and\n world\n Windows - Remove Groups/Users from the executable (except groups\n SYSTEM and ADMINISTRATORS) and allow READ [only] for SYSTEM and ADMINISTRATORS\n groups\n\n If required:\n\n - Restrict extproc execution to only authorized applications.\n - Specify EXTPROC_DLLS=ONLY: [list of authorized DLLS] in the extproc.ora and\n the listener.ora files\n - Create a separate, dedicated listener for use by the external procedure agent\n\n See the Oracle Net Services Administrators Guides, External Procedures section\n for detailed configuration information." }, - "code": "control 'V-61565' do\n title 'The DBMS must automatically audit account creation.'\n desc \"Once an attacker establishes initial access to a system, they often\n attempt to create a persistent method of re-establishing access. One way to\n accomplish this is for the attacker to simply create a new account.\n\n Auditing of account creation is one method and best practice for mitigating\n this risk. A comprehensive account management process will ensure an audit\n trail documents the creation of application user accounts and, as required,\n notifies administrators and/or application owners that they exist. Such a\n process greatly reduces the risk that accounts will be surreptitiously created\n and provides logging that can be used for forensic purposes.\n\n Note that user authentication and account management should be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP.\n\n However, notwithstanding how accounts are managed, Oracle auditing should\n always be configured to capture account creation.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000026-DB-000005'\n tag \"gid\": 'V-61565'\n tag \"rid\": 'SV-76055r2_rule'\n tag \"stig_id\": 'O121-C2-002200'\n tag \"fix_id\": 'F-67481r2_fix'\n tag \"cci\": ['CCI-000018']\n tag \"nist\": ['AC-2 (4)', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Check Oracle settings (and also OS settings and/or\n enterprise-level authentication/access mechanisms settings) to determine if\n account creation is being audited. If account creation is not being audited by\n Oracle, this is a finding.\n\n If Standard Auditing is used:\n To see if Oracle is configured to capture audit data, enter the following\n SQL*Plus command:\n SHOW PARAMETER AUDIT_TRAIL\n or the following SQL query:\n SELECT * FROM SYS.V$PARAMETER WHERE NAME = 'audit_trail';\n If Oracle returns the value 'NONE', this is a finding.\n\n If Unified Auditing is used:\n To see if Oracle is configured to capture audit data including account\n creation, enter the following SQL*Plus command:\n SELECT ' Account creation is not being audited. '\n FROM dual\n WHERE (SELECT Count(*)\n FROM (select policy_name , audit_option from audit_unified_policies\n WHERE audit_option = 'CREATE USER'\n and policy_name in (select policy_name from\n audit_unified_enabled_policies where user_name='ALL USERS'))) = 0\n OR (SELECT value\n FROM v$option\n WHERE parameter = 'Unified Auditing') != 'TRUE';\n\n If Oracle returns \\\"no rows selected\\\", this is not a finding.\"\n tag \"fix\": \"Configure Oracle to audit account creation activities.\n\n If Standard Auditing is used:\n Use this process to ensure auditable events are captured:\n ALTER SYSTEM SET AUDIT_TRAIL= SCOPE=SPFILE;\n Audit trail type can be 'OS', 'DB', 'DB,EXTENDED', 'XML' or 'XML,EXTENDED'.\n After executing this statement, it may be necessary to shut down and restart\n the Oracle database.\n\n If Unified Auditing is used:\n To ensure auditable events are captured:\n Link the oracle binary with uniaud_on, and then restart the database. Oracle\n Database Upgrade Guide describes how to enable unified auditing. Reference\n V-61625 for information on how to configure a policy to audit account creation.\n\n For more information on the configuration of auditing, refer to the following\n documents:\n \\\"Auditing Database Activity\\\" in the Oracle Database 2 Day + Security Guide:\n http://docs.oracle.com/database/121/TDPSG/tdpsg_auditing.htm#TDPSG50000\n \\\"Monitoring Database Activity with Auditing\\\" in the Oracle Database Security\n Guide:\n http://docs.oracle.com/database/121/DBSEG/part_6.htm#CCHEHCGI\n \\\"DBMS_AUDIT_MGMT\\\" in the Oracle Database PL/SQL Packages and Types Reference:\n http://docs.oracle.com/database/121/ARPLS/d_audit_mgmt.htm#ARPLS241\n Oracle Database Upgrade Guide:\n http://docs.oracle.com/database/121/UPGRD/afterup.htm#UPGRD52810\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n standard_auditing_used = input('standard_auditing_used')\n unified_auditing_used = input('unified_auditing_used')\n\n describe.one do\n describe 'Standard auditing is in use for audit purposes' do\n subject { standard_auditing_used }\n it { should be true }\n end\n\n describe 'Unified auditing is in use for audit purposes' do\n subject { unified_auditing_used }\n it { should be true }\n end\n end\n\n audit_trail = sql.query(\"select value from v$parameter where name = 'audit_trail';\").column('value')\n\n if standard_auditing_used\n describe 'The oracle database audit_trail parameter' do\n subject { audit_trail }\n it { should_not cmp 'NONE' }\n end\n end\n\n unified_auditing = sql.query(\"SELECT value FROM V$OPTION WHERE PARAMETER = 'Unified Auditing';\").column('value')\n\n if unified_auditing_used\n describe 'The oracle database unified auditing parameter' do\n subject { unified_auditing }\n it { should_not cmp 'FALSE' }\n end\n\n unified_auditing_events = sql.query(\"SELECT ' Account creation is not being audited. '\n FROM dual\n WHERE (SELECT Count(*)\n FROM (select policy_name , audit_option from audit_unified_policies\n WHERE audit_option = 'CREATE USER'\n and policy_name in (select policy_name from\n audit_unified_enabled_policies where user_name='ALL USERS'))) = 0\n OR (SELECT value\n FROM v$option\n WHERE parameter = 'Unified Auditing') != 'TRUE';\").column('Account creation is not being audited.').uniq\n\n describe 'The unified auditing data capture for account creation' do\n subject { unified_auditing_events.to_s }\n it { should_not cmp '[nil]' }\n end\n end\nend\n", + "code": " control 'V-61685' do\n impact 0.0\n describe 'This control is not applicable on oracle within aws rds, as aws manages the operating system in which the oracle database is running on' do\n skip 'This control is not applicable on oracle within aws rds, as aws manages the operating system in which the oracle database is running on'\n end\n end\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61565.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61685.rb", "line": 1 }, - "id": "V-61565" + "id": "V-61685" }, { - "title": "The DBMS must automatically audit account modification.", - "desc": "Once an attacker establishes initial access to a system, they often\n attempt to create a persistent method of re-establishing access. One way to\n accomplish this is for the attacker to simply modify an existing account.\n\n Auditing of account modification is one method and best practice for\n mitigating this risk. A comprehensive application account management process\n ensures an audit trail automatically documents the modification of application\n user accounts and, as required, notifies administrators, application owners,\n and/or appropriate individuals. Applications must provide this capability\n directly, leveraging complementary technology providing this capability or a\n combination thereof.\n\n Automated account auditing processes greatly reduces the risk that accounts\n will be surreptitiously modified and provides logging that can be used for\n forensic purposes.\n\n Note that user authentication and account management should be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP.\n\n However, notwithstanding how accounts are managed, Oracle auditing should\n always be configured to capture account modification.", + "title": "The ISSM must review changes to DBA role assignments.", + "desc": "Unauthorized assignment of DBA privileges can lead to a compromise of\n DBMS integrity. Providing oversight to the authorization and assignment of\n privileges provides the separation of duty to support sufficient oversight.", "descriptions": { - "default": "Once an attacker establishes initial access to a system, they often\n attempt to create a persistent method of re-establishing access. One way to\n accomplish this is for the attacker to simply modify an existing account.\n\n Auditing of account modification is one method and best practice for\n mitigating this risk. A comprehensive application account management process\n ensures an audit trail automatically documents the modification of application\n user accounts and, as required, notifies administrators, application owners,\n and/or appropriate individuals. Applications must provide this capability\n directly, leveraging complementary technology providing this capability or a\n combination thereof.\n\n Automated account auditing processes greatly reduces the risk that accounts\n will be surreptitiously modified and provides logging that can be used for\n forensic purposes.\n\n Note that user authentication and account management should be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP.\n\n However, notwithstanding how accounts are managed, Oracle auditing should\n always be configured to capture account modification." + "default": "Unauthorized assignment of DBA privileges can lead to a compromise of\n DBMS integrity. Providing oversight to the authorization and assignment of\n privileges provides the separation of duty to support sufficient oversight." }, "impact": 0.5, "refs": [], "tags": { - "gtitle": "SRG-APP-000027-DB-000186", - "gid": "V-61569", - "rid": "SV-76059r2_rule", - "stig_id": "O121-C2-002300", - "fix_id": "F-67485r3_fix", + "gtitle": "SRG-APP-000516-DB-999900", + "gid": "V-61497", + "rid": "SV-75987r1_rule", + "stig_id": "O121-BP-024600", + "fix_id": "F-67413r1_fix", "cci": [ - "CCI-001403" + "CCI-000366" ], "nist": [ - "AC-2 (4)", + "CM-6 b", "Rev_4" ], "false_negatives": null, @@ -214,15 +218,15 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Check Oracle settings (and also OS settings and/or\n enterprise-level authentication/access mechanisms settings) to determine if\n account modification is being audited. If account modification is not being\n audited by Oracle, this is a finding.\n\n If Standard Auditing is used:\n To see if Oracle is configured to capture audit data, enter the following\n SQL*Plus command:\n SHOW PARAMETER AUDIT_TRAIL\n or the following SQL query:\n SELECT * FROM SYS.V$PARAMETER WHERE NAME = 'audit_trail';\n If Oracle returns the value 'NONE', this is a finding.\n\n If Unified Auditing is used:\n To see if Oracle is configured to capture audit data including account\n modification, enter the following SQL*Plus command:\n SELECT ' Account modification is not being audited. '\n FROM dual\n WHERE (SELECT Count(*)\n FROM (select policy_name , audit_option from audit_unified_policies\n WHERE audit_option = 'ALTER USER'\n and policy_name in (select policy_name from\n audit_unified_enabled_policies where user_name='ALL USERS'))) = 0\n OR (SELECT value\n FROM v$option\n WHERE parameter = 'Unified Auditing') != 'TRUE';\n\n If Oracle returns \"no rows selected\", this is not a finding.", - "fix": "Configure Oracle to audit account modifications activities.\n\n If Standard Auditing is used:\n Use this process to ensure auditable events are captured:\n ALTER SYSTEM SET AUDIT_TRAIL= SCOPE=SPFILE;\n Audit trail type can be 'OS', 'DB', 'DB,EXTENDED', 'XML' or 'XML,EXTENDED'.\n After executing this statement, it may be necessary to shut down and restart\n the Oracle database.\n\n If Unified Auditing is used:\n To ensure auditable events are captured:\n Link the oracle binary with uniaud_on, and then restart the database. Oracle\n Database Upgrade Guide describes how to enable unified auditing. Reference\n V-61625 for information on how to configure a policy to audit account\n modification.\n\n For more information on the configuration of auditing, refer to the following\n documents:\n \"Auditing Database Activity\" in the Oracle Database 2 Day + Security Guide:\n http://docs.oracle.com/database/121/TDPSG/tdpsg_auditing.htm#TDPSG50000\n \"Monitoring Database Activity with Auditing\" in the Oracle Database Security\n Guide:\n http://docs.oracle.com/database/121/DBSEG/part_6.htm#CCHEHCGI\n \"DBMS_AUDIT_MGMT\" in the Oracle Database PL/SQL Packages and Types Reference:\n http://docs.oracle.com/database/121/ARPLS/d_audit_mgmt.htm#ARPLS241\n Oracle Database Upgrade Guide:\n http://docs.oracle.com/database/121/UPGRD/afterup.htm#UPGRD52810" + "check": "Review policy and procedures documented or noted in the System\n Security Plan as well as evidence of implementation for monitoring changes to\n DBA role assignments and procedures for notifying the ISSM of the changes for\n review.\n\n If policy, procedures or implementation evidence do not exist, this is a\n finding.", + "fix": "Develop, document and implement procedures to monitor changes to\n DBA role assignments.\n\n Develop, document and implement procedures to notify the ISSM of changes to DBA\n role assignments.\n\n Include in the procedures methods that provide evidence of monitoring and\n notification." }, - "code": "control 'V-61569' do\n title 'The DBMS must automatically audit account modification.'\n desc \"Once an attacker establishes initial access to a system, they often\n attempt to create a persistent method of re-establishing access. One way to\n accomplish this is for the attacker to simply modify an existing account.\n\n Auditing of account modification is one method and best practice for\n mitigating this risk. A comprehensive application account management process\n ensures an audit trail automatically documents the modification of application\n user accounts and, as required, notifies administrators, application owners,\n and/or appropriate individuals. Applications must provide this capability\n directly, leveraging complementary technology providing this capability or a\n combination thereof.\n\n Automated account auditing processes greatly reduces the risk that accounts\n will be surreptitiously modified and provides logging that can be used for\n forensic purposes.\n\n Note that user authentication and account management should be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP.\n\n However, notwithstanding how accounts are managed, Oracle auditing should\n always be configured to capture account modification.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000027-DB-000186'\n tag \"gid\": 'V-61569'\n tag \"rid\": 'SV-76059r2_rule'\n tag \"stig_id\": 'O121-C2-002300'\n tag \"fix_id\": 'F-67485r3_fix'\n tag \"cci\": ['CCI-001403']\n tag \"nist\": ['AC-2 (4)', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Check Oracle settings (and also OS settings and/or\n enterprise-level authentication/access mechanisms settings) to determine if\n account modification is being audited. If account modification is not being\n audited by Oracle, this is a finding.\n\n If Standard Auditing is used:\n To see if Oracle is configured to capture audit data, enter the following\n SQL*Plus command:\n SHOW PARAMETER AUDIT_TRAIL\n or the following SQL query:\n SELECT * FROM SYS.V$PARAMETER WHERE NAME = 'audit_trail';\n If Oracle returns the value 'NONE', this is a finding.\n\n If Unified Auditing is used:\n To see if Oracle is configured to capture audit data including account\n modification, enter the following SQL*Plus command:\n SELECT ' Account modification is not being audited. '\n FROM dual\n WHERE (SELECT Count(*)\n FROM (select policy_name , audit_option from audit_unified_policies\n WHERE audit_option = 'ALTER USER'\n and policy_name in (select policy_name from\n audit_unified_enabled_policies where user_name='ALL USERS'))) = 0\n OR (SELECT value\n FROM v$option\n WHERE parameter = 'Unified Auditing') != 'TRUE';\n\n If Oracle returns \\\"no rows selected\\\", this is not a finding.\"\n tag \"fix\": \"Configure Oracle to audit account modifications activities.\n\n If Standard Auditing is used:\n Use this process to ensure auditable events are captured:\n ALTER SYSTEM SET AUDIT_TRAIL= SCOPE=SPFILE;\n Audit trail type can be 'OS', 'DB', 'DB,EXTENDED', 'XML' or 'XML,EXTENDED'.\n After executing this statement, it may be necessary to shut down and restart\n the Oracle database.\n\n If Unified Auditing is used:\n To ensure auditable events are captured:\n Link the oracle binary with uniaud_on, and then restart the database. Oracle\n Database Upgrade Guide describes how to enable unified auditing. Reference\n V-61625 for information on how to configure a policy to audit account\n modification.\n\n For more information on the configuration of auditing, refer to the following\n documents:\n \\\"Auditing Database Activity\\\" in the Oracle Database 2 Day + Security Guide:\n http://docs.oracle.com/database/121/TDPSG/tdpsg_auditing.htm#TDPSG50000\n \\\"Monitoring Database Activity with Auditing\\\" in the Oracle Database Security\n Guide:\n http://docs.oracle.com/database/121/DBSEG/part_6.htm#CCHEHCGI\n \\\"DBMS_AUDIT_MGMT\\\" in the Oracle Database PL/SQL Packages and Types Reference:\n http://docs.oracle.com/database/121/ARPLS/d_audit_mgmt.htm#ARPLS241\n Oracle Database Upgrade Guide:\n http://docs.oracle.com/database/121/UPGRD/afterup.htm#UPGRD52810\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n standard_auditing_used = input('standard_auditing_used')\n unified_auditing_used = input('unified_auditing_used')\n\n describe.one do\n describe 'Standard auditing is in use for audit purposes' do\n subject { standard_auditing_used }\n it { should be true }\n end\n\n describe 'Unified auditing is in use for audit purposes' do\n subject { unified_auditing_used }\n it { should be true }\n end\n end\n\n audit_trail = sql.query(\"select value from v$parameter where name = 'audit_trail';\").column('value')\n\n if standard_auditing_used\n describe 'The oracle database audit_trail parameter' do\n subject { audit_trail }\n it { should_not cmp 'NONE' }\n end\n end\n\n unified_auditing = sql.query(\"SELECT value FROM V$OPTION WHERE PARAMETER = 'Unified Auditing';\").column('value')\n\n if unified_auditing_used\n describe 'The oracle database unified auditing parameter' do\n subject { unified_auditing }\n it { should_not cmp 'FALSE' }\n end\n\n unified_auditing_events = sql.query(\"SELECT ' Account modification is not being audited. '\n FROM dual\n WHERE (SELECT Count(*)\n FROM (select policy_name , audit_option from audit_unified_policies\n WHERE audit_option = 'ALTER USER'\n and policy_name in (select policy_name from\n audit_unified_enabled_policies where user_name='ALL USERS'))) = 0\n OR (SELECT value\n FROM v$option\n WHERE parameter = 'Unified Auditing') != 'TRUE';\").column('Account modification is not being audited.').uniq\n\n describe 'The unified auditing data capture for account modification' do\n subject { unified_auditing_events.to_s }\n it { should_not cmp '[nil]' }\n end\n end\nend\n", + "code": "control 'V-61497' do\n title 'The ISSM must review changes to DBA role assignments.'\n desc \"Unauthorized assignment of DBA privileges can lead to a compromise of\n DBMS integrity. Providing oversight to the authorization and assignment of\n privileges provides the separation of duty to support sufficient oversight.\"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000516-DB-999900'\n tag \"gid\": 'V-61497'\n tag \"rid\": 'SV-75987r1_rule'\n tag \"stig_id\": 'O121-BP-024600'\n tag \"fix_id\": 'F-67413r1_fix'\n tag \"cci\": ['CCI-000366']\n tag \"nist\": ['CM-6 b', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Review policy and procedures documented or noted in the System\n Security Plan as well as evidence of implementation for monitoring changes to\n DBA role assignments and procedures for notifying the ISSM of the changes for\n review.\n\n If policy, procedures or implementation evidence do not exist, this is a\n finding.\"\n tag \"fix\": \"Develop, document and implement procedures to monitor changes to\n DBA role assignments.\n\n Develop, document and implement procedures to notify the ISSM of changes to DBA\n role assignments.\n\n Include in the procedures methods that provide evidence of monitoring and\n notification.\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n database_roles = sql.query('select * from dba_roles;').column('role')\n\n describe \"A manual review is required to ensure the ISSM reviews changes to DBA role assignments. The database roles to review are: #{database_roles}\" do\n skip \"A manual review is required to ensure the ISSM reviews changes to DBA role assignments. The database roles to review are: #{database_roles}\"\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61569.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61497.rb", "line": 1 }, - "id": "V-61569" + "id": "V-61497" }, { "title": "The DBMS must restrict access to system tables and other configuration\n information or metadata to DBAs or other authorized users.", @@ -267,24 +271,24 @@ "id": "V-61589" }, { - "title": "Logic modules within the database (to include packages, procedures,\n functions and triggers) must be monitored to discover unauthorized changes.", - "desc": "Any changes to the hardware, software, and/or firmware components of\n the information system and/or application can potentially have significant\n effects on the overall security of the system. This includes the logic modules\n implemented within the database, such as packages, procedures, functions and\n triggers.\n\n If the DBMS were to allow any user to make changes to these, then those\n changes might be implemented without undergoing the appropriate testing and\n approvals that are part of a robust change management process.\n\n Accordingly, only qualified and authorized individuals shall be allowed to\n obtain access to information system components for purposes of initiating\n changes, including upgrades and modifications.\n\n Unmanaged changes that occur to the database logic modules can lead to\n unauthorized or compromised installations.", + "title": "The DBMS must separate user functionality (including user interface\n services) from database management functionality.", + "desc": "Information system management functionality includes functions\n necessary to administer databases, network components, workstations, or\n servers, and typically requires privileged user access.\n\n The separation of user functionality from information system management\n functionality is either physical or logical and is accomplished by using\n different computers, different central processing units, different instances of\n the operating system, different network addresses, combinations of these\n methods, or other methods, as appropriate.\n\n An example of this type of separation is observed in web administrative\n interfaces that use separate authentication methods for users of any other\n information system resources.\n\n This may include isolating the administrative interface on a different\n domain and with additional access controls.\n\n If administrative functionality or information regarding DBMS management is\n presented on an interface available for users, information on DBMS settings may\n be inadvertently made available to the user.", "descriptions": { - "default": "Any changes to the hardware, software, and/or firmware components of\n the information system and/or application can potentially have significant\n effects on the overall security of the system. This includes the logic modules\n implemented within the database, such as packages, procedures, functions and\n triggers.\n\n If the DBMS were to allow any user to make changes to these, then those\n changes might be implemented without undergoing the appropriate testing and\n approvals that are part of a robust change management process.\n\n Accordingly, only qualified and authorized individuals shall be allowed to\n obtain access to information system components for purposes of initiating\n changes, including upgrades and modifications.\n\n Unmanaged changes that occur to the database logic modules can lead to\n unauthorized or compromised installations." + "default": "Information system management functionality includes functions\n necessary to administer databases, network components, workstations, or\n servers, and typically requires privileged user access.\n\n The separation of user functionality from information system management\n functionality is either physical or logical and is accomplished by using\n different computers, different central processing units, different instances of\n the operating system, different network addresses, combinations of these\n methods, or other methods, as appropriate.\n\n An example of this type of separation is observed in web administrative\n interfaces that use separate authentication methods for users of any other\n information system resources.\n\n This may include isolating the administrative interface on a different\n domain and with additional access controls.\n\n If administrative functionality or information regarding DBMS management is\n presented on an interface available for users, information on DBMS settings may\n be inadvertently made available to the user." }, "impact": 0.5, "refs": [], "tags": { - "gtitle": "SRG-APP-000133-DB-000179", - "gid": "V-68863", - "rid": "SV-83467r1_rule", - "stig_id": "O121-OS-010710", - "fix_id": "F-75045r1_fix", + "gtitle": "SRG-APP-000211-DB-000122", + "gid": "V-61883", + "rid": "SV-76373r1_rule", + "stig_id": "O121-P2-017300", + "fix_id": "F-67799r1_fix", "cci": [ - "CCI-001499" + "CCI-001082" ], "nist": [ - "CM-5 (6)", + "SC-2", "Rev_4" ], "false_negatives": null, @@ -297,30 +301,30 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Review monitoring procedures and implementation evidence to\n verify that monitoring of changes to database logic modules is done.\n\n Verify the list of objects (packages, procedures, functions, and triggers)\n being monitored is complete. If monitoring does not occur or is not complete,\n this is a finding.", - "fix": "Implement procedures to monitor for unauthorized changes to\n database logic modules. If a third-party automated tool is not employed, an\n automated job that reports on the objects of interest and compares them to the\n baseline report for the same will meet the requirement." + "check": "Check DBMS settings and vendor documentation to verify\n administrative functionality is separate from user functionality.\n\n If administrator and general user functionality is not separated either\n physically or logically, this is a finding.", + "fix": "Configure DBMS settings to separate database administration and\n general user functionality. Provide those who have both administrative and\n general-user responsibilities with separate accounts for these separate\n functions." }, - "code": "control 'V-68863' do\n title \"Logic modules within the database (to include packages, procedures,\n functions and triggers) must be monitored to discover unauthorized changes.\"\n desc \"Any changes to the hardware, software, and/or firmware components of\n the information system and/or application can potentially have significant\n effects on the overall security of the system. This includes the logic modules\n implemented within the database, such as packages, procedures, functions and\n triggers.\n\n If the DBMS were to allow any user to make changes to these, then those\n changes might be implemented without undergoing the appropriate testing and\n approvals that are part of a robust change management process.\n\n Accordingly, only qualified and authorized individuals shall be allowed to\n obtain access to information system components for purposes of initiating\n changes, including upgrades and modifications.\n\n Unmanaged changes that occur to the database logic modules can lead to\n unauthorized or compromised installations.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000133-DB-000179'\n tag \"gid\": 'V-68863'\n tag \"rid\": 'SV-83467r1_rule'\n tag \"stig_id\": 'O121-OS-010710'\n tag \"fix_id\": 'F-75045r1_fix'\n tag \"cci\": ['CCI-001499']\n tag \"nist\": ['CM-5 (6)', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Review monitoring procedures and implementation evidence to\n verify that monitoring of changes to database logic modules is done.\n\n Verify the list of objects (packages, procedures, functions, and triggers)\n being monitored is complete. If monitoring does not occur or is not complete,\n this is a finding.\"\n tag \"fix\": \"Implement procedures to monitor for unauthorized changes to\n database logic modules. If a third-party automated tool is not employed, an\n automated job that reports on the objects of interest and compares them to the\n baseline report for the same will meet the requirement.\"\n describe 'A manual review is required to ensure the logic modules within the database (to include packages, procedures,\n functions and triggers) are monitored to discover unauthorized changes' do\n skip 'A manual review is required to ensure the logic modules within the database (to include packages, procedures,\n functions and triggers) are monitored to discover unauthorized changes'\n end\nend\n", + "code": "control 'V-61883' do\n title \"The DBMS must separate user functionality (including user interface\n services) from database management functionality.\"\n desc \"Information system management functionality includes functions\n necessary to administer databases, network components, workstations, or\n servers, and typically requires privileged user access.\n\n The separation of user functionality from information system management\n functionality is either physical or logical and is accomplished by using\n different computers, different central processing units, different instances of\n the operating system, different network addresses, combinations of these\n methods, or other methods, as appropriate.\n\n An example of this type of separation is observed in web administrative\n interfaces that use separate authentication methods for users of any other\n information system resources.\n\n This may include isolating the administrative interface on a different\n domain and with additional access controls.\n\n If administrative functionality or information regarding DBMS management is\n presented on an interface available for users, information on DBMS settings may\n be inadvertently made available to the user.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000211-DB-000122'\n tag \"gid\": 'V-61883'\n tag \"rid\": 'SV-76373r1_rule'\n tag \"stig_id\": 'O121-P2-017300'\n tag \"fix_id\": 'F-67799r1_fix'\n tag \"cci\": ['CCI-001082']\n tag \"nist\": ['SC-2', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Check DBMS settings and vendor documentation to verify\n administrative functionality is separate from user functionality.\n\n If administrator and general user functionality is not separated either\n physically or logically, this is a finding.\"\n tag \"fix\": \"Configure DBMS settings to separate database administration and\n general user functionality. Provide those who have both administrative and\n general-user responsibilities with separate accounts for these separate\n functions.\"\n describe 'A manual review is required to ensure the DBMS separates user functionality (including user interface\n services) from database management functionality' do\n skip 'A manual review is required to ensure the DBMS separates user functionality (including user interface\n services) from database management functionality'\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-68863.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61883.rb", "line": 1 }, - "id": "V-68863" + "id": "V-61883" }, { - "title": "Object permissions granted to PUBLIC must be restricted.", - "desc": "Permissions on objects may be granted to the user group PUBLIC.\n Because every database user is a member of the PUBLIC group, granting object\n permissions to PUBLIC gives all users in the database access to that object. In\n a secure environment, granting object permissions to PUBLIC must be restricted\n to those objects that all users are allowed to access. The policy does not\n require object permissions assigned to PUBLIC by the installation of Oracle\n Database server components be revoked.", + "title": "DBA OS accounts must be granted only those host system privileges\n necessary for the administration of the DBMS.", + "desc": "This requirement is intended to limit exposure due to operating from\n within a privileged account or role. The inclusion of role is intended to\n address those situations where an access control policy, such as Role Based\n Access Control (RBAC), is being implemented and where a change of role provides\n the same degree of assurance in the change of access authorizations for both\n the user and all processes acting on behalf of the user as would be provided by\n a change between a privileged and non-privileged account.\n\n DBAs, if assigned excessive OS privileges, could perform actions that could\n endanger the information system or hide evidence of malicious activity.", "descriptions": { - "default": "Permissions on objects may be granted to the user group PUBLIC.\n Because every database user is a member of the PUBLIC group, granting object\n permissions to PUBLIC gives all users in the database access to that object. In\n a secure environment, granting object permissions to PUBLIC must be restricted\n to those objects that all users are allowed to access. The policy does not\n require object permissions assigned to PUBLIC by the installation of Oracle\n Database server components be revoked." + "default": "This requirement is intended to limit exposure due to operating from\n within a privileged account or role. The inclusion of role is intended to\n address those situations where an access control policy, such as Role Based\n Access Control (RBAC), is being implemented and where a change of role provides\n the same degree of assurance in the change of access authorizations for both\n the user and all processes acting on behalf of the user as would be provided by\n a change between a privileged and non-privileged account.\n\n DBAs, if assigned excessive OS privileges, could perform actions that could\n endanger the information system or hide evidence of malicious activity." }, - "impact": 0, + "impact": 0.7, "refs": [], "tags": { - "gtitle": "SRG-APP-000516-DB-999900", - "gid": "V-61439", - "rid": "SV-75929r3_rule", - "stig_id": "O121-BP-022600", - "fix_id": "F-67355r2_fix", + "gtitle": "SRG-APP-000063-DB-000021", + "gid": "V-61537", + "rid": "SV-76027r1_rule", + "stig_id": "O121-C1-004500", + "fix_id": "F-67453r1_fix", "cci": [ "CCI-000366" ], @@ -338,35 +342,39 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "A default Oracle Database installation provides a set of\n predefined administrative accounts and non-administrative accounts. These are\n accounts that have special privileges required to administer areas of the\n database, such as the “CREATE ANY TABLE” or “ALTER SESSION” privilege, or\n “EXECUTE” privileges on packages owned by the SYS schema. The default\n tablespace for administrative accounts is either “SYSTEM” or “SYSAUX”.\n Non-administrative user accounts only have the minimum privileges needed to\n perform their jobs. Their default tablespace is “USERS”.\n\n To protect these accounts from unauthorized access, the installation process\n expires and locks most of these accounts, except where noted below. The\n database administrator is responsible for unlocking and resetting these\n accounts, as required.\n\n Non-Administrative Accounts - Expired and locked:\n APEX_PUBLIC_USER, DIP, FLOWS_040100*, FLOWS_FILES, MDDATA, ORACLE_OCM,\n SPATIAL_CSW_ADMIN_USR, SPATIAL_WFS_ADMIN_USR, XS$NULL\n\n Administrative Accounts - Expired and Locked:\n ANONYMOUS, CTXSTS, EXFSYS, LBACSYS, MDSYS, OLAPSYS, OEDDATA, OWBSYS,\n ORDPLUGINS, ORDSYS, OUTLN, SI_INFORMTN_SCHEMA, WK_TEST, WK_SYS, WKPROXY, WMSYS,\n XDB\n\n Administrative Accounts - Open:\n DBSNMP, MGMT_VIEW, SYS, SYSMAN, SYSTEM\n\n * Subject to change based on version installed\n\n Run the SQL query:\n\n select owner ||'.'|| table_name ||':'|| privilege from dba_tab_privs\n where grantee = 'PUBLIC';\n and owner not in\n ();\n\n (With respect to the list of special accounts that are excluded from this\n requirement, it is expected that the DBA will maintain the list to suit local\n circumstances, adding special accounts as necessary and removing any that are\n not supposed to be in use in the Oracle deployment that is under review.)\n\n If there are any records returned that are not Oracle product accounts, and are\n not documented and authorized, this is a finding.\n\n Note: This check may return false positives where other Oracle product accounts\n are not included in the exclusion list.", - "fix": "Revoke any privileges granted to PUBLIC for objects that are not\n owned by Oracle product accounts.\n\n From SQL*Plus:\n\n revoke [privilege name] from [user name] on [object name];\n\n Assign permissions to custom application user roles based on job functions:\n\n From SQL*Plus:\n\n grant [privilege name] to [user role] on [object name];" + "check": "Review host system privileges assigned to the Oracle DBA group\n and all individual Oracle DBA accounts.\n\n Note: do not include the Oracle software installation account in any results\n for this check.\n\n For UNIX systems (as root):\n cat /etc/group | grep -i dba\n groups root\n\n If \"root\" is returned in the first list, this is a finding.\n\n If any accounts listed in the first list are also listed in the second list,\n this is a finding.\n\n Investigate any user account group memberships other than DBA or root groups\n that are returned by the following command (also as root):\n\n groups [dba user account]\n\n Replace [dba user account] with the user account name of each DBA account.\n\n If individual DBA accounts are assigned to groups that grant access or\n privileges for purposes other than DBA responsibilities, this is a finding.\n\n For Windows Systems (click or select):\n Start / Settings / Control Panel / Administrative Tools / Computer Management /\n Local Users and Groups / Groups / ORA_DBA\n Start / Settings / Control Panel / Administrative Tools / Computer Management /\n Local Users and Groups / Groups / ORA_[SID]_DBA (if present)\n\n Note: Users assigned DBA privileges on a Windows host are granted membership in\n the ORA_DBA and/or ORA_[SID]_DBA groups. The ORA_DBA group grants DBA\n privileges to any database on the system. The ORA_[SID]_DBA groups grant DBA\n privileges to specific Oracle instances only.\n\n Make a note of each user listed. For each user (click or select):\n Start / Settings / Control Panel / Administrative Tools / Computer Management /\n Local Users and Groups / Users / [DBA user name] / Member of\n\n If DBA users belong to any groups other than DBA groups and the Windows Users\n group, this is a finding.\n\n Examine User Rights assigned to DBA groups or group members:\n Start / Settings / Control Panel / Administrative Tools / Local Security Policy\n / Security Settings / Local Policies / User Rights Assignments\n\n If any User Rights are assigned directly to the DBA group(s) or DBA user\n accounts, this is a finding.", + "fix": "Revoke all host system privileges from the DBA group accounts and\n DBA user accounts not required for DBMS administration.\n\n Revoke all OS group memberships that assign excessive privileges to the DBA\n group accounts and DBA user accounts.\n\n Remove any directly applied permissions or user rights from the DBA group\n accounts and DBA user accounts.\n\n Document all DBA group accounts and individual DBA account-assigned privileges\n in the System Security Plan." }, - "code": "control 'V-61439' do\n title 'Object permissions granted to PUBLIC must be restricted.'\n desc \"Permissions on objects may be granted to the user group PUBLIC.\n Because every database user is a member of the PUBLIC group, granting object\n permissions to PUBLIC gives all users in the database access to that object. In\n a secure environment, granting object permissions to PUBLIC must be restricted\n to those objects that all users are allowed to access. The policy does not\n require object permissions assigned to PUBLIC by the installation of Oracle\n Database server components be revoked.\"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000516-DB-999900'\n tag \"gid\": 'V-61439'\n tag \"rid\": 'SV-75929r3_rule'\n tag \"stig_id\": 'O121-BP-022600'\n tag \"fix_id\": 'F-67355r2_fix'\n tag \"cci\": ['CCI-000366']\n tag \"nist\": ['CM-6 b', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"A default Oracle Database installation provides a set of\n predefined administrative accounts and non-administrative accounts. These are\n accounts that have special privileges required to administer areas of the\n database, such as the “CREATE ANY TABLE” or “ALTER SESSION” privilege, or\n “EXECUTE” privileges on packages owned by the SYS schema. The default\n tablespace for administrative accounts is either “SYSTEM” or “SYSAUX”.\n Non-administrative user accounts only have the minimum privileges needed to\n perform their jobs. Their default tablespace is “USERS”.\n\n To protect these accounts from unauthorized access, the installation process\n expires and locks most of these accounts, except where noted below. The\n database administrator is responsible for unlocking and resetting these\n accounts, as required.\n\n Non-Administrative Accounts - Expired and locked:\n APEX_PUBLIC_USER, DIP, FLOWS_040100*, FLOWS_FILES, MDDATA, ORACLE_OCM,\n SPATIAL_CSW_ADMIN_USR, SPATIAL_WFS_ADMIN_USR, XS$NULL\n\n Administrative Accounts - Expired and Locked:\n ANONYMOUS, CTXSTS, EXFSYS, LBACSYS, MDSYS, OLAPSYS, OEDDATA, OWBSYS,\n ORDPLUGINS, ORDSYS, OUTLN, SI_INFORMTN_SCHEMA, WK_TEST, WK_SYS, WKPROXY, WMSYS,\n XDB\n\n Administrative Accounts - Open:\n DBSNMP, MGMT_VIEW, SYS, SYSMAN, SYSTEM\n\n * Subject to change based on version installed\n\n Run the SQL query:\n\n select owner ||'.'|| table_name ||':'|| privilege from dba_tab_privs\n where grantee = 'PUBLIC';\n and owner not in\n ();\n\n (With respect to the list of special accounts that are excluded from this\n requirement, it is expected that the DBA will maintain the list to suit local\n circumstances, adding special accounts as necessary and removing any that are\n not supposed to be in use in the Oracle deployment that is under review.)\n\n If there are any records returned that are not Oracle product accounts, and are\n not documented and authorized, this is a finding.\n\n Note: This check may return false positives where other Oracle product accounts\n are not included in the exclusion list.\"\n tag \"fix\": \"Revoke any privileges granted to PUBLIC for objects that are not\n owned by Oracle product accounts.\n\n From SQL*Plus:\n\n revoke [privilege name] from [user name] on [object name];\n\n Assign permissions to custom application user roles based on job functions:\n\n From SQL*Plus:\n\n grant [privilege name] to [user role] on [object name];\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n users_with_public_access = sql.query(\"select DISTINCT owner from dba_tab_privs where grantee = 'PUBLIC';\").column('owner').uniq\n\n if users_with_public_access.empty?\n impact 0.0\n describe 'There are no oracle users with access to PUBLIC, control N/A' do\n skip 'There are no oracle users with access to PUBLIC'\n end\n else\n users_with_public_access.each do |user|\n describe \"oracle user: #{user} with access to PUBLIC\" do\n subject { user }\n it { should be_in input('users_allowed_access_to_public')}\n end\n end\n end\nend\n", + "code": "control 'V-61537' do\n title \"DBA OS accounts must be granted only those host system privileges\n necessary for the administration of the DBMS.\"\n desc \"This requirement is intended to limit exposure due to operating from\n within a privileged account or role. The inclusion of role is intended to\n address those situations where an access control policy, such as Role Based\n Access Control (RBAC), is being implemented and where a change of role provides\n the same degree of assurance in the change of access authorizations for both\n the user and all processes acting on behalf of the user as would be provided by\n a change between a privileged and non-privileged account.\n\n DBAs, if assigned excessive OS privileges, could perform actions that could\n endanger the information system or hide evidence of malicious activity.\n \"\n impact 0.7\n tag \"gtitle\": 'SRG-APP-000063-DB-000021'\n tag \"gid\": 'V-61537'\n tag \"rid\": 'SV-76027r1_rule'\n tag \"stig_id\": 'O121-C1-004500'\n tag \"fix_id\": 'F-67453r1_fix'\n tag \"cci\": ['CCI-000366']\n tag \"nist\": ['CM-6 b', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Review host system privileges assigned to the Oracle DBA group\n and all individual Oracle DBA accounts.\n\n Note: do not include the Oracle software installation account in any results\n for this check.\n\n For UNIX systems (as root):\n cat /etc/group | grep -i dba\n groups root\n\n If \\\"root\\\" is returned in the first list, this is a finding.\n\n If any accounts listed in the first list are also listed in the second list,\n this is a finding.\n\n Investigate any user account group memberships other than DBA or root groups\n that are returned by the following command (also as root):\n\n groups [dba user account]\n\n Replace [dba user account] with the user account name of each DBA account.\n\n If individual DBA accounts are assigned to groups that grant access or\n privileges for purposes other than DBA responsibilities, this is a finding.\n\n For Windows Systems (click or select):\n Start / Settings / Control Panel / Administrative Tools / Computer Management /\n Local Users and Groups / Groups / ORA_DBA\n Start / Settings / Control Panel / Administrative Tools / Computer Management /\n Local Users and Groups / Groups / ORA_[SID]_DBA (if present)\n\n Note: Users assigned DBA privileges on a Windows host are granted membership in\n the ORA_DBA and/or ORA_[SID]_DBA groups. The ORA_DBA group grants DBA\n privileges to any database on the system. The ORA_[SID]_DBA groups grant DBA\n privileges to specific Oracle instances only.\n\n Make a note of each user listed. For each user (click or select):\n Start / Settings / Control Panel / Administrative Tools / Computer Management /\n Local Users and Groups / Users / [DBA user name] / Member of\n\n If DBA users belong to any groups other than DBA groups and the Windows Users\n group, this is a finding.\n\n Examine User Rights assigned to DBA groups or group members:\n Start / Settings / Control Panel / Administrative Tools / Local Security Policy\n / Security Settings / Local Policies / User Rights Assignments\n\n If any User Rights are assigned directly to the DBA group(s) or DBA user\n accounts, this is a finding.\"\n tag \"fix\": \"Revoke all host system privileges from the DBA group accounts and\n DBA user accounts not required for DBMS administration.\n\n Revoke all OS group memberships that assign excessive privileges to the DBA\n group accounts and DBA user accounts.\n\n Remove any directly applied permissions or user rights from the DBA group\n accounts and DBA user accounts.\n\n Document all DBA group accounts and individual DBA account-assigned privileges\n in the System Security Plan.\"\n\n get_dba_users = command('cat /etc/group | grep -i dba').stdout.strip.split(\"\\n\")\n get_members_root_group = command('groups root').stdout.strip.split(\"\\n\")\n\n get_dba_users.each do |user|\n describe \"The dba user: #{user} in /etc/group\" do\n subject { user }\n it { should_not cmp 'root' }\n end\n\n get_members_root_group.each do |member|\n describe \"The user: #{member} in the root group\" do\n subject { member }\n it { should_not cmp user.to_s }\n end\n end\n end\n if get_dba_users.empty?\n describe 'There are no dba users, therefore this control is NA' do\n skip 'There are no dba users, therefore this control is NA'\n end\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61439.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61537.rb", "line": 1 }, - "id": "V-61439" + "id": "V-61537" }, { - "title": "The system must protect audit tools from unauthorized modification.", - "desc": "Protecting audit data also includes identifying and protecting the\n tools used to view and manipulate log data.\n\n Depending upon the log format and application, system and application log\n tools may provide the only means to manipulate and manage application and\n system log data.\n\n If the tools are compromised it could provide attackers with the capability\n to manipulate log data. It is, therefore, imperative that audit tools be\n controlled and protected from unauthorized modification.\n\n Audit tools include, but are not limited to, OS provided audit tools,\n vendor provided audit tools, and open source audit tools needed to successfully\n view and manipulate audit information system activity and records.\n\n If an attacker were to gain access to audit tools he could analyze audit\n logs for system weaknesses or weaknesses in the auditing itself. An attacker\n could also manipulate logs to hide evidence of malicious activity.", + "title": "The DBMS must use multifactor authentication for local access to\n privileged accounts.", + "desc": "Multifactor authentication is defined as using two or more factors to\n achieve authentication.\n\n Factors include:\n (i) Something a user knows (e.g., password/PIN);\n (ii) Something a user has (e.g., cryptographic identification device,\n token); or\n (iii) Something a user is (e.g., biometric).\n\n A privileged account is defined as an information system account with\n authorizations of a privileged user.\n\n Local Access is defined as access to an organizational information system\n by a user (or process acting on behalf of a user) communicating through a\n direct connection without the use of a network.\n\n The lack of multifactor authentication makes it much easier for an attacker\n to gain unauthorized access to a system.\n\n Transport Layer Security (TLS) is the successor protocol to Secure Sockets\n Layer (SSL). Although the Oracle configuration parameters have names including\n 'SSL', such as SSL_VERSION and SSL_CIPHER_SUITES, they refer to TLS.", "descriptions": { - "default": "Protecting audit data also includes identifying and protecting the\n tools used to view and manipulate log data.\n\n Depending upon the log format and application, system and application log\n tools may provide the only means to manipulate and manage application and\n system log data.\n\n If the tools are compromised it could provide attackers with the capability\n to manipulate log data. It is, therefore, imperative that audit tools be\n controlled and protected from unauthorized modification.\n\n Audit tools include, but are not limited to, OS provided audit tools,\n vendor provided audit tools, and open source audit tools needed to successfully\n view and manipulate audit information system activity and records.\n\n If an attacker were to gain access to audit tools he could analyze audit\n logs for system weaknesses or weaknesses in the auditing itself. An attacker\n could also manipulate logs to hide evidence of malicious activity." + "default": "Multifactor authentication is defined as using two or more factors to\n achieve authentication.\n\n Factors include:\n (i) Something a user knows (e.g., password/PIN);\n (ii) Something a user has (e.g., cryptographic identification device,\n token); or\n (iii) Something a user is (e.g., biometric).\n\n A privileged account is defined as an information system account with\n authorizations of a privileged user.\n\n Local Access is defined as access to an organizational information system\n by a user (or process acting on behalf of a user) communicating through a\n direct connection without the use of a network.\n\n The lack of multifactor authentication makes it much easier for an attacker\n to gain unauthorized access to a system.\n\n Transport Layer Security (TLS) is the successor protocol to Secure Sockets\n Layer (SSL). Although the Oracle configuration parameters have names including\n 'SSL', such as SSL_VERSION and SSL_CIPHER_SUITES, they refer to TLS." }, "impact": 0, - "refs": [], + "refs": [ + { + "ref": [] + } + ], "tags": { - "gtitle": "SRG-APP-000122-DB-000203", - "gid": "V-61661", - "rid": "SV-76151r1_rule", - "stig_id": "O121-C2-009700", - "fix_id": "F-67575r1_fix", + "gtitle": "SRG-APP-000151-DB-000106", + "gid": "V-61707", + "rid": "SV-76197r2_rule", + "stig_id": "O121-C2-013100", + "fix_id": "F-67623r1_fix", "cci": [ - "CCI-001494" + "CCI-000767" ], "nist": [ - "AU-9", + "IA-2 (3)", "Rev_4" ], "false_negatives": null, @@ -379,35 +387,81 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Review access permissions to tools used to view or modify audit\n log data. These tools may include the DBMS itself or tools external to the\n database.\n\n If appropriate permissions and access controls are not applied to prevent\n unauthorized modification of these tools, this is a finding.", - "fix": "Add or modify access controls and permissions to tools used to\n view or modify audit log data. Tools must be modifiable by authorized personnel\n only." + "check": "Review DBMS settings, OS settings, and/or enterprise-level\n authentication/access mechanism settings to determine whether users logging on\n to privileged accounts locally are required to use multifactor authentication.\n\n If users logging on to privileged accounts locally are not required to use\n multifactor authentication, this is a finding.\n\n Use authentication to prove the identities of users who are attempting to log\n on to the database. Authenticating user identity is imperative in distributed\n environments, without which there can be little confidence in network security.\n Passwords are the most common means of authentication. Oracle Database enables\n strong authentication with Oracle authentication adapters that support various\n third-party authentication services, including TLS with digital certificates.\n\n If the $ORACLE_HOME/network/admin/sqlnet.ora contains entries similar to the\n following, TLS is enabled.\n (Note: This assumes that a single sqlnet.ora file, in the default location, is\n in use. Please see the supplemental file \"Non-default sqlnet.ora\n configurations.pdf\" for how to find multiple and/or differently located\n sqlnet.ora files.)\n\n SQLNET.AUTHENTICATION_SERVICES= (BEQ, TCPS)\n SSL_VERSION = 1.2 or 1.1\n SSL_CLIENT_AUTHENTICATION = TRUE\n WALLET_LOCATION =\n (SOURCE =\n (METHOD = FILE)\n (METHOD_DATA =\n (DIRECTORY = /u01/app/oracle/product/12.1.0/dbhome_1/owm/wallets)\n )\n )\n\n SSL_CIPHER_SUITES= (SSL_RSA_WITH_AES_256_CBC_SHA384)\n ADR_BASE = /u01/app/oracle\n\n Note: \"SSL_VERSION = 1.2 or 1.1\" is the actual value, not a suggestion to\n use one or the other.", + "fix": "Configure DBMS, OS and/or enterprise-level authentication/access\n mechanism to require multifactor authentication for local users logging on to\n privileged accounts.\n\n If appropriate, enable support for Transport Layer Security (TLS) protocols and\n multifactor authentication through the use of Smart Cards (CAC/PIV)." }, - "code": "control 'V-61661' do\n title 'The system must protect audit tools from unauthorized modification.'\n desc \"Protecting audit data also includes identifying and protecting the\n tools used to view and manipulate log data.\n\n Depending upon the log format and application, system and application log\n tools may provide the only means to manipulate and manage application and\n system log data.\n\n If the tools are compromised it could provide attackers with the capability\n to manipulate log data. It is, therefore, imperative that audit tools be\n controlled and protected from unauthorized modification.\n\n Audit tools include, but are not limited to, OS provided audit tools,\n vendor provided audit tools, and open source audit tools needed to successfully\n view and manipulate audit information system activity and records.\n\n If an attacker were to gain access to audit tools he could analyze audit\n logs for system weaknesses or weaknesses in the auditing itself. An attacker\n could also manipulate logs to hide evidence of malicious activity.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000122-DB-000203'\n tag \"gid\": 'V-61661'\n tag \"rid\": 'SV-76151r1_rule'\n tag \"stig_id\": 'O121-C2-009700'\n tag \"fix_id\": 'F-67575r1_fix'\n tag \"cci\": ['CCI-001494']\n tag \"nist\": ['AU-9', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Review access permissions to tools used to view or modify audit\n log data. These tools may include the DBMS itself or tools external to the\n database.\n\n If appropriate permissions and access controls are not applied to prevent\n unauthorized modification of these tools, this is a finding.\"\n tag \"fix\": \"Add or modify access controls and permissions to tools used to\n view or modify audit log data. Tools must be modifiable by authorized personnel\n only.\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n users_allowed_access_to_audit_info = sql.query(\"SELECT GRANTEE, TABLE_NAME, PRIVILEGE\n FROM DBA_TAB_PRIVS where owner='AUDSYS';\").column('grantee').uniq\n if users_allowed_access_to_audit_info.empty?\n impact 0.0\n describe 'There are no oracle users allowed access to audit information, control N/A' do\n skip 'There are no oracle users allowed access to audit information'\n end\n else\n users_allowed_access_to_audit_info.each do |user|\n describe \"oracle users: #{user} allowed access to audit information\" do\n subject { user }\n it { should be_in input('allowed_audit_users') }\n end\n end\n end\nend\n", + "code": " control 'V-61707' do\n impact 0.0\n describe 'This control is not applicable on oracle within aws rds, as aws manages the operating system in which the oracle database is running on' do\n skip 'This control is not applicable on oracle within aws rds, as aws manages the operating system in which the oracle database is running on'\n end\n end\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61661.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61707.rb", "line": 1 }, - "id": "V-61661" + "id": "V-61707" }, { - "title": "The DBMS must only generate error messages that provide information\n necessary for corrective actions without revealing organization-defined\n sensitive or potentially harmful information in error logs and administrative\n messages that could be exploited.", - "desc": "Any application providing too much information in error logs and in\n administrative messages to the screen risks compromising the data and security\n of the application and system. The structure and content of error messages\n needs to be carefully considered by the organization and development team.\n\n The extent to which the application is able to identify and handle error\n conditions is guided by organizational policy and operational requirements.\n Sensitive information includes account numbers, social security numbers, and\n credit card numbers.\n\n Databases can inadvertently provide a wealth of information to an attacker\n through improperly handled error messages. In addition to sensitive business or\n personal information, database errors can provide host names, IP addresses,\n user names, and other system information not required for troubleshooting but\n very useful to someone targeting the system.\n\n This calls for inspection of application source code, which will require\n collaboration with the application developers. It is recognized that in many\n cases, the database administrator (DBA) is organizationally separate from the\n application developers and may have limited, if any, access to source code.\n Nevertheless, protections of this type are so important to the secure operation\n of databases that they must not be ignored. At a minimum, the DBA must attempt\n to obtain assurances from the development organization that this issue has been\n addressed and must document what has been discovered.", + "title": "DBMS processes or services must run under custom, dedicated OS\n accounts.", + "desc": "Separation of duties is a prevalent Information Technology control\n that is implemented at different layers of the information system, including\n the operating system and in applications. It serves to eliminate or reduce the\n possibility that a single user may carry out a prohibited action. Separation of\n duties requires that the person accountable for approving an action is not the\n same person who is tasked with implementing or carrying out that action.\n\n The DBMS must run under a custom dedicated OS account. When the DBMS is\n running under a shared account, users with access to that account could\n inadvertently or maliciously make changes to the DBMS's settings, files, or\n permissions.", "descriptions": { - "default": "Any application providing too much information in error logs and in\n administrative messages to the screen risks compromising the data and security\n of the application and system. The structure and content of error messages\n needs to be carefully considered by the organization and development team.\n\n The extent to which the application is able to identify and handle error\n conditions is guided by organizational policy and operational requirements.\n Sensitive information includes account numbers, social security numbers, and\n credit card numbers.\n\n Databases can inadvertently provide a wealth of information to an attacker\n through improperly handled error messages. In addition to sensitive business or\n personal information, database errors can provide host names, IP addresses,\n user names, and other system information not required for troubleshooting but\n very useful to someone targeting the system.\n\n This calls for inspection of application source code, which will require\n collaboration with the application developers. It is recognized that in many\n cases, the database administrator (DBA) is organizationally separate from the\n application developers and may have limited, if any, access to source code.\n Nevertheless, protections of this type are so important to the secure operation\n of databases that they must not be ignored. At a minimum, the DBA must attempt\n to obtain assurances from the development organization that this issue has been\n addressed and must document what has been discovered." + "default": "Separation of duties is a prevalent Information Technology control\n that is implemented at different layers of the information system, including\n the operating system and in applications. It serves to eliminate or reduce the\n possibility that a single user may carry out a prohibited action. Separation of\n duties requires that the person accountable for approving an action is not the\n same person who is tasked with implementing or carrying out that action.\n\n The DBMS must run under a custom dedicated OS account. When the DBMS is\n running under a shared account, users with access to that account could\n inadvertently or maliciously make changes to the DBMS's settings, files, or\n permissions." + }, + "impact": 0, + "refs": [ + { + "ref": [] + } + ], + "tags": { + "gtitle": "SRG-APP-000062-DB-000010", + "gid": "V-61579", + "rid": "SV-76069r1_rule", + "stig_id": "O121-C2-003400", + "fix_id": "F-67495r1_fix", + "cci": [ + "CCI-000366", + "CCI-002220" + ], + "nist": [ + "AC-5 c", + "Rev_4" + ], + "false_negatives": null, + "false_positives": null, + "documentable": false, + "mitigations": null, + "severity_override_guidance": false, + "potential_impacts": null, + "third_party_tools": null, + "mitigation_controls": null, + "responsibility": null, + "ia_controls": null, + "check": "Check OS settings to determine whether DBMS processes are\n running under a dedicated OS account. If the DBMS processes are running under\n shared accounts, this is a finding.\n\n This is done by the default installation. The installation documentation\n recommends that a user account named ORACLE is created and is identified as the\n software owner.\n\n Log on to the system as the software owner, typically ORACLE, the $ORACLE_HOME\n environment variable will point to the Oracle software. Enter the following\n commands to see if ORACLE is the software owner:\n\n $ cd $ORACLE_HOME\n $ ls -l (shows the directories - oracle is the owner and oinstall is the group.\n The example list below has been truncated)\n drwxr-xr-x 2 oracle oinstall 4096 Nov 21 08:42 addnode\n drwxr-xr-x 8 oracle oinstall 4096 Nov 21 08:41 apex\n drwxr-xr-x 9 oracle oinstall 4096 Nov 21 08:39 assistants\n drwxr-xr-x 2 oracle oinstall 4096 Nov 21 09:17 bin\n drwxr-xr-x 7 oracle oinstall 4096 Nov 21 08:42 ccr\n drwxr-xr-x 3 oracle oinstall 4096 Nov 21 08:42 cdata\n drwxr-xr-x 5 oracle oinstall 4096 Nov 21 09:04 cfgtoollogs\n drwxr-xr-x 4 oracle oinstall 4096 Nov 21 08:42 clone\n drwxr-xr-x 6 oracle oinstall 4096 Nov 21 08:39 crs\n drwxr-xr-x 6 oracle oinstall 4096 Nov 21 08:42 css\n drwxr-xr-x 11 oracle oinstall 4096 Nov 21 08:42 ctx\n drwxr-xr-x 7 oracle oinstall 4096 Nov 21 08:39 cv\n drwxr-xr-x 2 oracle oinstall 4096 Dec 16 13:11 dbs\n drwxr-xr-x 2 oracle oinstall 4096 Nov 21 08:42 dc_ocm\n drwxr-xr-x 5 oracle oinstall 4096 Nov 21 08:45 deinstall\n drwxr-xr-x 3 oracle oinstall 4096 Nov 21 08:39 demo\n drwxr-xr-x 3 oracle oinstall 4096 Nov 21 08:39 diagnostics\n\n $ ps -ef | grep ora_ (shows all of the oracle processes owned by the oracle\n user. The example list below has been truncated)\n\n oracle 1786 1 0 13:11 ? 00:00:00 ora_pmon_stig\n oracle 1788 1 0 13:11 ? 00:00:00 ora_psp0_stig\n oracle 1790 1 1 13:11 ? 00:00:08 ora_vktm_stig\n oracle 1794 1 0 13:11 ? 00:00:00 ora_gen0_stig\n oracle 1796 1 0 13:11 ? 00:00:00 ora_mman_stig\n oracle 1800 1 0 13:11 ? 00:00:00 ora_diag_stig\n oracle 1802 1 0 13:11 ? 00:00:00 ora_dbrm_stig\n oracle 1804 1 0 13:11 ? 00:00:00 ora_vkrm_stig\n oracle 1806 1 0 13:11 ? 00:00:00 ora_dia0_stig\n oracle 1808 1 0 13:11 ? 00:00:00 ora_dbw0_stig\n oracle 1810 1 0 13:11 ? 00:00:00 ora_lgwr_stig\n oracle 1812 1 0 13:11 ? 00:00:00 ora_ckpt_stig\n oracle 1814 1 0 13:11 ? 00:00:00 ora_lg00_stig\n oracle 1816 1 0 13:11 ? 00:00:00 ora_smon_stig\n oracle 1818 1 0 13:11 ? 00:00:00 ora_lg01_stig\n oracle 1820 1 0 13:11 ? 00:00:00 ora_reco_stig\n oracle 1822 1 0 13:11 ? 00:00:00 ora_lreg_stig\n oracle 1824 1 0 13:11 ? 00:00:00 ora_pxmn_stig\n oracle 2137 2125 0 13:25 pts/1 00:00:00 grep ora_", + "fix": "Create an OS account dedicated to Oracle DBMS processes, and\n allow only Oracle DBMS processes to run under the account." + }, + "code": " control 'V-61579' do\n impact 0.0\n describe 'This control is not applicable on oracle within aws rds, as aws manages the operating system in which the oracle database is running on' do\n skip 'This control is not applicable on oracle within aws rds, as aws manages the operating system in which the oracle database is running on'\n end\n end\n", + "source_location": { + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61579.rb", + "line": 1 + }, + "id": "V-61579" + }, + { + "title": "The DBMS must terminate user sessions upon user logoff or any other\n organization or policy-defined session termination events, such as idle time\n limit exceeded.", + "desc": "This requirement focuses on communications protection at the\n application session, versus network packet, level.\n\n Session IDs are tokens generated by web applications to uniquely identify\n an application user's session. Applications will make application decisions\n and execute business logic based on the session ID. Unique session identifiers\n or IDs are the opposite of sequentially generated session IDs, which can be\n easily guessed by an attacker. Unique session IDs help to reduce predictability\n of said identifiers. Unique session IDs address man-in-the-middle attacks,\n including session hijacking or insertion of false information into a session.\n If the attackers are unable to identify or guess the session information\n related to pending application traffic, they will have more difficulty in\n hijacking the session or otherwise manipulating valid sessions. When a user\n logs out, or when any other session termination event occurs, the application\n must terminate the user session to minimize the potential for an attacker to\n hijack that particular user session.\n\n Database sessions must be terminated when no longer in use in order to\n prevent session hijacking.", + "descriptions": { + "default": "This requirement focuses on communications protection at the\n application session, versus network packet, level.\n\n Session IDs are tokens generated by web applications to uniquely identify\n an application user's session. Applications will make application decisions\n and execute business logic based on the session ID. Unique session identifiers\n or IDs are the opposite of sequentially generated session IDs, which can be\n easily guessed by an attacker. Unique session IDs help to reduce predictability\n of said identifiers. Unique session IDs address man-in-the-middle attacks,\n including session hijacking or insertion of false information into a session.\n If the attackers are unable to identify or guess the session information\n related to pending application traffic, they will have more difficulty in\n hijacking the session or otherwise manipulating valid sessions. When a user\n logs out, or when any other session termination event occurs, the application\n must terminate the user session to minimize the potential for an attacker to\n hijack that particular user session.\n\n Database sessions must be terminated when no longer in use in order to\n prevent session hijacking." }, "impact": 0.5, "refs": [], "tags": { - "gtitle": "SRG-APP-000266-DB-000162", - "gid": "V-61791", - "rid": "SV-76281r2_rule", - "stig_id": "O121-C2-019900", - "fix_id": "F-67707r1_fix", + "gtitle": "SRG-APP-000220-DB-000149", + "gid": "V-61765", + "rid": "SV-76255r2_rule", + "stig_id": "O121-C2-017600", + "fix_id": "F-67681r4_fix", "cci": [ - "CCI-001312" + "CCI-001185" ], "nist": [ - "SI-11 a", + "SC-23 (1)", "Rev_4" ], "false_negatives": null, @@ -420,21 +474,21 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Check DBMS settings and custom database and application code to\n verify error messages do not contain information beyond what is needed for\n troubleshooting the issue.\n\n If database errors contain PII data, sensitive business data, or information\n useful for identifying the host system, this is a finding.\n\n Notes on Oracle's approach to this issue: Out of the box, Oracle covers this.\n For example, if a user does not have access to a table, the error is just that\n the table or view does not exist. The Oracle database is not going to display a\n Social Security Number in an error code unless an application is programmed to\n do so. Oracle applications will not expose the actual transactional data to a\n screen. The only way Oracle will capture this information is to enable\n specific logging levels. Custom code would require a review to ensure\n compliance.", - "fix": "Configure DBMS and custom database and application code not to\n divulge sensitive information or information useful for system identification\n in error information." + "check": "Review DBMS settings and vendor documentation to verify user\n sessions are terminated upon user logout. If they are not, this is a finding.\n\n Review system documentation and organization policy to identify other events\n that should result in session terminations. If other session termination events\n are defined, review DBMS settings to verify occurrences of these events would\n cause session termination.\n\n If occurrences of defined session-terminating events do not cause session\n terminations, this is a finding.\n\n When a user logs off of an Oracle session gracefully or has the session\n terminated for an idle timeout or any other reason, the session is terminated,\n and the resources are returned to the system. Check with the DBA to see what\n mechanism is used to disconnect the session and what events the site uses to\n determine if a connection needs to be terminated.\n\n To test for timeout, open a connection and leave it idle for a period greater\n than the defined idle timeout setting enforced by the system. Then try to use\n the connection. If the connection is no longer active, then the mechanism\n deployed to terminate the connection is active and working.", + "fix": "Configure DBMS settings to terminate sessions upon user logoff.\n Configure DBMS settings to terminate sessions upon the occurrence of any\n organization or policy-defined session termination event.\n\n - - - - -\n\n To configure specific session termination processes, we need to define the\n organization or policy-defined session termination event. Below are some\n examples.\n\n Oracle has several ways to disconnect idle sessions, both from within SQL*Plus\n via resources profiles (connect_time, idle_time) and with the SQL*net expire\n time parameter.\n\n Can use profiles to set the connect time and idle time with \"alter profile\"\n statements:\n\n alter profile senior_claim_analyst limit\n connect_time 15\n sessions_per_user 2\n ldle_time 10;\n\n Profiles comprise a named set of resource limits. By default, when users are\n created, they are given the default profile, which provides unlimited use of\n all resources.\n\n The syntax to create a profile follows:\n\n CREATE PROFILE LIMIT resource_parameters|password_parameters;\n Resource_parameters:\n [SESSIONS_PER_USER n|UNLIMITED|DEFAULT]\n [CPU_PER_SESSION n|UNLIMITED|DEFAULT]\n [CPU_PER_CALL n|UNLIMITED|DEFAULT]\n [CONNECT_TIME n|UNLIMITED|DEFAULT]\n [IDLE_TIME n|UNLIMITED|DEFAULT]\n\n By setting resource limits, can prevent users from performing operations that\n will tie up the system and prevent other users from performing operations. Can\n use resource limits for security, to ensure that users log off the system, so\n as not to leave the session connected for long periods of time.\n\n The system resource limits can be enforced at the session level, the call\n level, or both. The session level is calculated from the time the user logs on\n to the database until the user exits. The call level applies to each SQL\n command issued. Session-level limits are enforced for each connection. When a\n session-level limit is exceeded, only the last SQL command issued is rolled\n back; no further work can be performed until a commit, rollback, or exit is\n performed.\n\n Using SQLNET.EXPIRE_TIME\n\n The sqlnet.expire_time parameter is used to set a time interval, in minutes, to\n determine how often a probe should be sent verifying that client/server\n connections are active. If there is a need to ensure that connections are not\n left open indefinitely (or up to the time set by operating system-specific\n parameters), set a value that is greater than 0. This protects the system from\n connections left open due to an abnormal client termination.\n\n When the probe detects a terminated connection or a connection no longer in\n use, it signals an error, causing the server process to exit. This setting is\n intended for use on the database server side of the connection, which usually\n handles multiple connections at any one time. Limitations on using this\n terminated (dead) connection detection feature are:\n\n sqlnet.expire_time cannot be used on bequeathed connections.\n\n The SQL*Net expire_time probe packet will generate additional network traffic\n that may downgrade the network's performance, depending on the number of\n connections.\n\n Depending on the operating system that is in use, additional server processing\n may need to be performed to distinguish the connection probe from other events\n that occur. This overhead for detection of probe events can result in\n downgraded network performance.\n\n Turning-on expire_time\n\n To set up these advanced features, simply edit the sqlnet.ora file. If a\n beginner, follow this procedure:\n\n Start the Oracle Network Manager GUI.\n\n In the GUI navigator pane, expand the icons Local >> Profile.\n\n From the list on the right-hand pane, select General.\n\n Click on the Advanced tab.\n\n Next, enter the values for the fields or options to set.\n\n When finished, choose File >> Save Network Configuration to write the changes\n to the sqlnet.ora file. (Note: This assumes that a single sqlnet.ora file, in\n the default location, is in use. Please see the supplemental file \"Non-default\n sqlnet.ora configurations.pdf\" for how to find multiple and/or differently\n located sqlnet.ora files.)\n\n The sqlnet.ora inbound_connect_timeout parameter\n\n The sqlnet.ora inbound_connect_timeout parameter is used to limit the time, set\n in seconds, for a client to connect with the database server and provide the\n required authentication information.\n\n Also see sqlnet.inbound_connect_timeout tips.\n\n To limit consumption of Oracle resources by unauthorized users and enable an\n audit trail, should set time-limit values for the\n sqlnet.inbound_connect_timeout parameter in wall-clock seconds. (This parameter\n does not have default values.) Failure resulting from\n sqlnet.inbound_connect_timeout will throw an ORA-03136 inbound connection timed\n out error. " }, - "code": "control 'V-61791' do\n title \"The DBMS must only generate error messages that provide information\n necessary for corrective actions without revealing organization-defined\n sensitive or potentially harmful information in error logs and administrative\n messages that could be exploited.\"\n desc \"Any application providing too much information in error logs and in\n administrative messages to the screen risks compromising the data and security\n of the application and system. The structure and content of error messages\n needs to be carefully considered by the organization and development team.\n\n The extent to which the application is able to identify and handle error\n conditions is guided by organizational policy and operational requirements.\n Sensitive information includes account numbers, social security numbers, and\n credit card numbers.\n\n Databases can inadvertently provide a wealth of information to an attacker\n through improperly handled error messages. In addition to sensitive business or\n personal information, database errors can provide host names, IP addresses,\n user names, and other system information not required for troubleshooting but\n very useful to someone targeting the system.\n\n This calls for inspection of application source code, which will require\n collaboration with the application developers. It is recognized that in many\n cases, the database administrator (DBA) is organizationally separate from the\n application developers and may have limited, if any, access to source code.\n Nevertheless, protections of this type are so important to the secure operation\n of databases that they must not be ignored. At a minimum, the DBA must attempt\n to obtain assurances from the development organization that this issue has been\n addressed and must document what has been discovered.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000266-DB-000162'\n tag \"gid\": 'V-61791'\n tag \"rid\": 'SV-76281r2_rule'\n tag \"stig_id\": 'O121-C2-019900'\n tag \"fix_id\": 'F-67707r1_fix'\n tag \"cci\": ['CCI-001312']\n tag \"nist\": ['SI-11 a', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Check DBMS settings and custom database and application code to\n verify error messages do not contain information beyond what is needed for\n troubleshooting the issue.\n\n If database errors contain PII data, sensitive business data, or information\n useful for identifying the host system, this is a finding.\n\n Notes on Oracle's approach to this issue: Out of the box, Oracle covers this.\n For example, if a user does not have access to a table, the error is just that\n the table or view does not exist. The Oracle database is not going to display a\n Social Security Number in an error code unless an application is programmed to\n do so. Oracle applications will not expose the actual transactional data to a\n screen. The only way Oracle will capture this information is to enable\n specific logging levels. Custom code would require a review to ensure\n compliance.\"\n tag \"fix\": \"Configure DBMS and custom database and application code not to\n divulge sensitive information or information useful for system identification\n in error information.\"\n describe 'A manual review is required to ensure the DBMS only generates error messages that provide information\n necessary for corrective actions without revealing organization-defined\n sensitive or potentially harmful information in error logs and administrative\n messages that could be exploited.' do\n skip 'A manual review is required to ensure the DBMS only generates error messages that provide information\n necessary for corrective actions without revealing organization-defined\n sensitive or potentially harmful information in error logs and administrative\n messages that could be exploited.'\n end\nend\n", + "code": "control 'V-61765' do\n title \"The DBMS must terminate user sessions upon user logoff or any other\n organization or policy-defined session termination events, such as idle time\n limit exceeded.\"\n desc \"This requirement focuses on communications protection at the\n application session, versus network packet, level.\n\n Session IDs are tokens generated by web applications to uniquely identify\n an application user's session. Applications will make application decisions\n and execute business logic based on the session ID. Unique session identifiers\n or IDs are the opposite of sequentially generated session IDs, which can be\n easily guessed by an attacker. Unique session IDs help to reduce predictability\n of said identifiers. Unique session IDs address man-in-the-middle attacks,\n including session hijacking or insertion of false information into a session.\n If the attackers are unable to identify or guess the session information\n related to pending application traffic, they will have more difficulty in\n hijacking the session or otherwise manipulating valid sessions. When a user\n logs out, or when any other session termination event occurs, the application\n must terminate the user session to minimize the potential for an attacker to\n hijack that particular user session.\n\n Database sessions must be terminated when no longer in use in order to\n prevent session hijacking.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000220-DB-000149'\n tag \"gid\": 'V-61765'\n tag \"rid\": 'SV-76255r2_rule'\n tag \"stig_id\": 'O121-C2-017600'\n tag \"fix_id\": 'F-67681r4_fix'\n tag \"cci\": ['CCI-001185']\n tag \"nist\": ['SC-23 (1)', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Review DBMS settings and vendor documentation to verify user\n sessions are terminated upon user logout. If they are not, this is a finding.\n\n Review system documentation and organization policy to identify other events\n that should result in session terminations. If other session termination events\n are defined, review DBMS settings to verify occurrences of these events would\n cause session termination.\n\n If occurrences of defined session-terminating events do not cause session\n terminations, this is a finding.\n\n When a user logs off of an Oracle session gracefully or has the session\n terminated for an idle timeout or any other reason, the session is terminated,\n and the resources are returned to the system. Check with the DBA to see what\n mechanism is used to disconnect the session and what events the site uses to\n determine if a connection needs to be terminated.\n\n To test for timeout, open a connection and leave it idle for a period greater\n than the defined idle timeout setting enforced by the system. Then try to use\n the connection. If the connection is no longer active, then the mechanism\n deployed to terminate the connection is active and working.\"\n tag \"fix\": \"Configure DBMS settings to terminate sessions upon user logoff.\n Configure DBMS settings to terminate sessions upon the occurrence of any\n organization or policy-defined session termination event.\n\n - - - - -\n\n To configure specific session termination processes, we need to define the\n organization or policy-defined session termination event. Below are some\n examples.\n\n Oracle has several ways to disconnect idle sessions, both from within SQL*Plus\n via resources profiles (connect_time, idle_time) and with the SQL*net expire\n time parameter.\n\n Can use profiles to set the connect time and idle time with \\\"alter profile\\\"\n statements:\n\n alter profile senior_claim_analyst limit\n connect_time 15\n sessions_per_user 2\n ldle_time 10;\n\n Profiles comprise a named set of resource limits. By default, when users are\n created, they are given the default profile, which provides unlimited use of\n all resources.\n\n The syntax to create a profile follows:\n\n CREATE PROFILE LIMIT resource_parameters|password_parameters;\n Resource_parameters:\n [SESSIONS_PER_USER n|UNLIMITED|DEFAULT]\n [CPU_PER_SESSION n|UNLIMITED|DEFAULT]\n [CPU_PER_CALL n|UNLIMITED|DEFAULT]\n [CONNECT_TIME n|UNLIMITED|DEFAULT]\n [IDLE_TIME n|UNLIMITED|DEFAULT]\n\n By setting resource limits, can prevent users from performing operations that\n will tie up the system and prevent other users from performing operations. Can\n use resource limits for security, to ensure that users log off the system, so\n as not to leave the session connected for long periods of time.\n\n The system resource limits can be enforced at the session level, the call\n level, or both. The session level is calculated from the time the user logs on\n to the database until the user exits. The call level applies to each SQL\n command issued. Session-level limits are enforced for each connection. When a\n session-level limit is exceeded, only the last SQL command issued is rolled\n back; no further work can be performed until a commit, rollback, or exit is\n performed.\n\n Using SQLNET.EXPIRE_TIME\n\n The sqlnet.expire_time parameter is used to set a time interval, in minutes, to\n determine how often a probe should be sent verifying that client/server\n connections are active. If there is a need to ensure that connections are not\n left open indefinitely (or up to the time set by operating system-specific\n parameters), set a value that is greater than 0. This protects the system from\n connections left open due to an abnormal client termination.\n\n When the probe detects a terminated connection or a connection no longer in\n use, it signals an error, causing the server process to exit. This setting is\n intended for use on the database server side of the connection, which usually\n handles multiple connections at any one time. Limitations on using this\n terminated (dead) connection detection feature are:\n\n sqlnet.expire_time cannot be used on bequeathed connections.\n\n The SQL*Net expire_time probe packet will generate additional network traffic\n that may downgrade the network's performance, depending on the number of\n connections.\n\n Depending on the operating system that is in use, additional server processing\n may need to be performed to distinguish the connection probe from other events\n that occur. This overhead for detection of probe events can result in\n downgraded network performance.\n\n Turning-on expire_time\n\n To set up these advanced features, simply edit the sqlnet.ora file. If a\n beginner, follow this procedure:\n\n Start the Oracle Network Manager GUI.\n\n In the GUI navigator pane, expand the icons Local >> Profile.\n\n From the list on the right-hand pane, select General.\n\n Click on the Advanced tab.\n\n Next, enter the values for the fields or options to set.\n\n When finished, choose File >> Save Network Configuration to write the changes\n to the sqlnet.ora file. (Note: This assumes that a single sqlnet.ora file, in\n the default location, is in use. Please see the supplemental file \\\"Non-default\n sqlnet.ora configurations.pdf\\\" for how to find multiple and/or differently\n located sqlnet.ora files.)\n\n The sqlnet.ora inbound_connect_timeout parameter\n\n The sqlnet.ora inbound_connect_timeout parameter is used to limit the time, set\n in seconds, for a client to connect with the database server and provide the\n required authentication information.\n\n Also see sqlnet.inbound_connect_timeout tips.\n\n To limit consumption of Oracle resources by unauthorized users and enable an\n audit trail, should set time-limit values for the\n sqlnet.inbound_connect_timeout parameter in wall-clock seconds. (This parameter\n does not have default values.) Failure resulting from\n sqlnet.inbound_connect_timeout will throw an ORA-03136 inbound connection timed\n out error. \"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n query_idle_time = %{\n SELECT PROFILE, RESOURCE_NAME, LIMIT FROM DBA_PROFILES WHERE PROFILE =\n '%s' AND RESOURCE_NAME = 'IDLE_TIME'\n }\n\n query_sessions_per_user = %{\n SELECT PROFILE, RESOURCE_NAME, LIMIT FROM DBA_PROFILES WHERE PROFILE =\n '%s' AND RESOURCE_NAME = 'SESSIONS_PER_USER'\n }\n\n query_connect_time = %{\n SELECT PROFILE, RESOURCE_NAME, LIMIT FROM DBA_PROFILES WHERE PROFILE =\n '%s' AND RESOURCE_NAME = 'CONNECT_TIME'\n }\n\n user_profiles = sql.query('SELECT profile FROM dba_users;').column('profile').uniq\n\n user_profiles.each do |profile|\n idle_time = sql.query(format(query_idle_time, profile: profile)).column('limit')\n sessions_per_user = sql.query(format(query_sessions_per_user, profile: profile)).column('limit')\n connect_time = sql.query(format(query_connect_time, profile: profile)).column('limit')\n\n describe \"The oracle database idle time for profile: #{profile}\" do\n subject { idle_time }\n it { should cmp <= 15 }\n end\n\n describe \"The oracle database number of sessions per user for profile: #{profile}\" do\n subject { sessions_per_user }\n it { should cmp <= 3 }\n end\n\n describe \"The oracle database connect time for profile: #{profile}\" do\n subject { connect_time }\n it { should cmp <= 15 }\n end\n end\n if user_profiles.empty?\n describe 'There are no user profiles, therefore this control is NA' do\n skip 'There are no user profiles, therefore this control is NA'\n end\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61791.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61765.rb", "line": 1 }, - "id": "V-61791" + "id": "V-61765" }, { - "title": "Remote administration must be disabled for the Oracle connection\n manager.", - "desc": "Remote administration provides a potential opportunity for malicious\n users to make unauthorized changes to the Connection Manager configuration or\n interrupt its service.", + "title": "Network access to the DBMS must be restricted to authorized personnel.", + "desc": "Restricting remote access to specific, trusted systems helps prevent\n access by unauthorized and potentially malicious users.", "descriptions": { - "default": "Remote administration provides a potential opportunity for malicious\n users to make unauthorized changes to the Connection Manager configuration or\n interrupt its service." + "default": "Restricting remote access to specific, trusted systems helps prevent\n access by unauthorized and potentially malicious users." }, "impact": 0, "refs": [ @@ -444,10 +498,10 @@ ], "tags": { "gtitle": "SRG-APP-000516-DB-999900", - "gid": "V-61533", - "rid": "SV-76023r1_rule", - "stig_id": "O121-BP-026500", - "fix_id": "F-67449r1_fix", + "gid": "V-61515", + "rid": "SV-76005r2_rule", + "stig_id": "O121-BP-025600", + "fix_id": "F-67431r1_fix", "cci": [ "CCI-000366" ], @@ -465,39 +519,39 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "View the cman.ora file in the ORACLE_HOME/network/admin\n directory.\n\n If the file does not exist, the database is not accessed via Oracle Connection\n Manager and this check is not a finding.\n\n If the entry and value for REMOTE_ADMIN is not listed or is not set to a value\n of NO (REMOTE_ADMIN = NO), this is a finding.", - "fix": "View the cman.ora file in the ORACLE_HOME/network/admin directory\n of the Connection Manager.\n\n Include the following line in the file:\n\n REMOTE_ADMIN = NO" + "check": "IP address restriction may be defined for the database\n listener, by use of the Oracle Connection Manager or by an external network\n device.\n\n Identify the method used to enforce address restriction (interview or System\n Security Plan review).\n\n If enforced by the database listener, then review the SQLNET.ORA file located\n in the ORACLE_HOME/network/admin directory (note: this assumes that a single\n sqlnet.ora file, in the default location, is in use; please see the\n supplemental file \"Non-default sqlnet.ora configurations.pdf\" for how to find\n multiple and/or differently located sqlnet.ora files) or the directory\n indicated by the TNS_ADMIN environment variable or registry setting.\n\n If the following entries do not exist, then restriction by IP address is not\n configured and is a finding.\n\n tcp.validnode_checking=YES\n tcp.invited_nodes=(IP1, IP2, IP3)\n\n If enforced by an Oracle Connection Manager, then review the CMAN.ORA file for\n the Connection Manager (located in the TNS_ADMIN or ORACLE_HOME/network/admin\n directory for the connection manager).\n\n If a RULE entry allows all addresses (\"/32\") or does not match the address\n range specified in the System Security Plan, this is a finding.\n\n (rule=(src=[IP]/27)(dst=[IP])(srv=*)(act=accept))\n\n Note: an IP address with a \"/\" indicates acceptance by subnet mask where the\n number after the \"/\" is the left most number of bits in the address that must\n match for the rule to apply.\n\n If this rule is database-specific, then determine if the SERVICE_NAMES\n parameter is set:\n\n From SQL*PLUS:\n\n select value from v$parameter where name = 'service_names';\n\n If SERVICE_NAMES is set in the initialization file for the database instance,\n use (srv=[service name]), else, use (srv=*) if not set or rule applies to all\n databases on the DBMS server.\n\n If network access restriction is performed by an external device, validate ACLs\n are in place to prohibit unauthorized access to the DBMS. To do this, find the\n IP address of the database server (destination address) and source address\n (authorized IPs) in the System Security Plan. Confirm only authorized IPs from\n the System Security Plan are allowed access to the DBMS.", + "fix": "Configure the database listener to restrict access by IP address\n or set up an external device to restrict network access to the DBMS." }, - "code": " control 'V-61533' do\n impact 0.0\n describe 'This control is not applicable on oracle within aws rds, as aws manages the operating system in which the oracle database is running on' do\n skip 'This control is not applicable on oracle within aws rds, as aws manages the operating system in which the oracle database is running on'\n end\n end\n", + "code": " control 'V-61515' do\n impact 0.0\n describe 'This control is not applicable on oracle within aws rds, as aws manages the operating system in which the oracle database is running on' do\n skip 'This control is not applicable on oracle within aws rds, as aws manages the operating system in which the oracle database is running on'\n end\n end\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61533.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61515.rb", "line": 1 }, - "id": "V-61533" + "id": "V-61515" }, { - "title": "The DBMS, when utilizing PKI-based authentication, must validate\n certificates by constructing a certification path with status information to an\n accepted trust anchor.", - "desc": "A trust anchor is an authoritative entity represented via a public key\n and associated data. It is used in the context of public key infrastructures,\n X.509 digital certificates, and DNSSEC.\n\n When there is a chain of trust, usually the top entity to be trusted\n becomes the trust anchor; it can be for example a Certification Authority (CA).\n A certification path starts with the Subject certificate and proceeds through a\n number of intermediate certificates up to a trusted root certificate, typically\n issued by a trusted CA.\n\n Path validation is necessary for a relying party to make an informed trust\n decision when presented with any certificate not already explicitly trusted.\n\n Status information for certification paths includes certificate revocation\n lists or online certificate status protocol responses.\n\n Database Management Systems that do not validate certificates to a trust\n anchor are in danger of accepting certificates that are invalid and/or\n counterfeit. This could allow unauthorized access to the database.\n\n Transport Layer Security (TLS) is the successor protocol to Secure Sockets\n Layer (SSL). Although the Oracle configuration parameters have names including\n 'SSL', such as SSL_VERSION and SSL_CIPHER_SUITES, they refer to TLS.", + "title": "Databases utilizing Discretionary Access Control (DAC) must enforce a\n policy that limits propagation of access rights.", + "desc": "Discretionary Access Control (DAC) is based on the premise that\n individual users are owners of objects and therefore have discretion over\n who should be authorized to access the object and in which mode (e.g., read or\n write). Ownership is usually acquired as a consequence of creating the object\n or via specified ownership assignment.\n\n DAC allows the owner to determine who will have access to objects they\n control. An example of DAC includes user-controlled file permissions. DAC\n models have the potential for the access controls to propagate without limit,\n resulting in unauthorized access to said objects.\n\n When applications provide a discretionary access control mechanism, the\n application must be able to limit the propagation of those access rights.\n\n The DBMS must ensure the recipient of permissions possesses only the access\n intended. The database must enforce the ability to limit rights propagation if\n that is the intent of the grantor. If the propagation of access rights is not\n limited, users with rights to objects they do not own can continue to grant\n rights to those objects to other users without limit.\n\n This is default behavior for Oracle.", "descriptions": { - "default": "A trust anchor is an authoritative entity represented via a public key\n and associated data. It is used in the context of public key infrastructures,\n X.509 digital certificates, and DNSSEC.\n\n When there is a chain of trust, usually the top entity to be trusted\n becomes the trust anchor; it can be for example a Certification Authority (CA).\n A certification path starts with the Subject certificate and proceeds through a\n number of intermediate certificates up to a trusted root certificate, typically\n issued by a trusted CA.\n\n Path validation is necessary for a relying party to make an informed trust\n decision when presented with any certificate not already explicitly trusted.\n\n Status information for certification paths includes certificate revocation\n lists or online certificate status protocol responses.\n\n Database Management Systems that do not validate certificates to a trust\n anchor are in danger of accepting certificates that are invalid and/or\n counterfeit. This could allow unauthorized access to the database.\n\n Transport Layer Security (TLS) is the successor protocol to Secure Sockets\n Layer (SSL). Although the Oracle configuration parameters have names including\n 'SSL', such as SSL_VERSION and SSL_CIPHER_SUITES, they refer to TLS." + "default": "Discretionary Access Control (DAC) is based on the premise that\n individual users are owners of objects and therefore have discretion over\n who should be authorized to access the object and in which mode (e.g., read or\n write). Ownership is usually acquired as a consequence of creating the object\n or via specified ownership assignment.\n\n DAC allows the owner to determine who will have access to objects they\n control. An example of DAC includes user-controlled file permissions. DAC\n models have the potential for the access controls to propagate without limit,\n resulting in unauthorized access to said objects.\n\n When applications provide a discretionary access control mechanism, the\n application must be able to limit the propagation of those access rights.\n\n The DBMS must ensure the recipient of permissions possesses only the access\n intended. The database must enforce the ability to limit rights propagation if\n that is the intent of the grantor. If the propagation of access rights is not\n limited, users with rights to objects they do not own can continue to grant\n rights to those objects to other users without limit.\n\n This is default behavior for Oracle." }, - "impact": 0, + "impact": 0.5, "refs": [ { "ref": [] } ], "tags": { - "gtitle": "SRG-APP-000175-DB-000067", - "gid": "V-61741", - "rid": "SV-76231r3_rule", - "stig_id": "O121-C2-015300", - "fix_id": "F-67657r1_fix", + "gtitle": "SRG-APP-000085-DB-000038", + "gid": "V-61617", + "rid": "SV-76107r1_rule", + "stig_id": "O121-C2-006600", + "fix_id": "F-67533r1_fix", "cci": [ - "CCI-000185" + "CCI-002165" ], "nist": [ - "IA-5 (2) (a)", + "AC-3 (4)", "Rev_4" ], "false_negatives": null, @@ -510,35 +564,39 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "If PKI is not enabled in the Oracle Database, this is not a\n finding.\n\n If all accounts are authenticated by the OS or an enterprise-level\n authentication/access mechanism and not by Oracle, this is not a finding.\n\n Review DBMS configuration to verify the certificates being accepted by the DBMS\n have a valid certification path with status information to an accepted trust\n anchor.\n\n If certification paths are not being validated back to a trust anchor, this is\n a finding.\n\n - - - - -\n The database supports PKI-based authentication by using digital certificates\n over TLS in addition to the native encryption and data integrity capabilities\n of these protocols.\n\n Oracle provides a complete PKI that is based on RSA Security, Inc., Public-Key\n Cryptography Standards, and which interoperates with Oracle servers and\n clients. The database uses a wallet that is a container that is used to store\n authentication and signing credentials, including private keys, certificates,\n and trusted certificates needed by TLS. In an Oracle environment, every entity\n that communicates over TLS must have a wallet containing an X.509 version 3\n certificate, private key, and list of trusted certificates.\n\n If the $ORACLE_HOME/network/admin/sqlnet.ora contains the following entries,\n TLS is installed.\n\n WALLET_LOCATION = (SOURCE= (METHOD = FILE) (METHOD_DATA = DIRECTORY=/wallet)\n\n SSL_CIPHER_SUITES=(SSL_cipher_suiteExample)\n SSL_VERSION = 1.2 or 1.1\n SSL_CLIENT_AUTHENTICATION=TRUE\n\n (Note: This assumes that a single sqlnet.ora file, in the default location, is\n in use. Please see the supplemental file \"Non-default sqlnet.ora\n configurations.pdf\" for how to find multiple and/or differently located\n sqlnet.ora files.)\n\n Note: \"SSL_VERSION = 1.2 or 1.1\" is the actual value, not a suggestion to use\n one or the other.", - "fix": "Configure the DBMS to validate certificates by constructing a\n certification path with status information to an accepted trust anchor.\n\n Configure the database to support Transport Layer Security (TLS) protocols and\n the Oracle Wallet to store authentication and signing credentials, including\n private keys." + "check": "Verify the DBMS has the ability to grant permissions without\n the grantee receiving the right to grant those same permissions to another user.\n\n Review organization policies regarding access propagation. If an access\n propagation policy limiting the propagation of rights does not exist, this is a\n finding.\n\n Review DBMS configuration to verify access propagation policies are enforced by\n the DBMS as configured. If the DBMS does not enforce the access propagation\n policy, this is a finding.", + "fix": "Create and document an access propagation policy that limits the\n propagation of rights.\n\n Configure the DBMS to enforce the access propagation policy.\n\n When a user is granted access to an object, they have access to the object.\n When a user is granted access to an object with the GRANT option, then they can\n provide permissions to others. Without the GRANT option, a user cannot grant\n access to an object. No configuration is required." }, - "code": " control 'V-61741' do\n impact 0.0\n describe 'This control is not applicable on oracle within aws rds, as aws manages the operating system in which the oracle database is running on' do\n skip 'This control is not applicable on oracle within aws rds, as aws manages the operating system in which the oracle database is running on'\n end\n end\n", + "code": " control 'V-61617' do\n title \"Databases utilizing Discretionary Access Control (DAC) must enforce a\n policy that limits propagation of access rights.\"\n desc \"Discretionary Access Control (DAC) is based on the premise that\n individual users are owners of objects and therefore have discretion over\n who should be authorized to access the object and in which mode (e.g., read or\n write). Ownership is usually acquired as a consequence of creating the object\n or via specified ownership assignment.\n\n DAC allows the owner to determine who will have access to objects they\n control. An example of DAC includes user-controlled file permissions. DAC\n models have the potential for the access controls to propagate without limit,\n resulting in unauthorized access to said objects.\n\n When applications provide a discretionary access control mechanism, the\n application must be able to limit the propagation of those access rights.\n\n The DBMS must ensure the recipient of permissions possesses only the access\n intended. The database must enforce the ability to limit rights propagation if\n that is the intent of the grantor. If the propagation of access rights is not\n limited, users with rights to objects they do not own can continue to grant\n rights to those objects to other users without limit.\n\n This is default behavior for Oracle.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000085-DB-000038'\n tag \"gid\": 'V-61617'\n tag \"rid\": 'SV-76107r1_rule'\n tag \"stig_id\": 'O121-C2-006600'\n tag \"fix_id\": 'F-67533r1_fix'\n tag \"cci\": ['CCI-002165']\n tag \"nist\": ['AC-3 (4)', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Verify the DBMS has the ability to grant permissions without\n the grantee receiving the right to grant those same permissions to another user.\n\n Review organization policies regarding access propagation. If an access\n propagation policy limiting the propagation of rights does not exist, this is a\n finding.\n\n Review DBMS configuration to verify access propagation policies are enforced by\n the DBMS as configured. If the DBMS does not enforce the access propagation\n policy, this is a finding.\"\n tag \"fix\": \"Create and document an access propagation policy that limits the\n propagation of rights.\n\n Configure the DBMS to enforce the access propagation policy.\n\n When a user is granted access to an object, they have access to the object.\n When a user is granted access to an object with the GRANT option, then they can\n provide permissions to others. Without the GRANT option, a user cannot grant\n access to an object. No configuration is required.\"\n describe 'A manaul review is required to ensure the Databases utilizing Discretionary Access Control (DAC) enforce a\n policy that limits propagation of access rights' do\n skip 'A manaul review is required to ensure the Databases utilizing Discretionary Access Control (DAC) enforce a\n policy that limits propagation of access rights'\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61741.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61617.rb", "line": 1 }, - "id": "V-61741" + "id": "V-61617" }, { - "title": "The system must protect audit information from unauthorized\n modification.", - "desc": "If audit data were to become compromised, then competent forensic\n analysis and discovery of the true source of potentially malicious system\n activity is impossible to achieve.\n\n To ensure the veracity of audit data, the information system and/or the\n application must protect audit information from unauthorized modification.\n\n This requirement can be achieved through multiple methods which will depend\n upon system architecture and design. Some commonly employed methods include\n ensuring log files enjoy the proper file system permissions and limiting log\n data locations.\n\n Applications providing a user interface to audit data will leverage user\n permissions and roles identifying the user accessing the data and the\n corresponding rights that the user enjoys in order to make access decisions\n regarding the modification of audit data.\n\n Audit information includes all information (e.g., audit records, audit\n settings, and audit reports) needed to successfully audit information system\n activity.\n\n Modification of database audit data could mask the theft of, or the\n unauthorized modification of, sensitive data stored in the database.", + "title": "The DBMS must disable user accounts after 35 days of inactivity.", + "desc": "Password complexity, or strength, is a measure of the effectiveness of\n a password in resisting attempts at guessing and brute-force attacks.\n\n To meet password policy requirements, passwords need to be changed at\n specific policy-based intervals.\n\n If the information system or application allows the user to consecutively\n reuse their password when that password has exceeded its defined lifetime, the\n end result is a password that is not changed as per policy requirements.\n\n Unused or expired DBMS accounts provide a means for undetected,\n unauthorized access to the database.\n\n Note that user authentication and account management must be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP This requirement applies to cases where it is necessary to\n have accounts directly managed by Oracle.", "descriptions": { - "default": "If audit data were to become compromised, then competent forensic\n analysis and discovery of the true source of potentially malicious system\n activity is impossible to achieve.\n\n To ensure the veracity of audit data, the information system and/or the\n application must protect audit information from unauthorized modification.\n\n This requirement can be achieved through multiple methods which will depend\n upon system architecture and design. Some commonly employed methods include\n ensuring log files enjoy the proper file system permissions and limiting log\n data locations.\n\n Applications providing a user interface to audit data will leverage user\n permissions and roles identifying the user accessing the data and the\n corresponding rights that the user enjoys in order to make access decisions\n regarding the modification of audit data.\n\n Audit information includes all information (e.g., audit records, audit\n settings, and audit reports) needed to successfully audit information system\n activity.\n\n Modification of database audit data could mask the theft of, or the\n unauthorized modification of, sensitive data stored in the database." + "default": "Password complexity, or strength, is a measure of the effectiveness of\n a password in resisting attempts at guessing and brute-force attacks.\n\n To meet password policy requirements, passwords need to be changed at\n specific policy-based intervals.\n\n If the information system or application allows the user to consecutively\n reuse their password when that password has exceeded its defined lifetime, the\n end result is a password that is not changed as per policy requirements.\n\n Unused or expired DBMS accounts provide a means for undetected,\n unauthorized access to the database.\n\n Note that user authentication and account management must be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP This requirement applies to cases where it is necessary to\n have accounts directly managed by Oracle." }, - "impact": 0, - "refs": [], + "impact": 0.5, + "refs": [ + { + "ref": [] + } + ], "tags": { - "gtitle": "SRG-APP-000119-DB-000060", - "gid": "V-61655", - "rid": "SV-76145r1_rule", - "stig_id": "O121-C2-009400", - "fix_id": "F-67569r2_fix", + "gtitle": "SRG-APP-000163-DB-000113", + "gid": "V-61717", + "rid": "SV-76207r2_rule", + "stig_id": "O121-C2-013800", + "fix_id": "F-67633r3_fix", "cci": [ - "CCI-000163" + "CCI-000795" ], "nist": [ - "AU-9", + "IA-4 e)", "Rev_4" ], "false_negatives": null, @@ -551,30 +609,30 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Review locations of audit logs, both internal to the database\n and database audit logs located at the operating system-level. Verify there are\n appropriate controls and permissions to protect the audit information from\n unauthorized modification.\n\n If appropriate controls and permissions do not exist, this is a finding.\n\n - - - - -\n If Standard Auditing is used:\n DBA_TAB_PRIVS describes all object grants in the database. Check to see who\n has permissions on the AUD$ table.\n\n Related View\n\n DBA_TAB_PRIVS describes the object grants for which the current user is the\n object owner, grantor, or grantee.\n Column Datatype NULL Description\n GRANTEE VARCHAR2(30) NOT NULL Name of the user to whom access was granted\n VARCHAR2(30) NOT NULL Owner of the object\n TABLE_NA VARCHAR2(30) NOT NULL Name of the object\n GRANTOR VARCHAR2(30) NOT NULL Name of the user who performed the grant\n PRIVILEGE VARCHAR2(40) NOT NULL Privilege on the object\n GRANTABLE VARCHAR2(3) Indicates whether the privilege was granted\n with the GRANT OPTION (YES) or not (NO)\n HIERARCHY VARCHAR2(3) Indicates whether the privilege was granted\n with the HIERARCHY OPTION (YES) or not (NO)\n COMMON VARCHAR2(3)\n TYPE VARCHAR2(24)\n\n sqlplus connect as sysdba;\n\n SQL> SELECT GRANTEE, TABLE_NAME, PRIVILEGE\n FROM DBA_TAB_PRIVS where table_name = 'AUD$';\n\n If Unified Auditing is used:\n DBA_TAB_PRIVS describes all object grants in the database. Check to see who\n has permissions on the AUDSYS tables.\n\n Related View\n\n DBA_TAB_PRIVS describes the object grants for which the current user is the\n object owner, grantor, or grantee.\n Column Datatype NULL Description\n GRANTEE VARCHAR2(30) NOT NULL Name of the user to whom access was granted\n OWNER VARCHAR2(30) NOT NULL Owner of the object\n TABLE_NAME VARCHAR2(30) NOT NULL Name of the object\n GRANTOR VARCHAR2(30) NOT NULL Name of the user who performed the grant\n PRIVILEGE VARCHAR2(40) NOT NULL Privilege on the object\n GRANTABLE VARCHAR2(3) Indicates whether the privilege was granted\n with the GRANT OPTION (YES) or not (NO)\n HIERARCHY VARCHAR2(3) Indicates whether the privilege was granted\n with the HIERARCHY OPTION (YES) or not (NO)\n COMMON VARCHAR2(3)\n TYPE VARCHAR2(24)\n\n sqlplus connect as sysdba;\n\n SQL> SELECT GRANTEE, TABLE_NAME, PRIVILEGE\n FROM DBA_TAB_PRIVS where owner='AUDSYS';", - "fix": "Add controls and modify permissions to protect database audit log\n data from unauthorized modification, whether stored in the database itself or\n at the OS level.\n\n - - - - -\n If Standard Auditing is used:\n Revoke access to the AUD$ table to anyone who should not have access to it.\n\n In the check we looked for all users who had access to the AUD$ table. To fix\n this, use the REVOKE command to revoke access to users who should not have\n access to the audit data.\n\n REVOKE statement\n\n Use the REVOKE statement to remove permissions from a specific user or from all\n users to perform actions on database objects.\n The following types of permissions can be revoked:\n\n Delete data from a specific table.\n Insert data into a specific table.\n Create a foreign key reference to the named table or to a subset of columns\n from a table.\n Select data from a table, view, or a subset of columns in a table.\n Create a trigger on a table.\n Update data in a table or in a subset of columns in a table.\n Run a specified routine (function or procedure).\n\n If a user named FRED had access to the AUD$ table and wanting to revoke that\n access, use the following command. The syntax that would be used for the REVOKE\n statement for tables is as follows:\n\n REVOKE privilege-type ON [ TABLE ] { table-Name | view-Name } FROM grantees\n\n SQL>REVOKE SELECT ON TABLE AUD$ FROM FRED;\n\n Revoking a privilege without specifying a column list revokes the privilege for\n all of the columns in the table.\n Syntax for routines\n\n table-privileges include\n\n DELETE |\n INSERT |\n REFERENCES [column list] |\n SELECT [column list] |\n TRIGGER |\n UPDATE [column list]\n\n column list\n\n ( column-identifier {, column-identifier}* )\n\n Use the ALL PRIVILEGES privilege type to revoke all of the permissions from the\n user for the specified table. Can also revoke one or more table privileges by\n specifying a privilege-list.\n\n Use the DELETE privilege type to revoke permission to delete rows from the\n specified table.\n\n Use the INSERT privilege type to revoke permission to insert rows into the\n specified table.\n\n Use the REFERENCES privilege type to revoke permission to create a foreign key\n reference to the specified table. If a column list is specified with the\n REFERENCES privilege, the permission is revoked on only the foreign key\n reference to the specified columns.\n\n Use the SELECT privilege type to revoke permission to perform SELECT statements\n on a table or view. If a column list is specified with the SELECT privilege,\n the permission is revoked on only those columns. If no column list is\n specified, then the privilege is valid on all of the columns in the table.\n\n Use the TRIGGER privilege type to revoke permission to create a trigger on the\n specified table.\n\n Use the UPDATE privilege type to revoke permission to use the UPDATE statement\n on the specified table. If a column list is specified, the permission is\n revoked only on the specified columns.\n grantees\n\n { authorization ID | PUBLIC } [,{ authorization ID | PUBLIC } ] *\n\n Can revoke the privileges from specific users or from all users. Use the\n keyword PUBLIC to specify all users. The privileges revoked from PUBLIC and\n from individual users are independent privileges. For example, a SELECT\n privilege on table t is granted to both PUBLIC and to the authorization ID\n harry. The SELECT privilege is later revoked from the authorization ID 'Harry',\n but the authorization ID 'Harry' can access the table through the PUBLIC\n privilege.\n\n Restriction: Cannot revoke the privileges of the owner of an object.\n routine-designator\n\n {\n qualified-name [ signature ]\n }\n\n Cascading object dependencies\n\n For views, triggers, and constraints, if the privilege on which the object\n depends is revoked, the object is automatically dropped. Derby does not try to\n determine if there are other privileges that can replace the privileges that\n are being revoked. For more information, see \"SQL standard authorization\" in\n the Java DB Developer's Guide.\n Limitations\n\n The following limitations apply to the REVOKE statement:\n\n Table-level privileges:\n\n All of the table-level privilege types for a specified grantee and table ID are\n stored in one row in the SYSTABLEPERMS system table. For example, when user2 is\n granted the SELECT and DELETE privileges on table user1.t1, a row is added to\n the SYSTABLEPERMS table. The GRANTEE field contains user2 and the TABLEID\n contains user1.t1. The SELECTPRIV and DELETEPRIV fields are set to Y. The\n remaining privilege type fields are set to N.\n\n When a grantee creates an object that relies on one of the privilege types, the\n Derby engine tracks the dependency of the object on the specific row in the\n SYSTABLEPERMS table. For example, user2 creates the view v1 by using the\n statement SELECT * FROM user1.t1; the dependency manager tracks the dependency\n of view v1 on the row in SYSTABLEPERMS for GRANTEE(user2), TABLEID(user1.t1).\n The dependency manager knows only that the view is dependent on a privilege\n type in that specific row but does not track exactly which privilege type the\n view is dependent on.\n\n When a REVOKE statement for a table-level privilege is issued for a grantee and\n table ID, all of the objects that are dependent on the grantee and table ID are\n dropped. For example, if user1 revokes the DELETE privilege on table t1 from\n user2, the row in SYSTABLEPERMS for GRANTEE(user2), TABLEID(user1.t1) is\n modified by the REVOKE statement. The dependency manager sends a revoke\n invalidation message to the view user2.v1, and the view is dropped, even though\n the view is not dependent on the DELETE privilege for GRANTEE(user2),\n TABLEID(user1.t1).\n\n Column-level privileges:\n\n Only one type of privilege for a specified grantee and table ID are stored in\n one row in the SYSCOLPERMS system table. For example, when user2 is granted the\n SELECT privilege on table user1.t1 for columns c12 and c13, a row is added to\n the SYSCOLPERMS. The GRANTEE field contains user2, the TABLEID contains\n user1.t1, the TYPE field contains S, and the COLUMNS field contains c12, c13.\n\n When a grantee creates an object that relies on the privilege type and the\n subset of columns in a table ID, the Derby engine tracks the dependency of the\n object on the specific row in the SYSCOLPERMS table. For example, user2 creates\n the view v1 by using the statement SELECT c11 FROM user1.t1; the dependency\n manager tracks the dependency of view v1 on the row in SYSCOLPERMS for\n GRANTEE(user2), TABLEID(user1.t1), TYPE(S). The dependency manager knows that\n the view is dependent on the SELECT privilege type but does not track exactly\n which columns the view is dependent on.\n\n When a REVOKE statement for a column-level privilege is issued for a grantee,\n table ID, and type, all of the objects that are dependent on the grantee, table\n ID, and type are dropped. For example, if user1 revokes the SELECT privilege on\n column c12 on table user1.t1 from user2, the row in SYSCOLPERMS for\n GRANTEE(user2), TABLEID(user1.t1), TYPE(S) is modified by the REVOKE statement.\n The dependency manager sends a revoke invalidation message to the view\n user2.v1, and the view is dropped, even though the view is not dependent on the\n column c12 for GRANTEE(user2), TABLEID(user1.t1), TYPE(S).\n\n If Unified Auditing is used:\n\n Apply the same process used in standard auditing to the tables with AUDSYS as\n the owner." + "check": "If all user accounts are managed and authenticated by the OS or\n an enterprise-level authentication/access mechanism, and not by Oracle, this is\n not a finding.\n\n For accounts managed by Oracle, check DBMS settings to determine if accounts\n can be automatically disabled by the system after 35 days of inactivity. Also,\n ask the DBA if an alternative method, such as a stored procedure run daily, to\n disable Oracle-managed accounts inactive for more than 35 days, has been\n deployed.\n\n If the ability to disable accounts after 35 days of inactivity, by either of\n these means, does not exist, this is a finding.\n\n - - - - -\n\n Check to see what profile each user is associated with, if any, with this query:\n\n select username, profile from dba_users order by 1,2;\n\n Then check the profile to see what the password_life_time is set to in the\n table dba_profiles; the password_life_time is a value stored in the LIMIT\n column, and identified by the value PASSWORD_LIFE_TIME in the RESOURCE_NAME\n column.\n\n SQL>select profile, resource_name, resource_type, limit from dba_profiles where\n upper(resource_name) = 'PASSWORD_LIFE_TIME';", + "fix": "For accounts managed by Oracle, determine if it is practical and\n acceptable to require a password change every 35 days or fewer, rather than the\n standard 60 days (as specified in SRG-APP-000174-DB-000080). If it is, issue\n the statement:\n\n ALTER PROFILE PPPPPP LIMIT PASSWORD_LIFE_TIME 35;\n (See the Oracle-provided $ORACLE_HOME/rdbms/admin/secconf.sql script for\n examples.)\n\n If password changes every 35 days or fewer are unacceptable or impractical,\n implement an alternative method, such as a stored procedure run daily, to\n disable accounts inactive for more than 35 days." }, - "code": "control 'V-61655' do\n title \"The system must protect audit information from unauthorized\n modification.\"\n desc \"If audit data were to become compromised, then competent forensic\n analysis and discovery of the true source of potentially malicious system\n activity is impossible to achieve.\n\n To ensure the veracity of audit data, the information system and/or the\n application must protect audit information from unauthorized modification.\n\n This requirement can be achieved through multiple methods which will depend\n upon system architecture and design. Some commonly employed methods include\n ensuring log files enjoy the proper file system permissions and limiting log\n data locations.\n\n Applications providing a user interface to audit data will leverage user\n permissions and roles identifying the user accessing the data and the\n corresponding rights that the user enjoys in order to make access decisions\n regarding the modification of audit data.\n\n Audit information includes all information (e.g., audit records, audit\n settings, and audit reports) needed to successfully audit information system\n activity.\n\n Modification of database audit data could mask the theft of, or the\n unauthorized modification of, sensitive data stored in the database.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000119-DB-000060'\n tag \"gid\": 'V-61655'\n tag \"rid\": 'SV-76145r1_rule'\n tag \"stig_id\": 'O121-C2-009400'\n tag \"fix_id\": 'F-67569r2_fix'\n tag \"cci\": ['CCI-000163']\n tag \"nist\": ['AU-9', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Review locations of audit logs, both internal to the database\n and database audit logs located at the operating system-level. Verify there are\n appropriate controls and permissions to protect the audit information from\n unauthorized modification.\n\n If appropriate controls and permissions do not exist, this is a finding.\n\n - - - - -\n If Standard Auditing is used:\n DBA_TAB_PRIVS describes all object grants in the database. Check to see who\n has permissions on the AUD$ table.\n\n Related View\n\n DBA_TAB_PRIVS describes the object grants for which the current user is the\n object owner, grantor, or grantee.\n Column Datatype NULL Description\n GRANTEE VARCHAR2(30) NOT NULL Name of the user to whom access was granted\n VARCHAR2(30) NOT NULL Owner of the object\n TABLE_NA VARCHAR2(30) NOT NULL Name of the object\n GRANTOR VARCHAR2(30) NOT NULL Name of the user who performed the grant\n PRIVILEGE VARCHAR2(40) NOT NULL Privilege on the object\n GRANTABLE VARCHAR2(3) Indicates whether the privilege was granted\n with the GRANT OPTION (YES) or not (NO)\n HIERARCHY VARCHAR2(3) Indicates whether the privilege was granted\n with the HIERARCHY OPTION (YES) or not (NO)\n COMMON VARCHAR2(3)\n TYPE VARCHAR2(24)\n\n sqlplus connect as sysdba;\n\n SQL> SELECT GRANTEE, TABLE_NAME, PRIVILEGE\n FROM DBA_TAB_PRIVS where table_name = 'AUD$';\n\n If Unified Auditing is used:\n DBA_TAB_PRIVS describes all object grants in the database. Check to see who\n has permissions on the AUDSYS tables.\n\n Related View\n\n DBA_TAB_PRIVS describes the object grants for which the current user is the\n object owner, grantor, or grantee.\n Column Datatype NULL Description\n GRANTEE VARCHAR2(30) NOT NULL Name of the user to whom access was granted\n OWNER VARCHAR2(30) NOT NULL Owner of the object\n TABLE_NAME VARCHAR2(30) NOT NULL Name of the object\n GRANTOR VARCHAR2(30) NOT NULL Name of the user who performed the grant\n PRIVILEGE VARCHAR2(40) NOT NULL Privilege on the object\n GRANTABLE VARCHAR2(3) Indicates whether the privilege was granted\n with the GRANT OPTION (YES) or not (NO)\n HIERARCHY VARCHAR2(3) Indicates whether the privilege was granted\n with the HIERARCHY OPTION (YES) or not (NO)\n COMMON VARCHAR2(3)\n TYPE VARCHAR2(24)\n\n sqlplus connect as sysdba;\n\n SQL> SELECT GRANTEE, TABLE_NAME, PRIVILEGE\n FROM DBA_TAB_PRIVS where owner='AUDSYS';\"\n tag \"fix\": \"Add controls and modify permissions to protect database audit log\n data from unauthorized modification, whether stored in the database itself or\n at the OS level.\n\n - - - - -\n If Standard Auditing is used:\n Revoke access to the AUD$ table to anyone who should not have access to it.\n\n In the check we looked for all users who had access to the AUD$ table. To fix\n this, use the REVOKE command to revoke access to users who should not have\n access to the audit data.\n\n REVOKE statement\n\n Use the REVOKE statement to remove permissions from a specific user or from all\n users to perform actions on database objects.\n The following types of permissions can be revoked:\n\n Delete data from a specific table.\n Insert data into a specific table.\n Create a foreign key reference to the named table or to a subset of columns\n from a table.\n Select data from a table, view, or a subset of columns in a table.\n Create a trigger on a table.\n Update data in a table or in a subset of columns in a table.\n Run a specified routine (function or procedure).\n\n If a user named FRED had access to the AUD$ table and wanting to revoke that\n access, use the following command. The syntax that would be used for the REVOKE\n statement for tables is as follows:\n\n REVOKE privilege-type ON [ TABLE ] { table-Name | view-Name } FROM grantees\n\n SQL>REVOKE SELECT ON TABLE AUD$ FROM FRED;\n\n Revoking a privilege without specifying a column list revokes the privilege for\n all of the columns in the table.\n Syntax for routines\n\n table-privileges include\n\n DELETE |\n INSERT |\n REFERENCES [column list] |\n SELECT [column list] |\n TRIGGER |\n UPDATE [column list]\n\n column list\n\n ( column-identifier {, column-identifier}* )\n\n Use the ALL PRIVILEGES privilege type to revoke all of the permissions from the\n user for the specified table. Can also revoke one or more table privileges by\n specifying a privilege-list.\n\n Use the DELETE privilege type to revoke permission to delete rows from the\n specified table.\n\n Use the INSERT privilege type to revoke permission to insert rows into the\n specified table.\n\n Use the REFERENCES privilege type to revoke permission to create a foreign key\n reference to the specified table. If a column list is specified with the\n REFERENCES privilege, the permission is revoked on only the foreign key\n reference to the specified columns.\n\n Use the SELECT privilege type to revoke permission to perform SELECT statements\n on a table or view. If a column list is specified with the SELECT privilege,\n the permission is revoked on only those columns. If no column list is\n specified, then the privilege is valid on all of the columns in the table.\n\n Use the TRIGGER privilege type to revoke permission to create a trigger on the\n specified table.\n\n Use the UPDATE privilege type to revoke permission to use the UPDATE statement\n on the specified table. If a column list is specified, the permission is\n revoked only on the specified columns.\n grantees\n\n { authorization ID | PUBLIC } [,{ authorization ID | PUBLIC } ] *\n\n Can revoke the privileges from specific users or from all users. Use the\n keyword PUBLIC to specify all users. The privileges revoked from PUBLIC and\n from individual users are independent privileges. For example, a SELECT\n privilege on table t is granted to both PUBLIC and to the authorization ID\n harry. The SELECT privilege is later revoked from the authorization ID 'Harry',\n but the authorization ID 'Harry' can access the table through the PUBLIC\n privilege.\n\n Restriction: Cannot revoke the privileges of the owner of an object.\n routine-designator\n\n {\n qualified-name [ signature ]\n }\n\n Cascading object dependencies\n\n For views, triggers, and constraints, if the privilege on which the object\n depends is revoked, the object is automatically dropped. Derby does not try to\n determine if there are other privileges that can replace the privileges that\n are being revoked. For more information, see \\\"SQL standard authorization\\\" in\n the Java DB Developer's Guide.\n Limitations\n\n The following limitations apply to the REVOKE statement:\n\n Table-level privileges:\n\n All of the table-level privilege types for a specified grantee and table ID are\n stored in one row in the SYSTABLEPERMS system table. For example, when user2 is\n granted the SELECT and DELETE privileges on table user1.t1, a row is added to\n the SYSTABLEPERMS table. The GRANTEE field contains user2 and the TABLEID\n contains user1.t1. The SELECTPRIV and DELETEPRIV fields are set to Y. The\n remaining privilege type fields are set to N.\n\n When a grantee creates an object that relies on one of the privilege types, the\n Derby engine tracks the dependency of the object on the specific row in the\n SYSTABLEPERMS table. For example, user2 creates the view v1 by using the\n statement SELECT * FROM user1.t1; the dependency manager tracks the dependency\n of view v1 on the row in SYSTABLEPERMS for GRANTEE(user2), TABLEID(user1.t1).\n The dependency manager knows only that the view is dependent on a privilege\n type in that specific row but does not track exactly which privilege type the\n view is dependent on.\n\n When a REVOKE statement for a table-level privilege is issued for a grantee and\n table ID, all of the objects that are dependent on the grantee and table ID are\n dropped. For example, if user1 revokes the DELETE privilege on table t1 from\n user2, the row in SYSTABLEPERMS for GRANTEE(user2), TABLEID(user1.t1) is\n modified by the REVOKE statement. The dependency manager sends a revoke\n invalidation message to the view user2.v1, and the view is dropped, even though\n the view is not dependent on the DELETE privilege for GRANTEE(user2),\n TABLEID(user1.t1).\n\n Column-level privileges:\n\n Only one type of privilege for a specified grantee and table ID are stored in\n one row in the SYSCOLPERMS system table. For example, when user2 is granted the\n SELECT privilege on table user1.t1 for columns c12 and c13, a row is added to\n the SYSCOLPERMS. The GRANTEE field contains user2, the TABLEID contains\n user1.t1, the TYPE field contains S, and the COLUMNS field contains c12, c13.\n\n When a grantee creates an object that relies on the privilege type and the\n subset of columns in a table ID, the Derby engine tracks the dependency of the\n object on the specific row in the SYSCOLPERMS table. For example, user2 creates\n the view v1 by using the statement SELECT c11 FROM user1.t1; the dependency\n manager tracks the dependency of view v1 on the row in SYSCOLPERMS for\n GRANTEE(user2), TABLEID(user1.t1), TYPE(S). The dependency manager knows that\n the view is dependent on the SELECT privilege type but does not track exactly\n which columns the view is dependent on.\n\n When a REVOKE statement for a column-level privilege is issued for a grantee,\n table ID, and type, all of the objects that are dependent on the grantee, table\n ID, and type are dropped. For example, if user1 revokes the SELECT privilege on\n column c12 on table user1.t1 from user2, the row in SYSCOLPERMS for\n GRANTEE(user2), TABLEID(user1.t1), TYPE(S) is modified by the REVOKE statement.\n The dependency manager sends a revoke invalidation message to the view\n user2.v1, and the view is dropped, even though the view is not dependent on the\n column c12 for GRANTEE(user2), TABLEID(user1.t1), TYPE(S).\n\n If Unified Auditing is used:\n\n Apply the same process used in standard auditing to the tables with AUDSYS as\n the owner.\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n users_allowed_access_to_audit_info = sql.query(\"SELECT GRANTEE, TABLE_NAME, PRIVILEGE\n FROM DBA_TAB_PRIVS where owner='AUDSYS';\").column('grantee').uniq\n if users_allowed_access_to_audit_info.empty?\n impact 0.0\n describe 'There are no oracle users allowed access to audit information, control N/A' do\n skip 'There are no oracle users allowed access to audit information'\n end\n else\n users_allowed_access_to_audit_info.each do |user|\n describe \"oracle users: #{user} allowed access to audit information\" do\n subject { user }\n it { should be_in input('allowed_audit_users') }\n end\n end\n end\nend\n", + "code": "control 'V-61717' do\n title 'The DBMS must disable user accounts after 35 days of inactivity.'\n desc \"Password complexity, or strength, is a measure of the effectiveness of\n a password in resisting attempts at guessing and brute-force attacks.\n\n To meet password policy requirements, passwords need to be changed at\n specific policy-based intervals.\n\n If the information system or application allows the user to consecutively\n reuse their password when that password has exceeded its defined lifetime, the\n end result is a password that is not changed as per policy requirements.\n\n Unused or expired DBMS accounts provide a means for undetected,\n unauthorized access to the database.\n\n Note that user authentication and account management must be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP This requirement applies to cases where it is necessary to\n have accounts directly managed by Oracle.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000163-DB-000113'\n tag \"gid\": 'V-61717'\n tag \"rid\": 'SV-76207r2_rule'\n tag \"stig_id\": 'O121-C2-013800'\n tag \"fix_id\": 'F-67633r3_fix'\n tag \"cci\": ['CCI-000795']\n tag \"nist\": ['IA-4 e)', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"If all user accounts are managed and authenticated by the OS or\n an enterprise-level authentication/access mechanism, and not by Oracle, this is\n not a finding.\n\n For accounts managed by Oracle, check DBMS settings to determine if accounts\n can be automatically disabled by the system after 35 days of inactivity. Also,\n ask the DBA if an alternative method, such as a stored procedure run daily, to\n disable Oracle-managed accounts inactive for more than 35 days, has been\n deployed.\n\n If the ability to disable accounts after 35 days of inactivity, by either of\n these means, does not exist, this is a finding.\n\n - - - - -\n\n Check to see what profile each user is associated with, if any, with this query:\n\n select username, profile from dba_users order by 1,2;\n\n Then check the profile to see what the password_life_time is set to in the\n table dba_profiles; the password_life_time is a value stored in the LIMIT\n column, and identified by the value PASSWORD_LIFE_TIME in the RESOURCE_NAME\n column.\n\n SQL>select profile, resource_name, resource_type, limit from dba_profiles where\n upper(resource_name) = 'PASSWORD_LIFE_TIME';\"\n tag \"fix\": \"For accounts managed by Oracle, determine if it is practical and\n acceptable to require a password change every 35 days or fewer, rather than the\n standard 60 days (as specified in SRG-APP-000174-DB-000080). If it is, issue\n the statement:\n\n ALTER PROFILE PPPPPP LIMIT PASSWORD_LIFE_TIME 35;\n (See the Oracle-provided $ORACLE_HOME/rdbms/admin/secconf.sql script for\n examples.)\n\n If password changes every 35 days or fewer are unacceptable or impractical,\n implement an alternative method, such as a stored procedure run daily, to\n disable accounts inactive for more than 35 days.\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n query = %{\n SELECT PROFILE, RESOURCE_NAME, LIMIT FROM DBA_PROFILES WHERE PROFILE =\n '%s' AND RESOURCE_NAME = 'PASSWORD_LIFE_TIME'\n }\n\n user_profiles = sql.query('SELECT profile FROM dba_users;').column('profile').uniq\n\n user_profiles.each do |profile|\n next if profile == \"RDSADMIN\"\n password_life_time = sql.query(format(query, profile: profile)).column('limit')\n\n describe \"The oracle database account password life time for profile: #{profile}\" do\n subject { password_life_time }\n it { should cmp <= input('account_inactivity_age') }\n end\n end\n if user_profiles.empty?\n describe 'There are no user profiles, therefore this control is NA' do\n skip 'There are no user profiles, therefore this control is NA'\n end\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61655.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61717.rb", "line": 1 }, - "id": "V-61655" + "id": "V-61717" }, { - "title": "Changes to configuration options must be audited.", - "desc": "The AUDIT_SYS_OPERATIONS parameter is used to enable auditing of\n actions taken by the user SYS. The SYS user account is a shared account by\n definition and holds all privileges in the Oracle database. It is the account\n accessed by users connecting to the database with SYSDBA or SYSOPER privileges.", + "title": "When using command-line tools such as Oracle SQL*Plus, which can\n accept a plain-text password, users must use an alternative logon method that\n does not expose the password.", + "desc": "The SRG states: To prevent the compromise of authentication\n information, such as passwords, during the authentication process, the feedback\n from the information system shall not provide any information that would allow\n an unauthorized user to compromise the authentication mechanism.\n\n Obfuscation of user-provided information when typed into the system is a\n method used in addressing this risk\n\n For example, displaying asterisks when a user types in a password, is an\n example of obscuring feedback of authentication information.\n\n Database applications may allow for entry of the account name and\n password as a visible parameter of the application execution command. This\n practice should be prohibited and disabled to prevent shoulder surfing.\n\n SQL*Plus is an essential part of any Oracle installation. SQL*Plus cannot\n be configured not to accept a plain-text password. Since the typical SQL*Plus\n user is a database administrator, the consequences of password compromise are\n particularly serious. Therefore, the use of plain-text passwords must be\n prohibited, as a matter of practice and procedure.\n\n Transport Layer Security (TLS) is the successor protocol to Secure Sockets\n Layer (SSL). Although the Oracle configuration parameters have names including\n SSL, such as SSL_VERSION and SSL_CIPHER_SUITES, they refer to TLS.", "descriptions": { - "default": "The AUDIT_SYS_OPERATIONS parameter is used to enable auditing of\n actions taken by the user SYS. The SYS user account is a shared account by\n definition and holds all privileges in the Oracle database. It is the account\n accessed by users connecting to the database with SYSDBA or SYSOPER privileges." + "default": "The SRG states: To prevent the compromise of authentication\n information, such as passwords, during the authentication process, the feedback\n from the information system shall not provide any information that would allow\n an unauthorized user to compromise the authentication mechanism.\n\n Obfuscation of user-provided information when typed into the system is a\n method used in addressing this risk\n\n For example, displaying asterisks when a user types in a password, is an\n example of obscuring feedback of authentication information.\n\n Database applications may allow for entry of the account name and\n password as a visible parameter of the application execution command. This\n practice should be prohibited and disabled to prevent shoulder surfing.\n\n SQL*Plus is an essential part of any Oracle installation. SQL*Plus cannot\n be configured not to accept a plain-text password. Since the typical SQL*Plus\n user is a database administrator, the consequences of password compromise are\n particularly serious. Therefore, the use of plain-text passwords must be\n prohibited, as a matter of practice and procedure.\n\n Transport Layer Security (TLS) is the successor protocol to Secure Sockets\n Layer (SSL). Although the Oracle configuration parameters have names including\n SSL, such as SSL_VERSION and SSL_CIPHER_SUITES, they refer to TLS." }, - "impact": 0.5, + "impact": 0.7, "refs": [], "tags": { - "gtitle": "SRG-APP-000516-DB-999900", - "gid": "V-61519", - "rid": "SV-76009r1_rule", - "stig_id": "O121-BP-025800", - "fix_id": "F-67435r1_fix", + "gtitle": "SRG-APP-000178-DB-000083", + "gid": "V-61845", + "rid": "SV-76335r2_rule", + "stig_id": "O121-N1-015602", + "fix_id": "F-67761r4_fix", "cci": [ "CCI-000366" ], @@ -592,21 +650,21 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "From SQL*Plus:\n\n select value from v$parameter where name = 'audit_sys_operations';\n\n If the value returned is FALSE, this is a finding.", - "fix": "From SQL*Plus:\n\n alter system set audit_sys_operations = TRUE scope = spfile;\n\n The above SQL*Plus command will set the parameter to take effect at next system\n startup." + "check": "For Oracle SQL*Plus, which cannot be configured not to accept a\n plain-text password, and any other essential tool with the same limitation,\n verify that the system documentation explains the need for the tool, who uses\n it, and any relevant mitigations; and that AO approval has been obtained. If\n not, this is a finding.\n\n Request evidence that all users of the tool are trained in the importance of\n not using the plain-text password option and in how to keep the password\n hidden; and that they adhere to this practice. If not, this is a finding.", + "fix": "For Oracle SQL*Plus, which cannot be configured not to accept a\n plain-text password, and any other essential tool with the same limitation:\n\n 1) Document the need for it, who uses it, and any relevant mitigations, and\n obtain AO approval.\n 2) Train all users of the tool in the importance of not using the plain-text\n password option and in how to keep the password hidden.\n\n - - - - -\n Consider wrapping the startup command with a shell or wrapper and using an\n Oracle external password store.\n\n Oracle provides the capability to provide for a secure external password\n facility. Use the Oracle mkstore to create a secure storage area for passwords\n for applications, batch jobs, and scripts to use or deploy a site-authorized\n facility to perform this function.\n\n Check to see what has been stored in the Oracle External Password Store.\n\n To view all contents of a client wallet external password store, check specific\n credentials by viewing them. Listing the external password store contents\n provides information used to decide whether to add or delete credentials from\n the store. To list the contents of the external password store, enter the\n following command at the command line:\n\n $ mkstore -wrl wallet_location -listCredential\n\n For example:\n\n $ mkstore -wrl c:\\oracle\\product\\12.1.0\\db_1\\wallets -listCredential\n\n The wallet_location specifies the path to the directory where the wallet, whose\n external password store contents is to be viewed, is located. This command\n lists all of the credential database service names (aliases) and the\n corresponding user name (schema) for that database. Passwords are not listed.\n\n Configuring Clients to Use the External Password Store\n\n If the client is already configured to use external authentication, such as\n Windows native authentication or Transport Layer Security (TLS), then Oracle\n Database uses that authentication method. The same credentials used for this\n type of authentication are typically also used to log on to the database.\n\n For clients not using such authentication methods or wanting to override them\n for database authentication, set the SQLNET.WALLET_OVERRIDE parameter in\n sqlnet.ora to TRUE. The default value for SQLNET.WALLET_OVERRIDE is FALSE,\n allowing standard use of authentication credentials as before.\n\n If wanting a client to use the secure external password store feature, then\n perform the following configuration task:\n\n 1. Create a wallet on the client by using the following syntax at the command\n line:\n orapki create -wallet wallet_location -auto_login_local\n\n For example:\n orapki wallet create -wallet c:\\oracle\\product\\12.1.0\\db_1\\wallets\n -auto_login_local\n Enter password: password\n\n The wallet_location is the path to the directory where the wallet is to be\n created and stored. This command creates an Oracle wallet with the autologon\n feature enabled at the location specified. The autologon feature enables the\n client to access the wallet contents without supplying a password.\n\n The mkstore utility -create option uses password complexity verification.\n\n 2. Create database connection credentials in the wallet by using the following\n syntax at the command line:\n mkstore -wrl wallet_location -createCredential db_connect_string username\n Enter password: password\n\n For example:\n mkstore -wrl c:\\oracle\\product\\12.1.0\\db_1\\wallets -createCredential\n oracle system\n Enter password: password\n\n In this specification:\n The wallet_location is the path to the directory where the wallet was created.\n The db_connect_string used in the CONNECT /@db_connect_string statement must be\n identical to the db_connect_string specified in the -createCredential command.\n\n The db_connect_string is the TNS alias used to specify the database in the\n tnsnames.ora file or any service name used to identify the database on an\n Oracle network. By default, tnsnames.ora is located in the\n $ORACLE_HOME/network/admin directory on UNIX systems and in ORACLE_HOME etwork\\admin on Windows.\n\n The username is the database logon credential. When prompted, enter the\n password for this user.\n\n 3. In the client sqlnet.ora file, enter the WALLET_LOCATION parameter and set\n it to the directory location of the wallet created in Step 1. For example, if\n the wallet was created in $ORACLE_HOME/network/admin and the Oracle home is set\n to /private/ora12, then need to enter the following into the client sqlnet.ora\n file:\n\n WALLET_LOCATION =\n (SOURCE =\n (METHOD = FILE)\n (METHOD_DATA =\n (DIRECTORY = /private/ora12/network/admin)\n )\n )\n\n 4. In the client sqlnet.ora file, enter the SQLNET.WALLET_OVERRIDE parameter\n and set it to TRUE as follows:\n\n SQLNET.WALLET_OVERRIDE = TRUE\n\n This setting causes all CONNECT /@db_connect_string statements to use the\n information in the wallet at the specified location to authenticate to\n databases.\n\n When external authentication is in use, an authenticated user with such a\n wallet can use the CONNECT /@db_connect_string syntax to access the previously\n specified databases without providing a user name and password. However, if a\n user fails that external authentication, then these connect statements also\n fail.\n\n Below is a sample sqlnet.ora file with the WALLET_LOCATION and the\n SQLNET.WALLET_OVERRIDE parameters set as described in Steps 3 and 4.\n\n Below is a sample SQLNET.ORA File with Wallet Parameters Set\n\n WALLET_LOCATION =\n (SOURCE =\n (METHOD = FILE)\n (METHOD_DATA =\n (DIRECTORY = /private/ora12/network/admin)\n )\n )\n\n SQLNET.WALLET_OVERRIDE = TRUE\n SSL_CLIENT_AUTHENTICATION = FALSE\n SSL_VERSION =1.2 or 1.1\n\n (Note: This assumes that a single sqlnet.ora file, in the default location, is\n in use. Please see the supplemental file Non-default sqlnet.ora\n configurations.pdf for how to find multiple and/or differently located\n sqlnet.ora files.)\n\n Note: SSL_VERSION = 1.2 or 1.1 is the actual value, not a suggestion to\n use one or the other." }, - "code": "control 'V-61519' do\n title 'Changes to configuration options must be audited.'\n desc \"The AUDIT_SYS_OPERATIONS parameter is used to enable auditing of\n actions taken by the user SYS. The SYS user account is a shared account by\n definition and holds all privileges in the Oracle database. It is the account\n accessed by users connecting to the database with SYSDBA or SYSOPER privileges.\"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000516-DB-999900'\n tag \"gid\": 'V-61519'\n tag \"rid\": 'SV-76009r1_rule'\n tag \"stig_id\": 'O121-BP-025800'\n tag \"fix_id\": 'F-67435r1_fix'\n tag \"cci\": ['CCI-000366']\n tag \"nist\": ['CM-6 b', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"From SQL*Plus:\n\n select value from v$parameter where name = 'audit_sys_operations';\n\n If the value returned is FALSE, this is a finding.\"\n tag \"fix\": \"From SQL*Plus:\n\n alter system set audit_sys_operations = TRUE scope = spfile;\n\n The above SQL*Plus command will set the parameter to take effect at next system\n startup.\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n parameter = sql.query(\"select value from v$parameter where name = 'audit_sys_operations';\").column('value')\n\n describe 'The oracle database AUDIT_SYS_OPERATIONS parameter' do\n subject { parameter }\n it { should_not cmp 'FALSE' }\n end\nend\n", + "code": "control 'V-61845' do\n title \"When using command-line tools such as Oracle SQL*Plus, which can\n accept a plain-text password, users must use an alternative logon method that\n does not expose the password.\"\n desc \"The SRG states: To prevent the compromise of authentication\n information, such as passwords, during the authentication process, the feedback\n from the information system shall not provide any information that would allow\n an unauthorized user to compromise the authentication mechanism.\n\n Obfuscation of user-provided information when typed into the system is a\n method used in addressing this risk\n\n For example, displaying asterisks when a user types in a password, is an\n example of obscuring feedback of authentication information.\n\n Database applications may allow for entry of the account name and\n password as a visible parameter of the application execution command. This\n practice should be prohibited and disabled to prevent shoulder surfing.\n\n SQL*Plus is an essential part of any Oracle installation. SQL*Plus cannot\n be configured not to accept a plain-text password. Since the typical SQL*Plus\n user is a database administrator, the consequences of password compromise are\n particularly serious. Therefore, the use of plain-text passwords must be\n prohibited, as a matter of practice and procedure.\n\n Transport Layer Security (TLS) is the successor protocol to Secure Sockets\n Layer (SSL). Although the Oracle configuration parameters have names including\n SSL, such as SSL_VERSION and SSL_CIPHER_SUITES, they refer to TLS.\n \"\n impact 0.7\n tag \"gtitle\": 'SRG-APP-000178-DB-000083'\n tag \"gid\": 'V-61845'\n tag \"rid\": 'SV-76335r2_rule'\n tag \"stig_id\": 'O121-N1-015602'\n tag \"fix_id\": 'F-67761r4_fix'\n tag \"cci\": ['CCI-000366']\n tag \"nist\": ['CM-6 b', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"For Oracle SQL*Plus, which cannot be configured not to accept a\n plain-text password, and any other essential tool with the same limitation,\n verify that the system documentation explains the need for the tool, who uses\n it, and any relevant mitigations; and that AO approval has been obtained. If\n not, this is a finding.\n\n Request evidence that all users of the tool are trained in the importance of\n not using the plain-text password option and in how to keep the password\n hidden; and that they adhere to this practice. If not, this is a finding.\"\n tag \"fix\": \"For Oracle SQL*Plus, which cannot be configured not to accept a\n plain-text password, and any other essential tool with the same limitation:\n\n 1) Document the need for it, who uses it, and any relevant mitigations, and\n obtain AO approval.\n 2) Train all users of the tool in the importance of not using the plain-text\n password option and in how to keep the password hidden.\n\n - - - - -\n Consider wrapping the startup command with a shell or wrapper and using an\n Oracle external password store.\n\n Oracle provides the capability to provide for a secure external password\n facility. Use the Oracle mkstore to create a secure storage area for passwords\n for applications, batch jobs, and scripts to use or deploy a site-authorized\n facility to perform this function.\n\n Check to see what has been stored in the Oracle External Password Store.\n\n To view all contents of a client wallet external password store, check specific\n credentials by viewing them. Listing the external password store contents\n provides information used to decide whether to add or delete credentials from\n the store. To list the contents of the external password store, enter the\n following command at the command line:\n\n $ mkstore -wrl wallet_location -listCredential\n\n For example:\n\n $ mkstore -wrl c:\\\\oracle\\\\product\\\\12.1.0\\\\db_1\\\\wallets -listCredential\n\n The wallet_location specifies the path to the directory where the wallet, whose\n external password store contents is to be viewed, is located. This command\n lists all of the credential database service names (aliases) and the\n corresponding user name (schema) for that database. Passwords are not listed.\n\n Configuring Clients to Use the External Password Store\n\n If the client is already configured to use external authentication, such as\n Windows native authentication or Transport Layer Security (TLS), then Oracle\n Database uses that authentication method. The same credentials used for this\n type of authentication are typically also used to log on to the database.\n\n For clients not using such authentication methods or wanting to override them\n for database authentication, set the SQLNET.WALLET_OVERRIDE parameter in\n sqlnet.ora to TRUE. The default value for SQLNET.WALLET_OVERRIDE is FALSE,\n allowing standard use of authentication credentials as before.\n\n If wanting a client to use the secure external password store feature, then\n perform the following configuration task:\n\n 1. Create a wallet on the client by using the following syntax at the command\n line:\n orapki create -wallet wallet_location -auto_login_local\n\n For example:\n orapki wallet create -wallet c:\\\\oracle\\\\product\\\\12.1.0\\\\db_1\\\\wallets\n -auto_login_local\n Enter password: password\n\n The wallet_location is the path to the directory where the wallet is to be\n created and stored. This command creates an Oracle wallet with the autologon\n feature enabled at the location specified. The autologon feature enables the\n client to access the wallet contents without supplying a password.\n\n The mkstore utility -create option uses password complexity verification.\n\n 2. Create database connection credentials in the wallet by using the following\n syntax at the command line:\n mkstore -wrl wallet_location -createCredential db_connect_string username\n Enter password: password\n\n For example:\n mkstore -wrl c:\\\\oracle\\\\product\\\\12.1.0\\\\db_1\\\\wallets -createCredential\n oracle system\n Enter password: password\n\n In this specification:\n The wallet_location is the path to the directory where the wallet was created.\n The db_connect_string used in the CONNECT /@db_connect_string statement must be\n identical to the db_connect_string specified in the -createCredential command.\n\n The db_connect_string is the TNS alias used to specify the database in the\n tnsnames.ora file or any service name used to identify the database on an\n Oracle network. By default, tnsnames.ora is located in the\n $ORACLE_HOME/network/admin directory on UNIX systems and in ORACLE_HOME\\\n etwork\\\\admin on Windows.\n\n The username is the database logon credential. When prompted, enter the\n password for this user.\n\n 3. In the client sqlnet.ora file, enter the WALLET_LOCATION parameter and set\n it to the directory location of the wallet created in Step 1. For example, if\n the wallet was created in $ORACLE_HOME/network/admin and the Oracle home is set\n to /private/ora12, then need to enter the following into the client sqlnet.ora\n file:\n\n WALLET_LOCATION =\n (SOURCE =\n (METHOD = FILE)\n (METHOD_DATA =\n (DIRECTORY = /private/ora12/network/admin)\n )\n )\n\n 4. In the client sqlnet.ora file, enter the SQLNET.WALLET_OVERRIDE parameter\n and set it to TRUE as follows:\n\n SQLNET.WALLET_OVERRIDE = TRUE\n\n This setting causes all CONNECT /@db_connect_string statements to use the\n information in the wallet at the specified location to authenticate to\n databases.\n\n When external authentication is in use, an authenticated user with such a\n wallet can use the CONNECT /@db_connect_string syntax to access the previously\n specified databases without providing a user name and password. However, if a\n user fails that external authentication, then these connect statements also\n fail.\n\n Below is a sample sqlnet.ora file with the WALLET_LOCATION and the\n SQLNET.WALLET_OVERRIDE parameters set as described in Steps 3 and 4.\n\n Below is a sample SQLNET.ORA File with Wallet Parameters Set\n\n WALLET_LOCATION =\n (SOURCE =\n (METHOD = FILE)\n (METHOD_DATA =\n (DIRECTORY = /private/ora12/network/admin)\n )\n )\n\n SQLNET.WALLET_OVERRIDE = TRUE\n SSL_CLIENT_AUTHENTICATION = FALSE\n SSL_VERSION =1.2 or 1.1\n\n (Note: This assumes that a single sqlnet.ora file, in the default location, is\n in use. Please see the supplemental file Non-default sqlnet.ora\n configurations.pdf for how to find multiple and/or differently located\n sqlnet.ora files.)\n\n Note: SSL_VERSION = 1.2 or 1.1 is the actual value, not a suggestion to\n use one or the other.\"\n describe 'A manual review is required to ensure when using command-line tools such as Oracle SQL*Plus, which can\n accept a plain-text password, users must use an alternative logon method that\n does not expose the password' do\n skip 'A manual review is required to ensure when using command-line tools such as Oracle SQL*Plus, which can\n accept a plain-text password, users must use an alternative logon method that\n does not expose the password'\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61519.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61845.rb", "line": 1 }, - "id": "V-61519" + "id": "V-61845" }, { - "title": "Network client connections must be restricted to supported versions.", - "desc": "Unsupported Oracle network client installations may introduce\n vulnerabilities to the database. Restriction to use of supported versions helps\n to protect the database and helps to enforce newer, more robust security\n controls.", + "title": "The DBMS must implement required cryptographic protections using\n cryptographic modules complying with applicable federal laws, Executive Orders,\n directives, policies, regulations, standards, and guidance.", + "desc": "Use of cryptography to provide confidentiality and non-repudiation is\n not effective unless strong methods are employed. Many earlier encryption\n methods and modules have been broken and/or overtaken by increasing computing\n power. The NIST FIPS 140-2 cryptographic standards provide proven methods and\n strengths to employ cryptography effectively.\n\n Detailed information on the NIST Cryptographic Module Validation Program\n (CMVP) is available at http://csrc.nist.gov/groups/STM/cmvp/index.html\n\n Note: this does not require that all databases be encrypted. It specifies\n that if encryption is required, then the implementation of the encryption must\n satisfy the prevailing standards.", "descriptions": { - "default": "Unsupported Oracle network client installations may introduce\n vulnerabilities to the database. Restriction to use of supported versions helps\n to protect the database and helps to enforce newer, more robust security\n controls." + "default": "Use of cryptography to provide confidentiality and non-repudiation is\n not effective unless strong methods are employed. Many earlier encryption\n methods and modules have been broken and/or overtaken by increasing computing\n power. The NIST FIPS 140-2 cryptographic standards provide proven methods and\n strengths to employ cryptography effectively.\n\n Detailed information on the NIST Cryptographic Module Validation Program\n (CMVP) is available at http://csrc.nist.gov/groups/STM/cmvp/index.html\n\n Note: this does not require that all databases be encrypted. It specifies\n that if encryption is required, then the implementation of the encryption must\n satisfy the prevailing standards." }, "impact": 0, "refs": [ @@ -615,16 +673,16 @@ } ], "tags": { - "gtitle": "SRG-APP-000516-DB-999900", - "gid": "V-61535", - "rid": "SV-76025r2_rule", - "stig_id": "O121-BP-026600", - "fix_id": "F-67451r1_fix", + "gtitle": "SRG-APP-000196-DB-000140", + "gid": "V-61759", + "rid": "SV-76249r3_rule", + "stig_id": "O121-C2-016600", + "fix_id": "F-67675r2_fix", "cci": [ - "CCI-000366" + "CCI-002450" ], "nist": [ - "CM-6 b", + "SC-13", "Rev_4" ], "false_negatives": null, @@ -637,35 +695,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Note: The SQLNET.ALLOWED_LOGON_VERSION parameter is deprecated\n in Oracle Database 12c. This parameter has been replaced with two new Oracle\n Net Services parameters:\n\n SQLNET.ALLOWED_LOGON_VERSION_SERVER\n SQLNET.ALLOWED_LOGON_VERSION_CLIENT\n\n View the SQLNET.ORA file in the ORACLE_HOME/network/admin directory or the\n directory specified in the TNS_ADMIN environment variable. (Please see the\n supplemental file \"Non-default sqlnet.ora configurations.pdf\" for how to find\n multiple and/or differently located sqlnet.ora files.)\n\n Locate the following entries:\n\n SQLNET.ALLOWED_LOGON_VERSION_SERVER = 11\n SQLNET.ALLOWED_LOGON_VERSION_CLIENT=11\n\n If the parameters do not exist, this is a finding.\n\n If the parameters are not set to a value of 11 or higher, this is a finding.\n\n Note: Attempting to connect with a client version lower than specified in these\n parameters may result in a misleading error:\n ORA-01017: invalid username/password: logon denied", - "fix": "Edit the SQLNET.ORA file to add or edit the entries:\n\n SQLNET.ALLOWED_LOGON_VERSION_SERVER = 11\n SQLNET.ALLOWED_LOGON_VERSION_CLIENT=11\n\n Set the value to 11 or higher.\n Valid values for SQLNET.ALLOWED_LOGON_VERSION_SERVER are: 8,9,10,11,12 and 12a\n\n Valid values for SQLNET.ALLOWED_LOGON_VERSION_CLIENT are: 8,10,11,12 and 12a\n\n For more information on sqlnet.ora parameters refer to the following document:\n \"Database Net Services Reference\"\n http://docs.oracle.com/database/121/NETRF/sqlnet.htm#NETRF006" + "check": "If encryption is not required for the database, this is not a\n finding.\n\n If the DBMS has not implemented federally required cryptographic protections\n for the level of classification of the data it contains, this is a finding.\n\n Check the following settings to see if FIPS 140-2 encryption is configured. If\n encryption is not configured, check with the DBA and SYSTEM Administrator to\n see if other mechanisms or third-party products are deployed to encrypt data\n during the transmission or storage of data.\n\n For Transparent Data Encryption and DBMS_CRYPTO:\n\n To see if Oracle is configured for FIPS 140-2 Transparent Data Encryption\n and/or DBMS_CRYPTO, enter the following SQL*Plus command:\n SHOW PARAMETER DBFIPS_140\n or the following SQL query:\n SELECT * FROM SYS.V$PARAMETER WHERE NAME = 'DBFIPS_140';\n\n If Oracle returns the value 'FALSE', or returns no rows, this is a finding.\n\n To see if Oracle is configured for FIPS 140-2 SSL/TLS authentication and/or\n Encryption:\n\n Verify the DBMS version:\n select * from V_$VERSION;\n\n If the version displayed for Oracle Database is lower than 12.1.0.2, this is a\n finding.\n\n If the operating system is Windows and the DBMS version is 12.1.0.2, use the\n opatch command to display the patches applied to the DBMS.\n\n If the patches listed do not include \"WINDOWS DB BUNDLE PATCH 12.1.0.2.7\",\n this is a finding.\n\n Open the fips.ora file in a browser or editor. (The default location for\n fips.ora is $ORACLE_HOME/ldap/admin/ but alternate locations are possible. An\n alternate location, if it is in use, is specified in the FIPS_HOME environment\n variable.)\n\n If the line \"SSLFIPS_140=TRUE\" is not found in fips.ora, or the file does not\n exist, this is a finding.\n\n For (Native) Network Data Encryption:\n If the line, SQLNET.FIPS_140=TRUE is not found in\n $ORACLE_HOME/network/admin/sqlnet.ora, this is a finding. (Note: This assumes\n that a single sqlnet.ora file, in the default location, is in use. Please see\n the supplemental file \"Non-default sqlnet.ora configurations.pdf\" for how to\n find multiple and/or differently located sqlnet.ora files.)\n\n Note: For the Solaris platform, when DBFIPS_140 is FALSE, TDE (but not\n DBMS_CRYPTO) can still operate in a FIPS 140-compliant manner if FIPS 140\n operation is enabled for the Solaris Cryptographic Framework.", + "fix": "Implement required cryptographic protections using cryptographic\n modules complying with applicable federal laws, Executive Orders, directives,\n policies, regulations, standards, and guidance.\n\n Where not already in effect, upgrade the DBMS to version 12.1.0.2 or higher.\n\n Where the operating system is Windows and the DBMS version is 12.1.0.2, install\n patch \"WINDOWS DB BUNDLE PATCH 12.1.0.2.7\" if not already deployed.\n\n Open the fips.ora file in an editor. (The default location for fips.ora is\n $ORACLE_HOME/ldap/admin/ but alternate locations are possible. An alternate\n location, if it is in use, is specified in the FIPS_HOME environment variable.)\n\n Create or modify fips.ora to include the line \"SSLFIPS_140=TRUE\".\n\n - - - - -\n The strength requirements are dependent upon data classification.\n\n For unclassified data, where cryptography is required:\n AES 128 for encryption\n SHA 256 for hashing\n\n NSA has established the suite B encryption requirements for protecting National\n Security Systems (NSS) as follows:\n AES 128 for Secret\n AES 256 for Top Secret\n SHA 256 for Secret\n SHA 384 for Top Secret\n\n National Security System is defined as:\n (OMB Circular A-130) Any telecommunications or information system operated by\n the United States Government, the function, operation, or use of which (1)\n involves intelligence activities; (2) involves cryptologic activities related\n to national security; (3) involves command and control of military forces; (4)\n involves equipment that is an integral part of a weapon or weapons system; or\n (5) is critical to the direct fulfillment of military or intelligence missions,\n but excluding any system that is to be used for routine administrative and\n business applications (including payroll, finance, logistics, and personnel\n management applications)." }, - "code": " control 'V-61535' do\n impact 0.0\n describe 'This control is not applicable on oracle within aws rds, as aws manages the operating system in which the oracle database is running on' do\n skip 'This control is not applicable on oracle within aws rds, as aws manages the operating system in which the oracle database is running on'\n end\n end\n", + "code": " control 'V-61759' do\n impact 0.0\n describe 'This control is not applicable on oracle within aws rds, as aws manages the operating system in which the oracle database is running on' do\n skip 'This control is not applicable on oracle within aws rds, as aws manages the operating system in which the oracle database is running on'\n end\n end\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61535.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61759.rb", "line": 1 }, - "id": "V-61535" + "id": "V-61759" }, { - "title": "The DBMS must isolate security functions from nonsecurity functions by\n means of separate security domains.", - "desc": "Security functions are defined as \"the hardware, software, and/or\n firmware of the information system responsible for enforcing the system\n security policy and supporting the isolation of code and data on which the\n protection is based\".\n\n Developers and implementers can increase the assurance in security\n functions by employing well-defined security policy models, structured,\n disciplined, and rigorous hardware and software development techniques, and\n sound system/security engineering principles.\n\n Database Management Systems typically separate security functionality from\n non-security functionality via separate databases or schemas. Database objects\n or code implementing security functionality must not be commingled with objects\n or code implementing application logic. When security and non-security\n functionality is commingled, users who have access to non-security\n functionality may be able to access security functionality.", + "title": "All use of privileged accounts must be audited.", + "desc": "This is intended to limit exposure, by making it possible to trace any\n unauthorized access, by a privileged user account or role that has permissions\n on security functions or security-relevant information, to other data or\n functionality.", "descriptions": { - "default": "Security functions are defined as \"the hardware, software, and/or\n firmware of the information system responsible for enforcing the system\n security policy and supporting the isolation of code and data on which the\n protection is based\".\n\n Developers and implementers can increase the assurance in security\n functions by employing well-defined security policy models, structured,\n disciplined, and rigorous hardware and software development techniques, and\n sound system/security engineering principles.\n\n Database Management Systems typically separate security functionality from\n non-security functionality via separate databases or schemas. Database objects\n or code implementing security functionality must not be commingled with objects\n or code implementing application logic. When security and non-security\n functionality is commingled, users who have access to non-security\n functionality may be able to access security functionality." + "default": "This is intended to limit exposure, by making it possible to trace any\n unauthorized access, by a privileged user account or role that has permissions\n on security functions or security-relevant information, to other data or\n functionality." }, "impact": 0.5, "refs": [], "tags": { - "gtitle": "SRG-APP-000233-DB-000124", - "gid": "V-61775", - "rid": "SV-76265r1_rule", - "stig_id": "O121-C2-018500", - "fix_id": "F-67691r1_fix", + "gtitle": "SRG-APP-000063-DB-000018", + "gid": "V-61595", + "rid": "SV-76085r2_rule", + "stig_id": "O121-C2-004200", + "fix_id": "F-67511r1_fix", "cci": [ - "CCI-001084" + "CCI-000366" ], "nist": [ - "SC-3", + "CM-6 b", "Rev_4" ], "false_negatives": null, @@ -678,35 +736,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Check DBMS settings to determine whether objects or code\n implementing security functionality are located in a separate security domain,\n such as a separate database or schema created specifically for security\n functionality.\n\n If security-related database objects or code are not kept separate, this is a\n finding.\n\n The Oracle elements of security functionality, such as the roles, permissions,\n and profiles, along with password complexity requirements, are stored in\n separate schemas in the database. Review any site-specific applications\n security modules built into the database and determine what schema they are\n located in and take appropriate action. The Oracle objects will be in the\n Oracle Data Dictionary.", - "fix": "Locate security-related database objects and code in a separate\n database, schema, or other separate security domain from database objects and\n code implementing application logic. (This is the default behavior for\n Oracle.) Review any site-specific applications security modules built into the\n database: determine what schema they are located in and take appropriate\n action." + "check": "Review auditing configuration.\n\n If it is possible for a privileged user/role to access non-security functions\n or information without having the action recorded in the audit log, this is a\n finding.\n\n To obtain a list of unified auditing policies that have been defined, run the\n query:\n SELECT unique policy_name from AUDIT_UNIFIED_POLICIES;\n\n To obtain a list of unified auditing policies that have been enabled and the\n users for which it has been enabled, run the query:\n SELECT unique policy_name, user_name from AUDIT_UNIFIED_ENABLED_POLICIES;\n\n Unless otherwise required, verify that user_name is set to 'ALL USERS' to\n insure that the activity of administrative users is being logged.", + "fix": "Configure DBMS auditing so that all use of privileged accounts is\n recorded in the audit log." }, - "code": "control 'V-61775' do\n title \"The DBMS must isolate security functions from nonsecurity functions by\n means of separate security domains.\"\n desc \"Security functions are defined as \\\"the hardware, software, and/or\n firmware of the information system responsible for enforcing the system\n security policy and supporting the isolation of code and data on which the\n protection is based\\\".\n\n Developers and implementers can increase the assurance in security\n functions by employing well-defined security policy models, structured,\n disciplined, and rigorous hardware and software development techniques, and\n sound system/security engineering principles.\n\n Database Management Systems typically separate security functionality from\n non-security functionality via separate databases or schemas. Database objects\n or code implementing security functionality must not be commingled with objects\n or code implementing application logic. When security and non-security\n functionality is commingled, users who have access to non-security\n functionality may be able to access security functionality.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000233-DB-000124'\n tag \"gid\": 'V-61775'\n tag \"rid\": 'SV-76265r1_rule'\n tag \"stig_id\": 'O121-C2-018500'\n tag \"fix_id\": 'F-67691r1_fix'\n tag \"cci\": ['CCI-001084']\n tag \"nist\": ['SC-3', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Check DBMS settings to determine whether objects or code\n implementing security functionality are located in a separate security domain,\n such as a separate database or schema created specifically for security\n functionality.\n\n If security-related database objects or code are not kept separate, this is a\n finding.\n\n The Oracle elements of security functionality, such as the roles, permissions,\n and profiles, along with password complexity requirements, are stored in\n separate schemas in the database. Review any site-specific applications\n security modules built into the database and determine what schema they are\n located in and take appropriate action. The Oracle objects will be in the\n Oracle Data Dictionary.\"\n tag \"fix\": \"Locate security-related database objects and code in a separate\n database, schema, or other separate security domain from database objects and\n code implementing application logic. (This is the default behavior for\n Oracle.) Review any site-specific applications security modules built into the\n database: determine what schema they are located in and take appropriate\n action.\"\n describe 'A manual review is required to ensure the DBMS isolates security functions from nonsecurity functions by\n means of separate security domains' do\n skip 'A manual review is required to ensure the DBMS isolates security functions from nonsecurity functions by\n means of separate security domains'\n end\nend\n", + "code": "control 'V-61595' do\n title 'All use of privileged accounts must be audited.'\n desc \"This is intended to limit exposure, by making it possible to trace any\n unauthorized access, by a privileged user account or role that has permissions\n on security functions or security-relevant information, to other data or\n functionality.\"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000063-DB-000018'\n tag \"gid\": 'V-61595'\n tag \"rid\": 'SV-76085r2_rule'\n tag \"stig_id\": 'O121-C2-004200'\n tag \"fix_id\": 'F-67511r1_fix'\n tag \"cci\": ['CCI-000366']\n tag \"nist\": ['CM-6 b', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Review auditing configuration.\n\n If it is possible for a privileged user/role to access non-security functions\n or information without having the action recorded in the audit log, this is a\n finding.\n\n To obtain a list of unified auditing policies that have been defined, run the\n query:\n SELECT unique policy_name from AUDIT_UNIFIED_POLICIES;\n\n To obtain a list of unified auditing policies that have been enabled and the\n users for which it has been enabled, run the query:\n SELECT unique policy_name, user_name from AUDIT_UNIFIED_ENABLED_POLICIES;\n\n Unless otherwise required, verify that user_name is set to 'ALL USERS' to\n insure that the activity of administrative users is being logged.\"\n tag \"fix\": \"Configure DBMS auditing so that all use of privileged accounts is\n recorded in the audit log.\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n unified_auditing_policies_defined = sql.query('SELECT unique policy_name from AUDIT_UNIFIED_POLICIES;').column('policy_name')\n\n describe 'The list of unified auditing policies defined' do\n subject { unified_auditing_policies_defined }\n it { should_not be_empty }\n end\n\n users_being_audited = sql.query('SELECT unique user_name from AUDIT_UNIFIED_ENABLED_POLICIES;').column('user_name')\n\n describe 'The list of users being audited' do\n subject { users_being_audited }\n it { should include 'ALL USERS' }\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61775.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61595.rb", "line": 1 }, - "id": "V-61775" + "id": "V-61595" }, { - "title": "Recovery procedures and technical system features must exist to ensure\n recovery is done in a secure and verifiable manner.", - "desc": "Application recovery and reconstitution constitutes executing an\ninformation system contingency plan comprised of activities that restore\nessential missions and business functions.\n\n Database management systems and transaction-based processing systems are\nexamples of information systems that are transaction-based. Transaction\nrollback and transaction journaling are examples of mechanisms supporting\ntransaction recovery.\n\n A DBMS may be vulnerable to use of compromised data or other critical files\nduring recovery. Use of compromised files could introduce maliciously altered\napplication code, relaxed security settings or loss of data integrity. Where\navailable, DBMS mechanisms to ensure use of only trusted files can help protect\nthe database from this type of compromise during DBMS recovery.", + "title": "DBMS production application and data directories must be protected\n from developers on shared production/development DBMS host systems.", + "desc": "Developer roles must not be assigned DBMS administrative privileges to\n production DBMS application and data directories. The separation of production\n DBA and developer roles helps protect the production system from unauthorized,\n malicious or unintentional interruption due to development activities.", "descriptions": { - "default": "Application recovery and reconstitution constitutes executing an\ninformation system contingency plan comprised of activities that restore\nessential missions and business functions.\n\n Database management systems and transaction-based processing systems are\nexamples of information systems that are transaction-based. Transaction\nrollback and transaction journaling are examples of mechanisms supporting\ntransaction recovery.\n\n A DBMS may be vulnerable to use of compromised data or other critical files\nduring recovery. Use of compromised files could introduce maliciously altered\napplication code, relaxed security settings or loss of data integrity. Where\navailable, DBMS mechanisms to ensure use of only trusted files can help protect\nthe database from this type of compromise during DBMS recovery." + "default": "Developer roles must not be assigned DBMS administrative privileges to\n production DBMS application and data directories. The separation of production\n DBA and developer roles helps protect the production system from unauthorized,\n malicious or unintentional interruption due to development activities." }, "impact": 0.5, "refs": [], "tags": { - "gtitle": "SRG-APP-000144-DB-000101", - "gid": "V-61689", - "rid": "SV-76179r1_rule", - "stig_id": "O121-C2-012000", - "fix_id": "F-67603r1_fix", + "gtitle": "SRG-APP-000516-DB-999900", + "gid": "V-61487", + "rid": "SV-75977r1_rule", + "stig_id": "O121-BP-024100", + "fix_id": "F-67403r1_fix", "cci": [ - "CCI-000553" + "CCI-000366" ], "nist": [ - "CP-10 (2)", + "CM-6 b", "Rev_4" ], "false_negatives": null, @@ -719,39 +777,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Review DBMS recovery procedures and technical system features\n to determine if mechanisms exist and are in place to specify use of trusted\n files during DBMS recovery.\n\n If recovery procedures do not exist or are not sufficient to ensure recovery is\n done in a secure and verifiable manner, this is a finding.\n\n If system features exist and are not employed or not employed sufficiently,\n this is a finding.\n\n If circumstances that can inhibit a trusted recovery are not documented and\n appropriate mitigating procedures have not been put in place, this is a finding.\n\n Review the database backup strategy with the system administrator. Consider\n using Oracle RMAN with an encrypted backup to insure the backed up files can be\n trusted not to be compromised.", - "fix": "Implement DBMS recovery procedures and employ technical system\n features to specify trusted files during DBMS recovery. Test the solution and\n review the site-specific criteria to ensure that the backup and recovery\n process uses trusted files.\n\n Ensure circumstances that can inhibit a trusted recovery are documented and\n appropriate mitigating procedures have been put in place.\n\n Oracle recommends using RMAN Backup and encrypting backup files. With\n encrypted files stored on a mount point with limited access, the integrity of\n the files can be trusted.\n\n - - - - -\n Notes on Oracle Backup and Recovery Solutions\n\n When implementing a backup and recovery strategy, have the following solutions\n available:\n\n -- Recovery Manager (RMAN)\n Recovery Manager is fully integrated with the Oracle database to perform a\n range of backup and recovery activities, including maintaining an RMAN\n repository of historical data about backups. Can access RMAN through the\n command line or through Oracle Enterprise Manager.\n\n -- User-managed backup and recovery\n In this solution, perform backup and recovery with a mixture of host operating\n system commands and SQL*Plus recovery commands. Responsible for determining all\n aspects of when and how backups and recovery are done.\n\n -- Media management\n If not wanting to use RMAN with an encrypted backup, consider configuring RMAN\n to make backups to a media manager. On most platforms, to back up to and\n restore from sequential media such as tape, must integrate a media manager with\n the Oracle database. Can use Oracle Secure Backup, which supports both database\n and file system backups to tape, as the media manager. See Oracle Secure Backup\n Administrator's Guide to learn how to set up RMAN for use specifically with\n Oracle Secure Backup.\n\n These solutions are supported by Oracle and are fully documented, but RMAN is\n the preferred solution for database backup and recovery. RMAN provides a common\n interface for backup tasks across different host operating systems and offers\n several backup techniques not available through user-managed methods.\n\n -- Incremental backups:\n An incremental backup stores only blocks changed since a previous backup.\n Thus, they provide more compact backups and faster recovery, thereby reducing\n the need to apply redo during data file media recovery. If enabling block\n change tracking, then can improve performance by avoiding full scans of every\n input data file. Can use the BACKUP INCREMENTAL command to perform incremental\n backups.\n\n -- Block media recovery:\n Can repair a data file with only a small number of corrupt data blocks without\n taking it off-line or restoring it from backup. Can use the RECOVER BLOCK\n command to perform block media recovery.\n\n -- Binary compression:\n A binary compression mechanism integrated into Oracle Database reduces the size\n of backups.\n\n -- Encrypted backups:\n RMAN uses backup encryption capabilities integrated into Oracle Database to\n store backup sets in an encrypted format. To create encrypted backups on disk,\n the database must use the Advanced Security Option. To create encrypted backups\n directly on tape, RMAN must use the Oracle Secure Backup SBT interface but does\n not require the Advanced Security Option.\n\n -- Automated database duplication:\n Easily creates a copy of the database, supporting various storage\n configurations, including direct duplication between ASM databases.\n\n -- Cross-platform data conversion:\n Whether using RMAN or user-managed methods, can supplement physical backups\n with logical backups of schema objects made with Data Pump Export utility. Can\n later use Data Pump Import to re-create data after restore and recovery.\n Logical backups are mostly beyond the scope of the backup and recovery\n documentation." + "check": "If the DBMS or DBMS host is not shared by production and\n development activities, this check is not a finding.\n\n Review OS DBA group membership.\n\n If any developer accounts, as identified in the System Security Plan, have been\n assigned DBA privileges, this is a finding.\n\n Note: Though shared production/non-production DBMS installations was allowed\n under previous database STIG guidance, doing so may place it in violation of\n OS, Application, Network or Enclave STIG guidance. Ensure that any shared\n production/non-production DBMS installation meets STIG guidance requirements at\n all levels or mitigate any conflicts in STIG guidance with the AO.", + "fix": "Create separate DBMS host OS groups for developer and production\n DBAs.\n\n Do not assign production DBA OS group membership to accounts used for\n development.\n\n Remove development accounts from production DBA OS group membership.\n\n Recommend establishing a dedicated DBMS host for production DBMS installations.\n A dedicated host system in this case refers to an instance of the operating\n system at a minimum. The operating system may reside on a virtual host machine\n where supported by the DBMS vendor." }, - "code": "control 'V-61689' do\n title \"Recovery procedures and technical system features must exist to ensure\n recovery is done in a secure and verifiable manner.\"\n desc \"Application recovery and reconstitution constitutes executing an\ninformation system contingency plan comprised of activities that restore\nessential missions and business functions.\n\n Database management systems and transaction-based processing systems are\nexamples of information systems that are transaction-based. Transaction\nrollback and transaction journaling are examples of mechanisms supporting\ntransaction recovery.\n\n A DBMS may be vulnerable to use of compromised data or other critical files\nduring recovery. Use of compromised files could introduce maliciously altered\napplication code, relaxed security settings or loss of data integrity. Where\navailable, DBMS mechanisms to ensure use of only trusted files can help protect\nthe database from this type of compromise during DBMS recovery.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000144-DB-000101'\n tag \"gid\": 'V-61689'\n tag \"rid\": 'SV-76179r1_rule'\n tag \"stig_id\": 'O121-C2-012000'\n tag \"fix_id\": 'F-67603r1_fix'\n tag \"cci\": ['CCI-000553']\n tag \"nist\": ['CP-10 (2)', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Review DBMS recovery procedures and technical system features\n to determine if mechanisms exist and are in place to specify use of trusted\n files during DBMS recovery.\n\n If recovery procedures do not exist or are not sufficient to ensure recovery is\n done in a secure and verifiable manner, this is a finding.\n\n If system features exist and are not employed or not employed sufficiently,\n this is a finding.\n\n If circumstances that can inhibit a trusted recovery are not documented and\n appropriate mitigating procedures have not been put in place, this is a finding.\n\n Review the database backup strategy with the system administrator. Consider\n using Oracle RMAN with an encrypted backup to insure the backed up files can be\n trusted not to be compromised.\"\n tag \"fix\": \"Implement DBMS recovery procedures and employ technical system\n features to specify trusted files during DBMS recovery. Test the solution and\n review the site-specific criteria to ensure that the backup and recovery\n process uses trusted files.\n\n Ensure circumstances that can inhibit a trusted recovery are documented and\n appropriate mitigating procedures have been put in place.\n\n Oracle recommends using RMAN Backup and encrypting backup files. With\n encrypted files stored on a mount point with limited access, the integrity of\n the files can be trusted.\n\n - - - - -\n Notes on Oracle Backup and Recovery Solutions\n\n When implementing a backup and recovery strategy, have the following solutions\n available:\n\n -- Recovery Manager (RMAN)\n Recovery Manager is fully integrated with the Oracle database to perform a\n range of backup and recovery activities, including maintaining an RMAN\n repository of historical data about backups. Can access RMAN through the\n command line or through Oracle Enterprise Manager.\n\n -- User-managed backup and recovery\n In this solution, perform backup and recovery with a mixture of host operating\n system commands and SQL*Plus recovery commands. Responsible for determining all\n aspects of when and how backups and recovery are done.\n\n -- Media management\n If not wanting to use RMAN with an encrypted backup, consider configuring RMAN\n to make backups to a media manager. On most platforms, to back up to and\n restore from sequential media such as tape, must integrate a media manager with\n the Oracle database. Can use Oracle Secure Backup, which supports both database\n and file system backups to tape, as the media manager. See Oracle Secure Backup\n Administrator's Guide to learn how to set up RMAN for use specifically with\n Oracle Secure Backup.\n\n These solutions are supported by Oracle and are fully documented, but RMAN is\n the preferred solution for database backup and recovery. RMAN provides a common\n interface for backup tasks across different host operating systems and offers\n several backup techniques not available through user-managed methods.\n\n -- Incremental backups:\n An incremental backup stores only blocks changed since a previous backup.\n Thus, they provide more compact backups and faster recovery, thereby reducing\n the need to apply redo during data file media recovery. If enabling block\n change tracking, then can improve performance by avoiding full scans of every\n input data file. Can use the BACKUP INCREMENTAL command to perform incremental\n backups.\n\n -- Block media recovery:\n Can repair a data file with only a small number of corrupt data blocks without\n taking it off-line or restoring it from backup. Can use the RECOVER BLOCK\n command to perform block media recovery.\n\n -- Binary compression:\n A binary compression mechanism integrated into Oracle Database reduces the size\n of backups.\n\n -- Encrypted backups:\n RMAN uses backup encryption capabilities integrated into Oracle Database to\n store backup sets in an encrypted format. To create encrypted backups on disk,\n the database must use the Advanced Security Option. To create encrypted backups\n directly on tape, RMAN must use the Oracle Secure Backup SBT interface but does\n not require the Advanced Security Option.\n\n -- Automated database duplication:\n Easily creates a copy of the database, supporting various storage\n configurations, including direct duplication between ASM databases.\n\n -- Cross-platform data conversion:\n Whether using RMAN or user-managed methods, can supplement physical backups\n with logical backups of schema objects made with Data Pump Export utility. Can\n later use Data Pump Import to re-create data after restore and recovery.\n Logical backups are mostly beyond the scope of the backup and recovery\n documentation.\"\n describe 'A manual review is required to ensure recovery procedures and technical system features exist to ensure\n recovery is done in a secure and verifiable manner' do\n skip 'A manual review is required to ensure recovery procedures and technical system features exist to ensure\n recovery is done in a secure and verifiable manner'\n end\nend\n", + "code": "control 'V-61487' do\n title \"DBMS production application and data directories must be protected\n from developers on shared production/development DBMS host systems.\"\n desc \"Developer roles must not be assigned DBMS administrative privileges to\n production DBMS application and data directories. The separation of production\n DBA and developer roles helps protect the production system from unauthorized,\n malicious or unintentional interruption due to development activities.\"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000516-DB-999900'\n tag \"gid\": 'V-61487'\n tag \"rid\": 'SV-75977r1_rule'\n tag \"stig_id\": 'O121-BP-024100'\n tag \"fix_id\": 'F-67403r1_fix'\n tag \"cci\": ['CCI-000366']\n tag \"nist\": ['CM-6 b', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"If the DBMS or DBMS host is not shared by production and\n development activities, this check is not a finding.\n\n Review OS DBA group membership.\n\n If any developer accounts, as identified in the System Security Plan, have been\n assigned DBA privileges, this is a finding.\n\n Note: Though shared production/non-production DBMS installations was allowed\n under previous database STIG guidance, doing so may place it in violation of\n OS, Application, Network or Enclave STIG guidance. Ensure that any shared\n production/non-production DBMS installation meets STIG guidance requirements at\n all levels or mitigate any conflicts in STIG guidance with the AO.\"\n tag \"fix\": \"Create separate DBMS host OS groups for developer and production\n DBAs.\n\n Do not assign production DBA OS group membership to accounts used for\n development.\n\n Remove development accounts from production DBA OS group membership.\n\n Recommend establishing a dedicated DBMS host for production DBMS installations.\n A dedicated host system in this case refers to an instance of the operating\n system at a minimum. The operating system may reside on a virtual host machine\n where supported by the DBMS vendor.\"\n describe 'A manual review is required to ensure DBMS production application and data directories are protected\n from developers on shared production/development DBMS host systems.' do\n skip 'A manual review is required to ensure DBMS production application and data directories are protected\n from developers on shared production/development DBMS host systems.'\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61689.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61487.rb", "line": 1 }, - "id": "V-61689" + "id": "V-61487" }, { - "title": "The DBMS must support organizational requirements to enforce password\n encryption for storage.", - "desc": "Applications must enforce password encryption when storing passwords.\n Passwords need to be protected at all times, and encryption is the standard\n method for protecting passwords. If passwords are not encrypted, they can be\n plainly read and easily compromised.\n\n Database passwords stored in clear text are vulnerable to unauthorized\n disclosure. Database passwords must always be encoded or encrypted when stored\n internally or externally to the DBMS.\n\n Transport Layer Security (TLS) is the successor protocol to Secure Sockets\n Layer (SSL). Although the Oracle configuration parameters have names including\n 'SSL', such as SSL_VERSION and SSL_CIPHER_SUITES, they refer to TLS.", + "title": "Database software directories, including DBMS configuration files,\n must be stored in dedicated directories, or DASD pools, separate from the host\n OS and other applications.", + "desc": "When dealing with change control issues, it should be noted, any\n changes to the hardware, software, and/or firmware components of the\n information system and/or application can potentially have significant effects\n on the overall security of the system.\n\n Multiple applications can provide a cumulative negative effect. A\n vulnerability and subsequent exploit to one application can lead to an exploit\n of other applications sharing the same security context. For example, an\n exploit to a web server process that leads to unauthorized administrative\n access to host system directories can most likely lead to a compromise of all\n applications hosted by the same system. Database software not installed using\n dedicated directories both threatens and is threatened by other hosted\n applications. Access controls defined for one application may by default\n provide access to the other application's database objects or directories. Any\n method that provides any level of separation of security context assists in the\n protection between applications.", "descriptions": { - "default": "Applications must enforce password encryption when storing passwords.\n Passwords need to be protected at all times, and encryption is the standard\n method for protecting passwords. If passwords are not encrypted, they can be\n plainly read and easily compromised.\n\n Database passwords stored in clear text are vulnerable to unauthorized\n disclosure. Database passwords must always be encoded or encrypted when stored\n internally or externally to the DBMS.\n\n Transport Layer Security (TLS) is the successor protocol to Secure Sockets\n Layer (SSL). Although the Oracle configuration parameters have names including\n 'SSL', such as SSL_VERSION and SSL_CIPHER_SUITES, they refer to TLS." + "default": "When dealing with change control issues, it should be noted, any\n changes to the hardware, software, and/or firmware components of the\n information system and/or application can potentially have significant effects\n on the overall security of the system.\n\n Multiple applications can provide a cumulative negative effect. A\n vulnerability and subsequent exploit to one application can lead to an exploit\n of other applications sharing the same security context. For example, an\n exploit to a web server process that leads to unauthorized administrative\n access to host system directories can most likely lead to a compromise of all\n applications hosted by the same system. Database software not installed using\n dedicated directories both threatens and is threatened by other hosted\n applications. Access controls defined for one application may by default\n provide access to the other application's database objects or directories. Any\n method that provides any level of separation of security context assists in the\n protection between applications." }, - "impact": 0, - "refs": [ - { - "ref": [] - } - ], + "impact": 0.5, + "refs": [], "tags": { - "gtitle": "SRG-APP-000171-DB-000074", - "gid": "V-61733", - "rid": "SV-76223r2_rule", - "stig_id": "O121-C2-014600", - "fix_id": "F-67649r5_fix", + "gtitle": "SRG-APP-000133-DB-000199", + "gid": "V-61875", + "rid": "SV-76365r1_rule", + "stig_id": "O121-P2-010900", + "fix_id": "F-67791r1_fix", "cci": [ - "CCI-000196" + "CCI-001499" ], "nist": [ - "IA-5 (1) (c)", + "CM-5 (6)", "Rev_4" ], "false_negatives": null, @@ -764,35 +818,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "(Oracle stores and displays its passwords in encrypted form.\n Nevertheless, this should be verified by reviewing the relevant system views,\n along with the other items to be checked here.)\n\n Ask the DBA to review the list of DBMS database objects, database configuration\n files, associated scripts, and applications defined within and external to the\n DBMS that access the database. The list should also include files, tables, or\n settings used to configure the operational environment for the DBMS and for\n interactive DBMS user accounts.\n\n Ask the DBA and/or ISSO to determine if any DBMS database objects, database\n configuration files, associated scripts, and applications defined within or\n external to the DBMS that access the database, and DBMS/user environment\n files/settings/tables, contain database passwords. If any do, confirm that DBMS\n passwords stored internally or externally to the DBMS are encoded or encrypted.\n\n If any passwords are stored in clear text, this is a finding.\n\n Ask the DBA/SA/Application Support staff if they have created an external\n password store for applications, batch jobs, and scripts to use. Verify that\n all passwords stored there are encrypted.\n\n If a password store is used and any password is not encrypted, this is a\n finding.\n\n - - - - -\n The following are notes on implementing a Secure External Password Store using\n Oracle Wallet.\n\n You can store password credentials for connecting to databases by using a\n client-side Oracle wallet. An Oracle wallet is a secure software container that\n stores authentication and signing credentials.\n\n This wallet usage can simplify large-scale deployments that rely on password\n credentials for connecting to databases. When this feature is configured,\n application code, batch jobs, and scripts no longer need embedded user names\n and passwords. This reduces risk because the passwords are no longer exposed,\n and password management policies are more easily enforced without changing\n application code whenever user names or passwords change.\n\n The external password store of the wallet is separate from the area where\n public key infrastructure (PKI) credentials are stored. Consequently, you\n cannot use Oracle Wallet Manager to manage credentials in the external password\n store of the wallet. Instead, use the command-line utility mkstore to manage\n these credentials.\n\n How Does the External Password Store Work?\n\n Typically, users (and applications, batch jobs, and scripts) connect to\n databases by using a standard CONNECT statement that specifies a database\n connection string. This string can include a user name and password, and an\n Oracle Net service name identifying the database on an Oracle Database network.\n If the password is omitted, the connection prompts the user for the password.\n\n For example, the service name could be the URL that identifies that database,\n or a TNS alias entered in the tnsnames.ora file in the database. Another\n possibility is a host:port:sid string.\n\n The following examples are standard CONNECT statements that could be used for a\n client that is not configured to use the external password store:\n\n CONNECT salesapp@sales_db.us.example.com\n Enter password: password\n\n CONNECT salesapp@orasales\n Enter password: password\n\n CONNECT salesapp@ourhost37:1527:DB17\n Enter password: password\n\n In these examples, salesapp is the user name, with the unique connection string\n for the database shown as specified in three different ways. Could use its URL\n sales_db.us.example.com, or its TNS alias, orasales, from the tnsnames.ora\n file, or its host:port:sid string.\n\n However, when clients are configured to use the secure external password store,\n applications can connect to a database with the following CONNECT statement\n syntax, without specifying database logon credentials:\n\n CONNECT /@db_connect_string\n\n CONNECT /@db_connect_string AS SYSDBA\n\n CONNECT /@db_connect_string AS SYSOPER\n\n In this specification, db_connect_string is a valid connection string to access\n the intended database, such as the service name, URL, or alias as shown in the\n earlier examples. Each user account must have its own unique connection string;\n cannot create one connection string for multiple users.\n\n In this case, the database credentials, user name and password, are securely\n stored in an Oracle wallet created for this purpose. The autologon feature of\n this wallet is turned on, so the system does not need a password to open the\n wallet. From the wallet, it gets the credentials to access the database for the\n user they represent.", - "fix": "Develop, document, and maintain a list of DBMS database objects,\n database configuration files, associated scripts, and applications defined\n within or external to the DBMS that access the database, and DBMS/user\n environment files/settings in the System Security Plan.\n\n Record whether they do or do not contain DBMS passwords. If passwords are\n present, ensure they are encoded or encrypted and protected by host system\n security.\n\n - - - - -\n The following are notes on implementing a Secure External Password Store using\n Oracle Wallet.\n\n Oracle provides the capability to provide for a secure external password\n facility. Use the Oracle mkstore to create a secure storage area for passwords\n for applications, batch jobs, and scripts to use, or deploy a site-authorized\n facility to perform this function.\n\n Check to see what has been stored in the Oracle External Password Store\n\n To view all contents of a client wallet external password store, check specific\n credentials by viewing them. Listing the external password store contents\n provides information that can be used to decide whether to add or delete\n credentials from the store. To list the contents of the external password\n store, enter the following command at the command line:\n\n $ mkstore -wrl wallet_location -listCredential\n\n For example: $ mkstore -wrl c:\\oracle\\product\\12.1.0\\db_1\\wallets\n -listCredential\n\n The wallet_location specifies the path to the directory where the wallet, whose\n external password store contents is to be viewed, is located. This command\n lists all of the credential database service names (aliases) and the\n corresponding user name (schema) for that database. Passwords are not listed.\n\n Configuring Clients to Use the External Password Store\n\n If the client is already configured to use external authentication, such as\n Windows native authentication or Transport Layer Security (TLS), then Oracle\n Database uses that authentication method. The same credentials used for this\n type of authentication are typically also used to log on to the database.\n\n For clients not using such authentication methods or wanting to override them\n for database authentication, can set the SQLNET.WALLET_OVERRIDE parameter in\n sqlnet.ora to TRUE. The default value for SQLNET.WALLET_OVERRIDE is FALSE,\n allowing standard use of authentication credentials as before.\n\n If wanting a client to use the secure external password store feature, then\n perform the following configuration task:\n\n 1. Create a wallet on the client by using the following syntax at the command\n line:\n\n mkstore -wrl wallet_location -create\n\n For example: mkstore -wrl c:\\oracle\\product\\12.1.0\\db_1\\wallets -create\n Enter password: password\n\n The wallet_location is the path to the directory where the wallet is to be\n created and stored. This command creates an Oracle wallet with the autologon\n feature enabled at the location specified. The autologon feature enables the\n client to access the wallet contents without supplying a password.\n\n The mkstore utility -create option uses password complexity verification.\n\n 2. Create database connection credentials in the wallet by using the following\n syntax at the command line:\n\n mkstore -wrl wallet_location -createCredential db_connect_string username\n Enter password: password\n\n For example: mkstore -wrl c:\\oracle\\product\\12.1.0\\db_1\\wallets\n -createCredential oracle system\n Enter password: password\n\n In this specification, the wallet_location is the path to the directory where\n the wallet was created. The db_connect_string used in the CONNECT\n /@db_connect_string statement must be identical to the db_connect_string\n specified in the -createCredential command. The db_connect_string is the TNS\n alias used to specify the database in the tnsnames.ora file or any service name\n used to identify the database on an Oracle network. By default, tnsnames.ora is\n located in the $ORACLE_HOME/network/admin directory on UNIX systems and in\n ORACLE_HOME etwork\\admin on Windows. The username is the database logon credential. When\n prompted, enter the password for this user.\n\n 3. In the client sqlnet.ora file, enter the WALLET_LOCATION parameter and set\n it to the directory location of the wallet created in Step 1. For example, if\n created the wallet in $ORACLE_HOME/network/admin and Oracle home is set to\n /private/ora12, then need to enter the following into client sqlnet.ora file:\n\n WALLET_LOCATION =\n (SOURCE =\n (METHOD = FILE)\n (METHOD_DATA =\n (DIRECTORY = /private/ora12/network/admin)\n )\n )\n\n 4. In the client sqlnet.ora file, enter the SQLNET.WALLET_OVERRIDE parameter\n and set it to TRUE as follows:\n\n SQLNET.WALLET_OVERRIDE = TRUE\n\n This setting causes all CONNECT /@db_connect_string statements to use the\n information in the wallet at the specified location to authenticate to\n databases.\n\n When external authentication is in use, an authenticated user with such a\n wallet can use the CONNECT /@db_connect_string syntax to access the previously\n specified databases without providing a user name and password. However, if a\n user fails that external authentication, then these connect statements also\n fail.\n\n Below is a sample sqlnet.ora file with the WALLET_LOCATION and the\n SQLNET.WALLET_OVERRIDE parameters set as described in Steps 3 and 4.\n\n WALLET_LOCATION =\n (SOURCE =\n (METHOD = FILE)\n (METHOD_DATA =\n (DIRECTORY = /private/ora12/network/admin)\n )\n )\n SQLNET.WALLET_OVERRIDE = TRUE\n SSL_CLIENT_AUTHENTICATION = FALSE\n SSL_VERSION = 1.2 or 1.1\n\n Note: \"SSL_VERSION = 1.2 or 1.1\" is the actual value, not a suggestion to use\n one or the other.\n\n (Note: This assumes that a single sqlnet.ora file, in the default location, is\n in use. Please see the supplemental file \"Non-default sqlnet.ora\n configurations.pdf\" for how to find multiple and/or differently located\n sqlnet.ora files.)" + "check": "Review the DBMS software library directory and note other root\n directories located on the same disk directory or any subdirectories. If any\n non-DBMS software directories exist on the disk directory, examine or\n investigate their use.\n\n If any of the directories are used by other applications, including third-party\n applications that use the DBMS, this is a finding.\n\n Only applications that are required for the functioning and administration, not\n use, of the DBMS should be located on the same disk directory as the DBMS\n software libraries.\n\n For databases located on mainframes, confirm that the database and its\n configuration files are isolated in their own DASD pools.\n\n If database software and database configuration files share DASD with other\n applications, this is a finding.", + "fix": "Install all applications on directories, or pools, separate from\n the DBMS software library directory. Re-locate any directories or re-install\n other application software that currently shares the DBMS software library\n directory to separate directories.\n\n For mainframe-based databases, locate database software and configuration files\n in separate DASD pools from other mainframe applications." }, - "code": " control 'V-61733' do\n impact 0.0\n describe 'This control is not applicable on oracle within aws rds, as aws manages the operating system in which the oracle database is running on' do\n skip 'This control is not applicable on oracle within aws rds, as aws manages the operating system in which the oracle database is running on'\n end\n end\n", + "code": "control 'V-61875' do\n title \"Database software directories, including DBMS configuration files,\n must be stored in dedicated directories, or DASD pools, separate from the host\n OS and other applications.\"\n desc \"When dealing with change control issues, it should be noted, any\n changes to the hardware, software, and/or firmware components of the\n information system and/or application can potentially have significant effects\n on the overall security of the system.\n\n Multiple applications can provide a cumulative negative effect. A\n vulnerability and subsequent exploit to one application can lead to an exploit\n of other applications sharing the same security context. For example, an\n exploit to a web server process that leads to unauthorized administrative\n access to host system directories can most likely lead to a compromise of all\n applications hosted by the same system. Database software not installed using\n dedicated directories both threatens and is threatened by other hosted\n applications. Access controls defined for one application may by default\n provide access to the other application's database objects or directories. Any\n method that provides any level of separation of security context assists in the\n protection between applications.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000133-DB-000199'\n tag \"gid\": 'V-61875'\n tag \"rid\": 'SV-76365r1_rule'\n tag \"stig_id\": 'O121-P2-010900'\n tag \"fix_id\": 'F-67791r1_fix'\n tag \"cci\": ['CCI-001499']\n tag \"nist\": ['CM-5 (6)', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Review the DBMS software library directory and note other root\n directories located on the same disk directory or any subdirectories. If any\n non-DBMS software directories exist on the disk directory, examine or\n investigate their use.\n\n If any of the directories are used by other applications, including third-party\n applications that use the DBMS, this is a finding.\n\n Only applications that are required for the functioning and administration, not\n use, of the DBMS should be located on the same disk directory as the DBMS\n software libraries.\n\n For databases located on mainframes, confirm that the database and its\n configuration files are isolated in their own DASD pools.\n\n If database software and database configuration files share DASD with other\n applications, this is a finding.\"\n tag \"fix\": \"Install all applications on directories, or pools, separate from\n the DBMS software library directory. Re-locate any directories or re-install\n other application software that currently shares the DBMS software library\n directory to separate directories.\n\n For mainframe-based databases, locate database software and configuration files\n in separate DASD pools from other mainframe applications.\"\n describe 'A manual review is required to ensure Database software directories, including DBMS configuration files,\n are stored in dedicated directories, or DASD pools, separate from the host\n OS and other applications' do\n skip 'A manual review is required to ensure Database software directories, including DBMS configuration files,\n are stored in dedicated directories, or DASD pools, separate from the host\n OS and other applications'\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61733.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61875.rb", "line": 1 }, - "id": "V-61733" + "id": "V-61875" }, { - "title": "The DBMS must uniquely identify and authenticate non-organizational\n users (or processes acting on behalf of non-organizational users).", - "desc": "Non-organizational users include all information system users other\n than organizational users which include organizational employees or individuals\n the organization deems to have equivalent status of employees (e.g.,\n contractors, guest researchers, individuals from allied nations).\n\n Non-organizational users shall be uniquely identified and authenticated for\n all accesses other than those accesses explicitly identified and documented by\n the organization when related to the use of anonymous access, such as accessing\n a web server.\n\n Accordingly, a risk assessment is used in determining the authentication\n needs of the organization.\n\n Scalability, practicality, and security are simultaneously considered in\n balancing the need to ensure ease of use for access to federal information and\n information systems with the need to protect and adequately mitigate risk to\n organizational operations, organizational assets, individuals, other\n organizations, and the Nation.", + "title": "Unused database components, DBMS software, and database objects must\n be removed.", + "desc": "Information systems are capable of providing a wide variety of\n functions and services. Some of the functions and services, provided by\n default, may not be necessary to support essential organizational operations\n (e.g., key missions, functions).\n\n It is detrimental for applications to provide, or install by default,\n functionality exceeding requirements or mission objectives. Examples include,\n but are not limited to, installing advertising software, demonstrations, or\n browser plug-ins not related to requirements or providing a wide array of\n functionality not required for the mission.\n\n Applications must adhere to the principles of least functionality by\n providing only essential capabilities.\n\n Demonstration and sample database objects and applications present publicly\n known attack points for malicious users. These demonstration and sample objects\n are meant to provide simple examples of coding specific functions and are not\n developed to prevent vulnerabilities from being introduced to the DBMS and host\n system.\n\n Unused and unnecessary DBMS components increase the attack vector for the\n DBMS by introducing additional targets for attack. By minimizing the services\n and applications installed on the system, the number of potential\n vulnerabilities is reduced.", "descriptions": { - "default": "Non-organizational users include all information system users other\n than organizational users which include organizational employees or individuals\n the organization deems to have equivalent status of employees (e.g.,\n contractors, guest researchers, individuals from allied nations).\n\n Non-organizational users shall be uniquely identified and authenticated for\n all accesses other than those accesses explicitly identified and documented by\n the organization when related to the use of anonymous access, such as accessing\n a web server.\n\n Accordingly, a risk assessment is used in determining the authentication\n needs of the organization.\n\n Scalability, practicality, and security are simultaneously considered in\n balancing the need to ensure ease of use for access to federal information and\n information systems with the need to protect and adequately mitigate risk to\n organizational operations, organizational assets, individuals, other\n organizations, and the Nation." + "default": "Information systems are capable of providing a wide variety of\n functions and services. Some of the functions and services, provided by\n default, may not be necessary to support essential organizational operations\n (e.g., key missions, functions).\n\n It is detrimental for applications to provide, or install by default,\n functionality exceeding requirements or mission objectives. Examples include,\n but are not limited to, installing advertising software, demonstrations, or\n browser plug-ins not related to requirements or providing a wide array of\n functionality not required for the mission.\n\n Applications must adhere to the principles of least functionality by\n providing only essential capabilities.\n\n Demonstration and sample database objects and applications present publicly\n known attack points for malicious users. These demonstration and sample objects\n are meant to provide simple examples of coding specific functions and are not\n developed to prevent vulnerabilities from being introduced to the DBMS and host\n system.\n\n Unused and unnecessary DBMS components increase the attack vector for the\n DBMS by introducing additional targets for attack. By minimizing the services\n and applications installed on the system, the number of potential\n vulnerabilities is reduced." }, - "impact": 0.5, + "impact": 0, "refs": [], "tags": { - "gtitle": "SRG-APP-000180-DB-000115", - "gid": "V-61881", - "rid": "SV-76371r1_rule", - "stig_id": "O121-P2-015800", - "fix_id": "F-67797r1_fix", + "gtitle": "SRG-APP-000141-DB-000091", + "gid": "V-61679", + "rid": "SV-76169r2_rule", + "stig_id": "O121-C2-011600", + "fix_id": "F-67593r2_fix", "cci": [ - "CCI-000804" + "CCI-000381" ], "nist": [ - "IA-8", + "CM-7 a", "Rev_4" ], "false_negatives": null, @@ -805,39 +859,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Review DBMS settings to determine whether non-organizational\n users are uniquely identified and authenticated when logging onto the system.\n\n If non-organizational users are not uniquely identified and authenticated, this\n is a finding.", - "fix": "Configure DBMS settings to uniquely identify and authenticate all\n non-organizational users who log onto the system." + "check": "Run this query to produce a list of components and features\n installed with the database:\n\n SELECT comp_id, comp_name, version, status from dba_registry\n where comp_id not in ('CATALOG','CATPROC','XDB');\n\n Review the list. If unused components are installed and are not documented and\n authorized, this is a finding.\n\n Starting with releases 11.1.0.7.x and above, all products are installed by\n default and the option to customize the product/component selection is no\n longer possible with the exception of those listed here:\n\n Oracle JVM,\n Oracle Text,\n Oracle Multimedia,\n Oracle OLAP,\n Oracle Spatial,\n Oracle Label Security,\n Oracle Application Express,\n Oracle Database Vault", + "fix": "If any components are required for operation of applications that\n will be accessing the DBMS, include them in the system documentation.\n\n One cannot remove components, either via Database Configuration Assistant\n (DBCA) or manually once the database has been created, either from a container\n or a non-container database.\n\n One can, however, use DBCA to create a non-container database and remove\n components during the creation process, before the database is created.\n\n When using DBCA to create a custom non-container database, select\n creation mode = advanced\n Database Template = Custom\n Database Options..Database Component.\n\n Components that can be selected or de-selected are:\n Oracle JVM, Oracle Text, Oracle Multimedia, Oracle OLAP, Oracle Spatial, Oracle\n Label Security, Oracle Application Express, Oracle Database Vault\n\n For a container database (CDB), the CDB$ROOT must have all possible database\n components available. This is because, when a pluggable database (PDB) is\n plugged into the CDB, the CDB must have the same components installed as the\n PDB. Since we do not know what components the PDBS may have, the CDB must be\n able to support all possible PDB configurations.\n\n Components installed in the CDB$ROOT do not need to be licensed. Components\n are only considered to be used if they are installed in the PDB.\n\n To configure a PDB to only use specific components, do the following:\n\n 1) Create a non-CDB 12.1 database and configure that database with the\n components desired.\n\n 2) Plug the non-CDB database into a CDB database, creating a new PDB. If\n wanted, can then create additional clones from the new PDB." }, - "code": "control 'V-61881' do\n title \"The DBMS must uniquely identify and authenticate non-organizational\n users (or processes acting on behalf of non-organizational users).\"\n desc \"Non-organizational users include all information system users other\n than organizational users which include organizational employees or individuals\n the organization deems to have equivalent status of employees (e.g.,\n contractors, guest researchers, individuals from allied nations).\n\n Non-organizational users shall be uniquely identified and authenticated for\n all accesses other than those accesses explicitly identified and documented by\n the organization when related to the use of anonymous access, such as accessing\n a web server.\n\n Accordingly, a risk assessment is used in determining the authentication\n needs of the organization.\n\n Scalability, practicality, and security are simultaneously considered in\n balancing the need to ensure ease of use for access to federal information and\n information systems with the need to protect and adequately mitigate risk to\n organizational operations, organizational assets, individuals, other\n organizations, and the Nation.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000180-DB-000115'\n tag \"gid\": 'V-61881'\n tag \"rid\": 'SV-76371r1_rule'\n tag \"stig_id\": 'O121-P2-015800'\n tag \"fix_id\": 'F-67797r1_fix'\n tag \"cci\": ['CCI-000804']\n tag \"nist\": ['IA-8', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Review DBMS settings to determine whether non-organizational\n users are uniquely identified and authenticated when logging onto the system.\n\n If non-organizational users are not uniquely identified and authenticated, this\n is a finding.\"\n tag \"fix\": \"Configure DBMS settings to uniquely identify and authenticate all\n non-organizational users who log onto the system.\"\n describe 'A manual review is required to ensure the DBMS uniquely identifies and authenticates non-organizational\n users (or processes acting on behalf of non-organizational users).' do\n skip 'A manual review is required to ensure the DBMS uniquely identifies and authenticates non-organizational\n users (or processes acting on behalf of non-organizational users).'\n end\nend\n", + "code": "control 'V-61679' do\n title \"Unused database components, DBMS software, and database objects must\n be removed.\"\n desc \"Information systems are capable of providing a wide variety of\n functions and services. Some of the functions and services, provided by\n default, may not be necessary to support essential organizational operations\n (e.g., key missions, functions).\n\n It is detrimental for applications to provide, or install by default,\n functionality exceeding requirements or mission objectives. Examples include,\n but are not limited to, installing advertising software, demonstrations, or\n browser plug-ins not related to requirements or providing a wide array of\n functionality not required for the mission.\n\n Applications must adhere to the principles of least functionality by\n providing only essential capabilities.\n\n Demonstration and sample database objects and applications present publicly\n known attack points for malicious users. These demonstration and sample objects\n are meant to provide simple examples of coding specific functions and are not\n developed to prevent vulnerabilities from being introduced to the DBMS and host\n system.\n\n Unused and unnecessary DBMS components increase the attack vector for the\n DBMS by introducing additional targets for attack. By minimizing the services\n and applications installed on the system, the number of potential\n vulnerabilities is reduced.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000141-DB-000091'\n tag \"gid\": 'V-61679'\n tag \"rid\": 'SV-76169r2_rule'\n tag \"stig_id\": 'O121-C2-011600'\n tag \"fix_id\": 'F-67593r2_fix'\n tag \"cci\": ['CCI-000381']\n tag \"nist\": ['CM-7 a', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Run this query to produce a list of components and features\n installed with the database:\n\n SELECT comp_id, comp_name, version, status from dba_registry\n where comp_id not in ('CATALOG','CATPROC','XDB');\n\n Review the list. If unused components are installed and are not documented and\n authorized, this is a finding.\n\n Starting with releases 11.1.0.7.x and above, all products are installed by\n default and the option to customize the product/component selection is no\n longer possible with the exception of those listed here:\n\n Oracle JVM,\n Oracle Text,\n Oracle Multimedia,\n Oracle OLAP,\n Oracle Spatial,\n Oracle Label Security,\n Oracle Application Express,\n Oracle Database Vault\"\n tag \"fix\": \"If any components are required for operation of applications that\n will be accessing the DBMS, include them in the system documentation.\n\n One cannot remove components, either via Database Configuration Assistant\n (DBCA) or manually once the database has been created, either from a container\n or a non-container database.\n\n One can, however, use DBCA to create a non-container database and remove\n components during the creation process, before the database is created.\n\n When using DBCA to create a custom non-container database, select\n creation mode = advanced\n Database Template = Custom\n Database Options..Database Component.\n\n Components that can be selected or de-selected are:\n Oracle JVM, Oracle Text, Oracle Multimedia, Oracle OLAP, Oracle Spatial, Oracle\n Label Security, Oracle Application Express, Oracle Database Vault\n\n For a container database (CDB), the CDB$ROOT must have all possible database\n components available. This is because, when a pluggable database (PDB) is\n plugged into the CDB, the CDB must have the same components installed as the\n PDB. Since we do not know what components the PDBS may have, the CDB must be\n able to support all possible PDB configurations.\n\n Components installed in the CDB$ROOT do not need to be licensed. Components\n are only considered to be used if they are installed in the PDB.\n\n To configure a PDB to only use specific components, do the following:\n\n 1) Create a non-CDB 12.1 database and configure that database with the\n components desired.\n\n 2) Plug the non-CDB database into a CDB database, creating a new PDB. If\n wanted, can then create additional clones from the new PDB.\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n list_of_installed_components = sql.query(\"SELECT comp_id, comp_name, version, status from dba_registry where comp_id not in ('CATALOG','CATPROC','XDB');\").column('comp_name').uniq\n if list_of_installed_components.empty?\n impact 0.0\n describe 'There are no oracle database components installed, control N/A' do\n skip 'TThere are no oracle database components installed, control N/A'\n end\n else\n list_of_installed_components.each do |component|\n describe \"The installed oracle database components: #{component}\" do\n subject { component }\n it { should be_in input('allowed_oracledb_components') }\n end\n end\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61881.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61679.rb", "line": 1 }, - "id": "V-61881" + "id": "V-61679" }, { - "title": "The DBMS must support organizational requirements to enforce password\n complexity by the number of special characters used.", - "desc": "Password complexity or strength is a measure of the effectiveness of a\n password in resisting attempts at guessing and brute-force attacks.\n\n Password complexity is one factor of several that determine how long it\n takes to crack a password. The more complex the password is, the greater the\n number of possible combinations that need to be tested before the password is\n compromised.\n\n Use of a complex password helps to increase the time and resources required\n to compromise the password.\n\n Note that user authentication and account management must be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP This requirement applies to cases where it is necessary to\n have accounts directly managed by Oracle.", + "title": "The Oracle REMOTE_OS_ROLES parameter must be set to FALSE.", + "desc": "Setting REMOTE_OS_ROLES to TRUE allows operating system groups to\n control Oracle roles. The default value of FALSE causes roles to be identified\n and managed by the database. If REMOTE_OS_ROLES is set to TRUE, a remote user\n could impersonate another operating system user over a network connection.", "descriptions": { - "default": "Password complexity or strength is a measure of the effectiveness of a\n password in resisting attempts at guessing and brute-force attacks.\n\n Password complexity is one factor of several that determine how long it\n takes to crack a password. The more complex the password is, the greater the\n number of possible combinations that need to be tested before the password is\n compromised.\n\n Use of a complex password helps to increase the time and resources required\n to compromise the password.\n\n Note that user authentication and account management must be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP This requirement applies to cases where it is necessary to\n have accounts directly managed by Oracle." + "default": "Setting REMOTE_OS_ROLES to TRUE allows operating system groups to\n control Oracle roles. The default value of FALSE causes roles to be identified\n and managed by the database. If REMOTE_OS_ROLES is set to TRUE, a remote user\n could impersonate another operating system user over a network connection." }, - "impact": 0.5, - "refs": [ - { - "ref": [] - } - ], + "impact": 0.7, + "refs": [], "tags": { - "gtitle": "SRG-APP-000169-DB-000176", - "gid": "V-61729", - "rid": "SV-76219r1_rule", - "stig_id": "O121-C2-014400", - "fix_id": "F-67645r1_fix", + "gtitle": "SRG-APP-000516-DB-999900", + "gid": "V-61427", + "rid": "SV-75917r1_rule", + "stig_id": "O121-BP-022000", + "fix_id": "F-67343r1_fix", "cci": [ - "CCI-001619" + "CCI-000366" ], "nist": [ - "IA-5 (1) (a)", + "CM-6 b", "Rev_4" ], "false_negatives": null, @@ -850,39 +900,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "If all user accounts are managed and authenticated by the OS or\n an enterprise-level authentication/access mechanism, and not by Oracle, this is\n not a finding.\n\n For each profile that can be applied to accounts where authentication is under\n Oracle's control, determine the password verification function, if any, that is\n in use:\n\n SELECT * FROM SYS.DBA_PROFILES\n WHERE RESOURCE_NAME = 'PASSWORD_VERIFY_FUNCTION'\n [AND PROFILE NOT IN ()]\n ORDER BY PROFILE;\n Bearing in mind that a profile can inherit from another profile, and the root\n profile is called DEFAULT, determine the name of the password verification\n function effective for each profile.\n\n If, for any profile, the function name is null, this is a finding.\n\n For each password verification function, examine its source code.\n\n If it does not enforce the organization-defined minimum number of special\n characters (1 unless otherwise specified), this is a finding.", - "fix": "If all user accounts are authenticated by the OS or an\n enterprise-level authentication/access mechanism, and not by Oracle, no fix to\n the DBMS is required.\n\n If any user accounts are managed by Oracle: Develop, test and implement a\n password verification function that enforces DoD requirements.\n\n (Oracle supplies a sample function called ORA12C_STRONG_VERIFY_FUNCTION, in the\n script file\n /RDBMS/ADMIN/utlpwdmg.sql. This can be used as the starting point\n for a customized function.)" + "check": "From SQL*Plus:\n\n select value from v$parameter where name = 'remote_os_roles';\n\n If the returned value is not FALSE or not documented in the System Security\n Plan as required, this is a finding.", + "fix": "Document remote OS roles in the System Security Plan.\n\n If not required, disable use of remote OS roles.\n\n From SQL*Plus:\n\n alter system set remote_os_roles = FALSE scope = spfile;\n\n The above SQL*Plus command will set the parameter to take effect at next system\n startup." }, - "code": "control 'V-61729' do\n title \"The DBMS must support organizational requirements to enforce password\n complexity by the number of special characters used.\"\n desc \"Password complexity or strength is a measure of the effectiveness of a\n password in resisting attempts at guessing and brute-force attacks.\n\n Password complexity is one factor of several that determine how long it\n takes to crack a password. The more complex the password is, the greater the\n number of possible combinations that need to be tested before the password is\n compromised.\n\n Use of a complex password helps to increase the time and resources required\n to compromise the password.\n\n Note that user authentication and account management must be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP This requirement applies to cases where it is necessary to\n have accounts directly managed by Oracle.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000169-DB-000176'\n tag \"gid\": 'V-61729'\n tag \"rid\": 'SV-76219r1_rule'\n tag \"stig_id\": 'O121-C2-014400'\n tag \"fix_id\": 'F-67645r1_fix'\n tag \"cci\": ['CCI-001619']\n tag \"nist\": ['IA-5 (1) (a)', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"If all user accounts are managed and authenticated by the OS or\n an enterprise-level authentication/access mechanism, and not by Oracle, this is\n not a finding.\n\n For each profile that can be applied to accounts where authentication is under\n Oracle's control, determine the password verification function, if any, that is\n in use:\n\n SELECT * FROM SYS.DBA_PROFILES\n WHERE RESOURCE_NAME = 'PASSWORD_VERIFY_FUNCTION'\n [AND PROFILE NOT IN ()]\n ORDER BY PROFILE;\n Bearing in mind that a profile can inherit from another profile, and the root\n profile is called DEFAULT, determine the name of the password verification\n function effective for each profile.\n\n If, for any profile, the function name is null, this is a finding.\n\n For each password verification function, examine its source code.\n\n If it does not enforce the organization-defined minimum number of special\n characters (1 unless otherwise specified), this is a finding.\"\n tag \"fix\": \"If all user accounts are authenticated by the OS or an\n enterprise-level authentication/access mechanism, and not by Oracle, no fix to\n the DBMS is required.\n\n If any user accounts are managed by Oracle: Develop, test and implement a\n password verification function that enforces DoD requirements.\n\n (Oracle supplies a sample function called ORA12C_STRONG_VERIFY_FUNCTION, in the\n script file\n /RDBMS/ADMIN/utlpwdmg.sql. This can be used as the starting point\n for a customized function.)\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n query = %{\n SELECT PROFILE, RESOURCE_NAME, LIMIT FROM DBA_PROFILES WHERE PROFILE =\n '%s' AND RESOURCE_NAME = 'PASSWORD_VERIFY_FUNCTION'\n }\n\n user_profiles = sql.query('SELECT profile FROM dba_users;').column('profile').uniq\n\n user_profiles.each do |profile|\n next if profile == \"RDSADMIN\"\n password_verify_function = sql.query(format(query, profile: profile)).column('limit')\n\n describe \"The oracle database account password verify function for profile: #{profile}\" do\n subject { password_verify_function }\n it { should_not eq ['NULL'] }\n end\n end\n if user_profiles.empty?\n describe 'There are no user profiles, therefore this control is NA' do\n skip 'There are no user profiles, therefore this control is NA'\n end\n end\nend\n", + "code": "control 'V-61427' do\n title 'The Oracle REMOTE_OS_ROLES parameter must be set to FALSE.'\n desc \"Setting REMOTE_OS_ROLES to TRUE allows operating system groups to\n control Oracle roles. The default value of FALSE causes roles to be identified\n and managed by the database. If REMOTE_OS_ROLES is set to TRUE, a remote user\n could impersonate another operating system user over a network connection.\"\n impact 0.7\n tag \"gtitle\": 'SRG-APP-000516-DB-999900'\n tag \"gid\": 'V-61427'\n tag \"rid\": 'SV-75917r1_rule'\n tag \"stig_id\": 'O121-BP-022000'\n tag \"fix_id\": 'F-67343r1_fix'\n tag \"cci\": ['CCI-000366']\n tag \"nist\": ['CM-6 b', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"From SQL*Plus:\n\n select value from v$parameter where name = 'remote_os_roles';\n\n If the returned value is not FALSE or not documented in the System Security\n Plan as required, this is a finding.\"\n tag \"fix\": \"Document remote OS roles in the System Security Plan.\n\n If not required, disable use of remote OS roles.\n\n From SQL*Plus:\n\n alter system set remote_os_roles = FALSE scope = spfile;\n\n The above SQL*Plus command will set the parameter to take effect at next system\n startup.\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n parameter = sql.query(\"select value from v$parameter where name = 'remote_os_roles';\").column('value')\n\n describe 'The oracle database REMOTE_OS_ROLES parameter' do\n subject { parameter }\n it { should cmp 'FALSE' }\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61729.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61427.rb", "line": 1 }, - "id": "V-61729" + "id": "V-61427" }, { - "title": "OS accounts utilized to run external procedures called by the DBMS\n must have limited privileges.", - "desc": "This requirement is intended to limit exposure due to operating from\n within a privileged account or role. The inclusion of role is intended to\n address those situations where an access control policy, such as Role Based\n Access Control (RBAC) is being implemented and where a change of role provides\n the same degree of assurance in the change of access authorizations for both\n the user and all processes acting on behalf of the user as would be provided by\n a change between a privileged and non-privileged account.\n\n To limit exposure when operating from within a privileged account or role,\n the application must support organizational requirements that users of\n information system accounts, or roles, with access to organization-defined\n lists of security functions or security-relevant information, use\n non-privileged accounts, or roles, when accessing other (non-security) system\n functions.\n\n Use of privileged accounts for non-administrative purposes puts data at\n risk of unintended or unauthorized loss, modification, or exposure. In\n particular, DBA accounts if used for non-administration application development\n or application maintenance can lead to miss-assignment of privileges where\n privileges are inherited by object owners. It may also lead to loss or\n compromise of application data where the elevated privileges bypass controls\n designed in and provided by applications.\n\n External applications called or spawned by the DBMS process may be executed\n under OS accounts with unnecessary privileges. This can lead to unauthorized\n access to OS resources and compromise of the OS, the DBMS or any other services\n provided by the host platform.", + "title": "The DBMS must include organization-defined additional, more detailed\n information in the audit records for audit events identified by type, location,\n or subject.", + "desc": "Information system auditing capability is critical for accurate\n forensic analysis. Audit record content that may be necessary to satisfy the\n requirement of this control includes: timestamps, source and destination\n addresses, user/process identifiers, event descriptions, success/fail\n indications, file names involved, and access control or flow control rules\n invoked.\n\n In addition, the application must have the capability to include\n organization-defined additional, more detailed information in the audit records\n for audit events. These events may be identified by type, location, or subject.\n\n An example of detailed information the organization may require in audit\n records is full-text recording of privileged commands or the individual\n identities of shared account users.\n\n Some organizations may determine that more detailed information is required\n for specific database event types. If this information is not available, it\n could negatively impact forensic investigations into user actions or other\n malicious events.", "descriptions": { - "default": "This requirement is intended to limit exposure due to operating from\n within a privileged account or role. The inclusion of role is intended to\n address those situations where an access control policy, such as Role Based\n Access Control (RBAC) is being implemented and where a change of role provides\n the same degree of assurance in the change of access authorizations for both\n the user and all processes acting on behalf of the user as would be provided by\n a change between a privileged and non-privileged account.\n\n To limit exposure when operating from within a privileged account or role,\n the application must support organizational requirements that users of\n information system accounts, or roles, with access to organization-defined\n lists of security functions or security-relevant information, use\n non-privileged accounts, or roles, when accessing other (non-security) system\n functions.\n\n Use of privileged accounts for non-administrative purposes puts data at\n risk of unintended or unauthorized loss, modification, or exposure. In\n particular, DBA accounts if used for non-administration application development\n or application maintenance can lead to miss-assignment of privileges where\n privileges are inherited by object owners. It may also lead to loss or\n compromise of application data where the elevated privileges bypass controls\n designed in and provided by applications.\n\n External applications called or spawned by the DBMS process may be executed\n under OS accounts with unnecessary privileges. This can lead to unauthorized\n access to OS resources and compromise of the OS, the DBMS or any other services\n provided by the host platform." + "default": "Information system auditing capability is critical for accurate\n forensic analysis. Audit record content that may be necessary to satisfy the\n requirement of this control includes: timestamps, source and destination\n addresses, user/process identifiers, event descriptions, success/fail\n indications, file names involved, and access control or flow control rules\n invoked.\n\n In addition, the application must have the capability to include\n organization-defined additional, more detailed information in the audit records\n for audit events. These events may be identified by type, location, or subject.\n\n An example of detailed information the organization may require in audit\n records is full-text recording of privileged commands or the individual\n identities of shared account users.\n\n Some organizations may determine that more detailed information is required\n for specific database event types. If this information is not available, it\n could negatively impact forensic investigations into user actions or other\n malicious events." }, - "impact": 0, - "refs": [ - { - "ref": [] - } - ], + "impact": 0.5, + "refs": [], "tags": { - "gtitle": "SRG-APP-000063-DB-000020", - "gid": "V-61601", - "rid": "SV-76091r2_rule", - "stig_id": "O121-C2-004400", - "fix_id": "F-67517r2_fix", + "gtitle": "SRG-APP-000101-DB-000044", + "gid": "V-61641", + "rid": "SV-76131r1_rule", + "stig_id": "O121-C2-008000", + "fix_id": "F-67553r2_fix", "cci": [ - "CCI-000366" + "CCI-000135" ], "nist": [ - "CM-6 b", + "AU-3 (1)", "Rev_4" ], "false_negatives": null, @@ -895,35 +941,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Determine which OS accounts are used by the DBMS to run\n external procedures.\n\n Validate that these OS accounts have only the privileges necessary to perform\n the required functionality.\n\n If any OS accounts, utilized by the database for running external procedures,\n have privileges beyond those required for running the external procedures, this\n is a finding.\n\n If use of the external procedure agent is authorized, ensure extproc is\n restricted to execution of authorized applications.\n\n External jobs are run using the account nobody by default.\n\n Review the contents of the file ORACLE_HOME/rdbms/admin/externaljob.ora for the\n lines run_user= and run_group=.\n\n If the user assigned to these parameters is not \"nobody\", this is a finding.\n\n System views providing privilege information are:\n DBA_SYS_PRIVS\n DBA_TAB_PRIVS\n DBA_ROLE_PRIVS", - "fix": "Limit privileges to DBMS-related OS accounts to those required to\n perform their DBMS specific functionality." + "check": "Verify, using vendor and system documentation if necessary,\n that the DBMS is configured to use Oracle's auditing features, or that a\n third-party product or custom code is deployed and configured to satisfy this\n requirement.\n\n If a third-party product or custom code is used, compare its current\n configuration with the audit requirements. If any of the requirements is not\n covered by the configuration, this is a finding.\n\n The remainder of this Check is applicable specifically where Oracle auditing is\n in use.\n\n If Standard Auditing is used:\n To see if Oracle is configured to capture audit data, enter the following\n SQL*Plus command:\n\n SHOW PARAMETER AUDIT_TRAIL\n\n or the following SQL query:\n\n SELECT * FROM SYS.V$PARAMETER WHERE NAME = 'audit_trail';\n\n If Oracle returns the value \"NONE\", this is a finding.\n\n Compare the organization-defined auditable events with the Oracle documentation\n to determine whether standard auditing covers all the requirements.\n\n If it does, this is not a finding.\n\n Compare those organization-defined auditable events that are not covered by the\n standard auditing, with the existing Fine-Grained Auditing (FGA) specifications\n returned by the following query:\n\n SELECT * FROM SYS.DBA_FGA_AUDIT_TRAIL;\n\n If any such auditable event is not covered by the existing FGA specifications,\n this is a finding.\n\n If Unified Auditing is used:\n To see if Oracle is configured to capture audit data, enter the following\n SQL*Plus command:\n\n SELECT * FROM V$OPTION WHERE PARAMETER = 'Unified Auditing';\n\n If Oracle returns the value \"TRUE\", this is not a finding.\n\n Compare the organization-defined auditable events with the Oracle documentation\n to determine whether standard auditing covers all the requirements.\n\n If it does, this is not a finding.\n\n Compare those organization-defined auditable events that are not covered by the\n standard auditing, with the existing Fine-Grained Auditing (FGA) specifications\n returned by the following query:\n\n SELECT * FROM SYS.UNIFIED_AUDIT_TRAIL WHERE AUDIT_TYPE = 'FineGrainedAudit';\n\n If any such auditable event is not covered by the existing FGA specifications,\n this is a finding.", + "fix": "Either configure the DBMS's auditing to audit\n organization-defined auditable events, or, if preferred, use a third-party or\n custom tool. The tool must provide the minimum capability to audit the required\n events.\n\n If using a third-party product, proceed in accordance with the product\n documentation. If using Oracle's capabilities, proceed as follows.\n\n If Standard Auditing is used:\n Use this process to ensure auditable events are captured:\n\n ALTER SYSTEM SET AUDIT_TRAIL= SCOPE=SPFILE;\n\n Audit trail type can be \"OS\", \"DB\", \"DB,EXTENDED\", \"XML\" or\n \"XML,EXTENDED\".\n\n After executing this statement, it may be necessary to shut down and restart\n the Oracle database.\n\n If the organization-defined additional audit requirements are not covered by\n the default audit options, deploy and configure Fine-Grained Auditing. For\n details, refer to Oracle documentation at the location below.\n\n If the site-specific audit requirements are not covered by the default audit\n options, deploy and configure Fine-Grained Auditing. For details, refer to\n Oracle documentation, at the location below.\n\n If Unified Auditing is used:\n Use this process to ensure auditable events are captured:\n\n SELECT * FROM V$OPTION WHERE PARAMETER = 'Unified Auditing';\n\n If Oracle returns the value \"TRUE\", this is not a finding.\n\n Otherwise,\n Link the oracle binary with uniaud_on, and then restart the database. Oracle\n Database Upgrade Guide describes how to enable unified auditing.\n\n If the organization-defined additional audit requirements are not covered by\n the default audit options, deploy and configure Fine-Grained Auditing. For\n details, refer to Oracle documentation at the location below.\n\n If the site-specific audit requirements are not covered by the default audit\n options, deploy and configure Fine-Grained Auditing. For details, refer to\n Oracle documentation, at the location below.\n\n For more information on the configuration of auditing, refer to the following\n documents:\n \"Auditing Database Activity\" in the Oracle Database 2 Day + Security Guide:\n http://docs.oracle.com/database/121/TDPSG/tdpsg_auditing.htm#TDPSG50000\n \"Monitoring Database Activity with Auditing\" in the Oracle Database Security\n Guide:\n http://docs.oracle.com/database/121/DBSEG/part_6.htm#CCHEHCGI\n \"DBMS_AUDIT_MGMT\" in the Oracle Database PL/SQL Packages and Types Reference:\n http://docs.oracle.com/database/121/ARPLS/d_audit_mgmt.htm#ARPLS241\n Oracle Database Upgrade Guide:\n http://docs.oracle.com/database/121/UPGRD/afterup.htm#UPGRD52810" }, - "code": " control 'V-61601' do\n impact 0.0\n describe 'This control is not applicable on oracle within aws rds, as aws manages the operating system in which the oracle database is running on' do\n skip 'This control is not applicable on oracle within aws rds, as aws manages the operating system in which the oracle database is running on'\n end\n end\n", + "code": "control 'V-61641' do\n title \"The DBMS must include organization-defined additional, more detailed\n information in the audit records for audit events identified by type, location,\n or subject.\"\n desc \"Information system auditing capability is critical for accurate\n forensic analysis. Audit record content that may be necessary to satisfy the\n requirement of this control includes: timestamps, source and destination\n addresses, user/process identifiers, event descriptions, success/fail\n indications, file names involved, and access control or flow control rules\n invoked.\n\n In addition, the application must have the capability to include\n organization-defined additional, more detailed information in the audit records\n for audit events. These events may be identified by type, location, or subject.\n\n An example of detailed information the organization may require in audit\n records is full-text recording of privileged commands or the individual\n identities of shared account users.\n\n Some organizations may determine that more detailed information is required\n for specific database event types. If this information is not available, it\n could negatively impact forensic investigations into user actions or other\n malicious events.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000101-DB-000044'\n tag \"gid\": 'V-61641'\n tag \"rid\": 'SV-76131r1_rule'\n tag \"stig_id\": 'O121-C2-008000'\n tag \"fix_id\": 'F-67553r2_fix'\n tag \"cci\": ['CCI-000135']\n tag \"nist\": ['AU-3 (1)', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Verify, using vendor and system documentation if necessary,\n that the DBMS is configured to use Oracle's auditing features, or that a\n third-party product or custom code is deployed and configured to satisfy this\n requirement.\n\n If a third-party product or custom code is used, compare its current\n configuration with the audit requirements. If any of the requirements is not\n covered by the configuration, this is a finding.\n\n The remainder of this Check is applicable specifically where Oracle auditing is\n in use.\n\n If Standard Auditing is used:\n To see if Oracle is configured to capture audit data, enter the following\n SQL*Plus command:\n\n SHOW PARAMETER AUDIT_TRAIL\n\n or the following SQL query:\n\n SELECT * FROM SYS.V$PARAMETER WHERE NAME = 'audit_trail';\n\n If Oracle returns the value \\\"NONE\\\", this is a finding.\n\n Compare the organization-defined auditable events with the Oracle documentation\n to determine whether standard auditing covers all the requirements.\n\n If it does, this is not a finding.\n\n Compare those organization-defined auditable events that are not covered by the\n standard auditing, with the existing Fine-Grained Auditing (FGA) specifications\n returned by the following query:\n\n SELECT * FROM SYS.DBA_FGA_AUDIT_TRAIL;\n\n If any such auditable event is not covered by the existing FGA specifications,\n this is a finding.\n\n If Unified Auditing is used:\n To see if Oracle is configured to capture audit data, enter the following\n SQL*Plus command:\n\n SELECT * FROM V$OPTION WHERE PARAMETER = 'Unified Auditing';\n\n If Oracle returns the value \\\"TRUE\\\", this is not a finding.\n\n Compare the organization-defined auditable events with the Oracle documentation\n to determine whether standard auditing covers all the requirements.\n\n If it does, this is not a finding.\n\n Compare those organization-defined auditable events that are not covered by the\n standard auditing, with the existing Fine-Grained Auditing (FGA) specifications\n returned by the following query:\n\n SELECT * FROM SYS.UNIFIED_AUDIT_TRAIL WHERE AUDIT_TYPE = 'FineGrainedAudit';\n\n If any such auditable event is not covered by the existing FGA specifications,\n this is a finding.\"\n tag \"fix\": \"Either configure the DBMS's auditing to audit\n organization-defined auditable events, or, if preferred, use a third-party or\n custom tool. The tool must provide the minimum capability to audit the required\n events.\n\n If using a third-party product, proceed in accordance with the product\n documentation. If using Oracle's capabilities, proceed as follows.\n\n If Standard Auditing is used:\n Use this process to ensure auditable events are captured:\n\n ALTER SYSTEM SET AUDIT_TRAIL= SCOPE=SPFILE;\n\n Audit trail type can be \\\"OS\\\", \\\"DB\\\", \\\"DB,EXTENDED\\\", \\\"XML\\\" or\n \\\"XML,EXTENDED\\\".\n\n After executing this statement, it may be necessary to shut down and restart\n the Oracle database.\n\n If the organization-defined additional audit requirements are not covered by\n the default audit options, deploy and configure Fine-Grained Auditing. For\n details, refer to Oracle documentation at the location below.\n\n If the site-specific audit requirements are not covered by the default audit\n options, deploy and configure Fine-Grained Auditing. For details, refer to\n Oracle documentation, at the location below.\n\n If Unified Auditing is used:\n Use this process to ensure auditable events are captured:\n\n SELECT * FROM V$OPTION WHERE PARAMETER = 'Unified Auditing';\n\n If Oracle returns the value \\\"TRUE\\\", this is not a finding.\n\n Otherwise,\n Link the oracle binary with uniaud_on, and then restart the database. Oracle\n Database Upgrade Guide describes how to enable unified auditing.\n\n If the organization-defined additional audit requirements are not covered by\n the default audit options, deploy and configure Fine-Grained Auditing. For\n details, refer to Oracle documentation at the location below.\n\n If the site-specific audit requirements are not covered by the default audit\n options, deploy and configure Fine-Grained Auditing. For details, refer to\n Oracle documentation, at the location below.\n\n For more information on the configuration of auditing, refer to the following\n documents:\n \\\"Auditing Database Activity\\\" in the Oracle Database 2 Day + Security Guide:\n http://docs.oracle.com/database/121/TDPSG/tdpsg_auditing.htm#TDPSG50000\n \\\"Monitoring Database Activity with Auditing\\\" in the Oracle Database Security\n Guide:\n http://docs.oracle.com/database/121/DBSEG/part_6.htm#CCHEHCGI\n \\\"DBMS_AUDIT_MGMT\\\" in the Oracle Database PL/SQL Packages and Types Reference:\n http://docs.oracle.com/database/121/ARPLS/d_audit_mgmt.htm#ARPLS241\n Oracle Database Upgrade Guide:\n http://docs.oracle.com/database/121/UPGRD/afterup.htm#UPGRD52810\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n standard_auditing_used = input('standard_auditing_used')\n unified_auditing_used = input('unified_auditing_used')\n\n describe.one do\n describe 'Standard auditing is in use for audit purposes' do\n subject { standard_auditing_used }\n it { should be true }\n end\n\n describe 'Unified auditing is in use for audit purposes' do\n subject { unified_auditing_used }\n it { should be true }\n end\n end\n\n audit_trail = sql.query(\"select value from v$parameter where name = 'audit_trail';\").column('value')\n audit_info_captured = sql.query('SELECT EVENT_TIMESTAMP FROM UNIFIED_AUDIT_TRAIL ORDER BY EVENT_TIMESTAMP DESC FETCH FIRST 10 ROWS ONLY;').column('event_timestamp')\n fga_audit_events = sql.query(\" SELECT * FROM SYS.UNIFIED_AUDIT_TRAIL WHERE AUDIT_TYPE = 'FineGrainedAudit';\").column('TIMESTAMP')\n\n if standard_auditing_used\n describe 'The oracle database audit_trail parameter' do\n subject { audit_trail }\n it { should_not cmp 'NONE' }\n end\n end\n\n unified_auditing = sql.query(\"SELECT value FROM V$OPTION WHERE PARAMETER = 'Unified Auditing';\").column('value')\n\n if unified_auditing_used\n describe 'The oracle database unified auditing parameter' do\n subject { unified_auditing }\n it { should_not cmp 'FALSE' }\n end\n\n describe 'The oracle database unified auditing events captured' do\n subject { audit_info_captured }\n it { should_not be_empty }\n end\n\n describe 'The oracle database fine grained auditing events captured' do\n subject { fga_audit_events }\n it { should_not be_empty }\n end\n\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61601.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61641.rb", "line": 1 }, - "id": "V-61601" + "id": "V-61641" }, { - "title": "The DBMS must have allocated audit record storage capacity.", - "desc": "Applications need to be cognizant of potential audit log storage\n capacity issues. During the installation and/or configuration process,\n applications should detect and determine if adequate storage capacity has been\n allocated for audit logs.\n\n During the installation process, a notification may be provided to the\n installer indicating, based on the auditing configuration chosen and the amount\n of storage space allocated for audit logs, the amount of storage capacity\n available is not sufficient to meet storage requirements.\n\n When insufficient space in directories is allocated for audit records,\n database audit logs can fill up and begin to overwrite earlier logs, database\n activity can stop altogether, or auditing could fail and crucial tracking data\n could be lost.", + "title": "The DBMS must check the validity of data inputs.", + "desc": "Invalid user input occurs when a user inserts data or characters into\n an application's data entry fields and the application is unprepared to process\n that data. This results in unanticipated application behavior, potentially\n leading to an application or information system compromise. Invalid user input\n is one of the primary methods employed when attempting to compromise an\n application.\n\n All applications need to validate the data users attempt to input to the\n application for processing. Rules for checking the valid syntax and semantics\n of information system inputs (e.g., character set, length, numerical range,\n acceptable values) are in place to verify inputs match specified definitions\n for format and content. Inputs passed to interpreters are prescreened to\n prevent the content from being unintentionally interpreted as commands.\n\n\n This calls for inspection of application source code, which will require\n collaboration with the application developers. It is recognized that in many\n cases, the database administrator (DBA) is organizationally separate from the\n application developers and may have limited, if any, access to source code.\n Nevertheless, protections of this type are so important to the secure operation\n of databases that they must not be ignored. At a minimum, the DBA must attempt\n to obtain assurances from the development organization that this issue has been\n addressed and must document what has been discovered.", "descriptions": { - "default": "Applications need to be cognizant of potential audit log storage\n capacity issues. During the installation and/or configuration process,\n applications should detect and determine if adequate storage capacity has been\n allocated for audit logs.\n\n During the installation process, a notification may be provided to the\n installer indicating, based on the auditing configuration chosen and the amount\n of storage space allocated for audit logs, the amount of storage capacity\n available is not sufficient to meet storage requirements.\n\n When insufficient space in directories is allocated for audit records,\n database audit logs can fill up and begin to overwrite earlier logs, database\n activity can stop altogether, or auditing could fail and crucial tracking data\n could be lost." + "default": "Invalid user input occurs when a user inserts data or characters into\n an application's data entry fields and the application is unprepared to process\n that data. This results in unanticipated application behavior, potentially\n leading to an application or information system compromise. Invalid user input\n is one of the primary methods employed when attempting to compromise an\n application.\n\n All applications need to validate the data users attempt to input to the\n application for processing. Rules for checking the valid syntax and semantics\n of information system inputs (e.g., character set, length, numerical range,\n acceptable values) are in place to verify inputs match specified definitions\n for format and content. Inputs passed to interpreters are prescreened to\n prevent the content from being unintentionally interpreted as commands.\n\n\n This calls for inspection of application source code, which will require\n collaboration with the application developers. It is recognized that in many\n cases, the database administrator (DBA) is organizationally separate from the\n application developers and may have limited, if any, access to source code.\n Nevertheless, protections of this type are so important to the secure operation\n of databases that they must not be ignored. At a minimum, the DBA must attempt\n to obtain assurances from the development organization that this issue has been\n addressed and must document what has been discovered." }, "impact": 0.5, "refs": [], "tags": { - "gtitle": "SRG-APP-000072-DB-000046", - "gid": "V-61615", - "rid": "SV-76105r1_rule", - "stig_id": "O121-C2-005700", - "fix_id": "F-67531r1_fix", + "gtitle": "SRG-APP-000251-DB-000160", + "gid": "V-61785", + "rid": "SV-76275r2_rule", + "stig_id": "O121-C2-019500", + "fix_id": "F-67701r1_fix", "cci": [ - "CCI-001849" + "CCI-001310" ], "nist": [ - "AU-4", + "SI-10", "Rev_4" ], "false_negatives": null, @@ -936,35 +982,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Review the DBMS settings to determine whether audit logging is\n configured to produce logs consistent with the amount of space allocated for\n logging. If auditing will generate excessive logs so that they may outgrow the\n space reserved for logging, this is a finding.\n\n If file-based auditing is in use, check that sufficient space is available to\n support the file(s). If not, this is a finding\n\n If standard, table-based auditing is used: The audit logs are written to a\n table called AUD$, and if a Virtual Private Database is deployed, we also\n create a table called FGA_LOG$. First check the current location of the audit\n trail tables.\n\n CONN / AS SYSDBA\n\n SELECT table_name, tablespace_name\n FROM dba_tables\n WHERE table_name IN ('AUD$', 'FGA_LOG$')\n ORDER BY table_name;\n\n TABLE_NAME TABLESPACE_NAME\n ------------------------------ ------------------------------\n AUD$ SYSTEM\n FGA_LOG$ SYSTEM\n\n If the tablespace name is SYSTEM, the table needs to be relocated to its own\n tablespace. Ensure that adequate space is allocated to that tablespace.\n\n If Unified Auditing is used:\n Audit logs are written to tables in the AUDSYS schema. The default tablespace\n for AUDSYS is USERS. A separate tablespace should be created to contain audit\n data. Ensure that adequate space is allocated to that tablespace.", - "fix": "Allocate sufficient disk space for file-based audit.\n\n Ensure that audit tables are in their own tablespaces and that the tablespaces\n have enough room for the volume of log data that will be produced." + "check": "Review DBMS code, settings, field definitions, constraints, and\n triggers to determine whether or not data being input into the database is\n validated.\n\n If code exists that allows invalid data to be acted upon or input into the\n database, this is a finding.\n\n If field definitions do not exist in the database, this is a finding.\n\n If fields do not contain enabled constraints where required, this is a finding.\n\n - - - - -\n Oracle provides built-in processes to keep data and its integrity intact by\n using constraints.\n\n Integrity Constraint States\n Can specify that a constraint is enabled (ENABLE) or disabled (DISABLE). If a\n constraint is enabled, data is checked as it is entered or updated in the\n database, and data that does not conform to the constraint is prevented from\n being entered. If a constraint is disabled, then data that does not conform can\n be allowed to enter the database.\n\n Additionally, can specify that existing data in the table must conform to the\n constraint (VALIDATE). Conversely, if specified NOVALIDATE, are not ensured\n that existing data conforms.\n\n An integrity constraint defined on a table can be in one of the following\n states:\n ENABLE, VALIDATE\n ENABLE, NOVALIDATE\n DISABLE, VALIDATE\n DISABLE, NOVALIDATE\n\n For details about the meaning of these states and an understanding of their\n consequences, see the Oracle Database SQL Language Reference. Some of these\n consequences are discussed here.\n\n Disabling Constraints\n To enforce the rules defined by integrity constraints, the constraints should\n always be enabled. However, consider temporarily disabling the integrity\n constraints of a table for the following performance reasons:\n\n - When loading large amounts of data into a table\n\n - When performing batch operations that make massive changes to a table (for\n example, changing every employee's number by adding 1000 to the existing number)\n\n - When importing or exporting one table at a time\n\n In all three cases, temporarily disabling integrity constraints can improve the\n performance of the operation, especially in data warehouse configurations.\n\n It is possible to enter data that violates a constraint while that constraint\n is disabled. Thus, always enable the constraint after completing any of the\n operations listed in the preceding bullet list.\n\n Enabling Constraints\n While a constraint is enabled, no row violating the constraint can be inserted\n into the table. However, while the constraint is disabled, such a row can be\n inserted. This row is known as an exception to the constraint. If the\n constraint is in the ENABLE, NOVALIDATE state, violations resulting from data\n entered while the constraint was disabled remain. The rows that violate the\n constraint must be either updated or deleted in order for the constraint to be\n put in the validated state.\n\n Can identify exceptions to a specific integrity constraint while attempting to\n enable the constraint. See \"Reporting Constraint Exceptions\". All rows\n violating constraints are noted in an EXCEPTIONS table, which can be examined.\n\n ENABLE, NOVALIDATE Constraint State\n When a constraint is in the ENABLE, NOVALIDATE state, all subsequent statements\n are checked for conformity to the constraint. However, any existing data in the\n table is not checked. A table with ENABLE, NOVALIDATE constraints can contain\n invalid data, but it is not possible to add new invalid data to it. Constraints\n in the ENABLE, NOVALIDATE state is most useful in data warehouse configurations\n that are uploading valid OLTP data.\n\n Enabling a constraint does not require validation. Enabling a constraint\n novalidate is much faster than enabling and validating a constraint. Also,\n validating a constraint that is already enabled does not require any DML locks\n during validation (unlike validating a previously disabled constraint).\n Enforcement guarantees that no violations are introduced during the validation.\n Hence, enabling without validating reduces the downtime typically associated\n with enabling a constraint.\n\n Efficient Use of Integrity Constraints: A Procedure\n\n Using integrity constraint states in the following order can ensure the best\n benefits:\n Disable state.\n Perform the operation (load, export, import).\n ENABLE, NOVALIDATE state.\n Enable state.\n\n Some benefits of using constraints in this order are:\n No locks are held.\n All constraints can go to enable state concurrently.\n Constraint enabling is done in parallel.\n Concurrent activity on table is permitted.\n\n Setting Integrity Constraints Upon Definition\n When an integrity constraint is defined in a CREATE TABLE or ALTER TABLE\n statement, it can be enabled, disabled, or validated or not validated as\n determined by the specification of the ENABLE/DISABLE clause. If the\n ENABLE/DISABLE clause is not specified in a constraint definition, the database\n automatically enables and validates the constraint.\n\n Disabling Constraints Upon Definition\n The following CREATE TABLE and ALTER TABLE statements both define and disable\n integrity constraints:\n\n CREATE TABLE emp (\n empno NUMBER(5) PRIMARY KEY DISABLE, . . . ;\n\n ALTER TABLE emp\n ADD PRIMARY KEY (empno) DISABLE;\n\n An ALTER TABLE statement that defines and disables an integrity constraint\n never fails because of rows in the table that violate the integrity constraint.\n The definition of the constraint is allowed because its rule is not enforced.\n\n Enabling Constraints Upon Definition\n\n The following CREATE TABLE and ALTER TABLE statements both define and enable\n integrity constraints:\n\n CREATE TABLE emp (\n empno NUMBER(5) CONSTRAINT emp.pk PRIMARY KEY, . . . ;\n\n ALTER TABLE emp\n ADD CONSTRAINT emp.pk PRIMARY KEY (empno);\n\n An ALTER TABLE statement that defines and attempts to enable an integrity\n constraint can fail because rows of the table violate the integrity constraint.\n If this case, the statement is rolled back, and the constraint definition is\n not stored and not enabled.\n\n When enabling a UNIQUE or PRIMARY KEY constraint, an associated index is\n created.", + "fix": "Modify database code to properly validate data before it is put\n into the database or acted upon by the database.\n\n Modify database to contain field definitions for each field in the database.\n\n Modify database to contain constraints on database columns and tables that\n require them for data validity.\n\n Review the application schemas implemented on the system. Check the DDL for\n the tables that are created for the applications to see if constraints have\n been enabled.\n\n - - - - -\n Enabling Constraints Upon Definition\n The following CREATE TABLE and ALTER TABLE statements both define and enable\n integrity constraints:\n CREATE TABLE emp (\n empno NUMBER(5) CONSTRAINT emp.pk PRIMARY KEY, . . . ) ;\n ALTER TABLE emp\n ADD CONSTRAINT emp.pk PRIMARY KEY (empno);\n\n An ALTER TABLE statement that defines and attempts to enable an integrity\n constraint can fail because existing rows of the table violate the integrity\n constraint. In this case, the statement is rolled back, and the constraint\n definition is not stored and not enabled.\n\n When enabling a UNIQUE or PRIMARY KEY constraint, an associated index is\n created." }, - "code": "control 'V-61615' do\n title 'The DBMS must have allocated audit record storage capacity.'\n desc \"Applications need to be cognizant of potential audit log storage\n capacity issues. During the installation and/or configuration process,\n applications should detect and determine if adequate storage capacity has been\n allocated for audit logs.\n\n During the installation process, a notification may be provided to the\n installer indicating, based on the auditing configuration chosen and the amount\n of storage space allocated for audit logs, the amount of storage capacity\n available is not sufficient to meet storage requirements.\n\n When insufficient space in directories is allocated for audit records,\n database audit logs can fill up and begin to overwrite earlier logs, database\n activity can stop altogether, or auditing could fail and crucial tracking data\n could be lost.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000072-DB-000046'\n tag \"gid\": 'V-61615'\n tag \"rid\": 'SV-76105r1_rule'\n tag \"stig_id\": 'O121-C2-005700'\n tag \"fix_id\": 'F-67531r1_fix'\n tag \"cci\": ['CCI-001849']\n tag \"nist\": ['AU-4', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Review the DBMS settings to determine whether audit logging is\n configured to produce logs consistent with the amount of space allocated for\n logging. If auditing will generate excessive logs so that they may outgrow the\n space reserved for logging, this is a finding.\n\n If file-based auditing is in use, check that sufficient space is available to\n support the file(s). If not, this is a finding\n\n If standard, table-based auditing is used: The audit logs are written to a\n table called AUD$, and if a Virtual Private Database is deployed, we also\n create a table called FGA_LOG$. First check the current location of the audit\n trail tables.\n\n CONN / AS SYSDBA\n\n SELECT table_name, tablespace_name\n FROM dba_tables\n WHERE table_name IN ('AUD$', 'FGA_LOG$')\n ORDER BY table_name;\n\n TABLE_NAME TABLESPACE_NAME\n ------------------------------ ------------------------------\n AUD$ SYSTEM\n FGA_LOG$ SYSTEM\n\n If the tablespace name is SYSTEM, the table needs to be relocated to its own\n tablespace. Ensure that adequate space is allocated to that tablespace.\n\n If Unified Auditing is used:\n Audit logs are written to tables in the AUDSYS schema. The default tablespace\n for AUDSYS is USERS. A separate tablespace should be created to contain audit\n data. Ensure that adequate space is allocated to that tablespace.\"\n tag \"fix\": \"Allocate sufficient disk space for file-based audit.\n\n Ensure that audit tables are in their own tablespaces and that the tablespaces\n have enough room for the volume of log data that will be produced.\"\n describe 'A manual review is required to ensure the DBMS has allocated audit record storage capacity' do\n skip 'A manual review is required to ensure the DBMS has allocated audit record storage capacity'\n end\nend\n", + "code": "control 'V-61785' do\n title 'The DBMS must check the validity of data inputs.'\n desc \"Invalid user input occurs when a user inserts data or characters into\n an application's data entry fields and the application is unprepared to process\n that data. This results in unanticipated application behavior, potentially\n leading to an application or information system compromise. Invalid user input\n is one of the primary methods employed when attempting to compromise an\n application.\n\n All applications need to validate the data users attempt to input to the\n application for processing. Rules for checking the valid syntax and semantics\n of information system inputs (e.g., character set, length, numerical range,\n acceptable values) are in place to verify inputs match specified definitions\n for format and content. Inputs passed to interpreters are prescreened to\n prevent the content from being unintentionally interpreted as commands.\n\n\n This calls for inspection of application source code, which will require\n collaboration with the application developers. It is recognized that in many\n cases, the database administrator (DBA) is organizationally separate from the\n application developers and may have limited, if any, access to source code.\n Nevertheless, protections of this type are so important to the secure operation\n of databases that they must not be ignored. At a minimum, the DBA must attempt\n to obtain assurances from the development organization that this issue has been\n addressed and must document what has been discovered.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000251-DB-000160'\n tag \"gid\": 'V-61785'\n tag \"rid\": 'SV-76275r2_rule'\n tag \"stig_id\": 'O121-C2-019500'\n tag \"fix_id\": 'F-67701r1_fix'\n tag \"cci\": ['CCI-001310']\n tag \"nist\": ['SI-10', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Review DBMS code, settings, field definitions, constraints, and\n triggers to determine whether or not data being input into the database is\n validated.\n\n If code exists that allows invalid data to be acted upon or input into the\n database, this is a finding.\n\n If field definitions do not exist in the database, this is a finding.\n\n If fields do not contain enabled constraints where required, this is a finding.\n\n - - - - -\n Oracle provides built-in processes to keep data and its integrity intact by\n using constraints.\n\n Integrity Constraint States\n Can specify that a constraint is enabled (ENABLE) or disabled (DISABLE). If a\n constraint is enabled, data is checked as it is entered or updated in the\n database, and data that does not conform to the constraint is prevented from\n being entered. If a constraint is disabled, then data that does not conform can\n be allowed to enter the database.\n\n Additionally, can specify that existing data in the table must conform to the\n constraint (VALIDATE). Conversely, if specified NOVALIDATE, are not ensured\n that existing data conforms.\n\n An integrity constraint defined on a table can be in one of the following\n states:\n ENABLE, VALIDATE\n ENABLE, NOVALIDATE\n DISABLE, VALIDATE\n DISABLE, NOVALIDATE\n\n For details about the meaning of these states and an understanding of their\n consequences, see the Oracle Database SQL Language Reference. Some of these\n consequences are discussed here.\n\n Disabling Constraints\n To enforce the rules defined by integrity constraints, the constraints should\n always be enabled. However, consider temporarily disabling the integrity\n constraints of a table for the following performance reasons:\n\n - When loading large amounts of data into a table\n\n - When performing batch operations that make massive changes to a table (for\n example, changing every employee's number by adding 1000 to the existing number)\n\n - When importing or exporting one table at a time\n\n In all three cases, temporarily disabling integrity constraints can improve the\n performance of the operation, especially in data warehouse configurations.\n\n It is possible to enter data that violates a constraint while that constraint\n is disabled. Thus, always enable the constraint after completing any of the\n operations listed in the preceding bullet list.\n\n Enabling Constraints\n While a constraint is enabled, no row violating the constraint can be inserted\n into the table. However, while the constraint is disabled, such a row can be\n inserted. This row is known as an exception to the constraint. If the\n constraint is in the ENABLE, NOVALIDATE state, violations resulting from data\n entered while the constraint was disabled remain. The rows that violate the\n constraint must be either updated or deleted in order for the constraint to be\n put in the validated state.\n\n Can identify exceptions to a specific integrity constraint while attempting to\n enable the constraint. See \\\"Reporting Constraint Exceptions\\\". All rows\n violating constraints are noted in an EXCEPTIONS table, which can be examined.\n\n ENABLE, NOVALIDATE Constraint State\n When a constraint is in the ENABLE, NOVALIDATE state, all subsequent statements\n are checked for conformity to the constraint. However, any existing data in the\n table is not checked. A table with ENABLE, NOVALIDATE constraints can contain\n invalid data, but it is not possible to add new invalid data to it. Constraints\n in the ENABLE, NOVALIDATE state is most useful in data warehouse configurations\n that are uploading valid OLTP data.\n\n Enabling a constraint does not require validation. Enabling a constraint\n novalidate is much faster than enabling and validating a constraint. Also,\n validating a constraint that is already enabled does not require any DML locks\n during validation (unlike validating a previously disabled constraint).\n Enforcement guarantees that no violations are introduced during the validation.\n Hence, enabling without validating reduces the downtime typically associated\n with enabling a constraint.\n\n Efficient Use of Integrity Constraints: A Procedure\n\n Using integrity constraint states in the following order can ensure the best\n benefits:\n Disable state.\n Perform the operation (load, export, import).\n ENABLE, NOVALIDATE state.\n Enable state.\n\n Some benefits of using constraints in this order are:\n No locks are held.\n All constraints can go to enable state concurrently.\n Constraint enabling is done in parallel.\n Concurrent activity on table is permitted.\n\n Setting Integrity Constraints Upon Definition\n When an integrity constraint is defined in a CREATE TABLE or ALTER TABLE\n statement, it can be enabled, disabled, or validated or not validated as\n determined by the specification of the ENABLE/DISABLE clause. If the\n ENABLE/DISABLE clause is not specified in a constraint definition, the database\n automatically enables and validates the constraint.\n\n Disabling Constraints Upon Definition\n The following CREATE TABLE and ALTER TABLE statements both define and disable\n integrity constraints:\n\n CREATE TABLE emp (\n empno NUMBER(5) PRIMARY KEY DISABLE, . . . ;\n\n ALTER TABLE emp\n ADD PRIMARY KEY (empno) DISABLE;\n\n An ALTER TABLE statement that defines and disables an integrity constraint\n never fails because of rows in the table that violate the integrity constraint.\n The definition of the constraint is allowed because its rule is not enforced.\n\n Enabling Constraints Upon Definition\n\n The following CREATE TABLE and ALTER TABLE statements both define and enable\n integrity constraints:\n\n CREATE TABLE emp (\n empno NUMBER(5) CONSTRAINT emp.pk PRIMARY KEY, . . . ;\n\n ALTER TABLE emp\n ADD CONSTRAINT emp.pk PRIMARY KEY (empno);\n\n An ALTER TABLE statement that defines and attempts to enable an integrity\n constraint can fail because rows of the table violate the integrity constraint.\n If this case, the statement is rolled back, and the constraint definition is\n not stored and not enabled.\n\n When enabling a UNIQUE or PRIMARY KEY constraint, an associated index is\n created.\"\n tag \"fix\": \"Modify database code to properly validate data before it is put\n into the database or acted upon by the database.\n\n Modify database to contain field definitions for each field in the database.\n\n Modify database to contain constraints on database columns and tables that\n require them for data validity.\n\n Review the application schemas implemented on the system. Check the DDL for\n the tables that are created for the applications to see if constraints have\n been enabled.\n\n - - - - -\n Enabling Constraints Upon Definition\n The following CREATE TABLE and ALTER TABLE statements both define and enable\n integrity constraints:\n CREATE TABLE emp (\n empno NUMBER(5) CONSTRAINT emp.pk PRIMARY KEY, . . . ) ;\n ALTER TABLE emp\n ADD CONSTRAINT emp.pk PRIMARY KEY (empno);\n\n An ALTER TABLE statement that defines and attempts to enable an integrity\n constraint can fail because existing rows of the table violate the integrity\n constraint. In this case, the statement is rolled back, and the constraint\n definition is not stored and not enabled.\n\n When enabling a UNIQUE or PRIMARY KEY constraint, an associated index is\n created.\"\n describe 'A manual review is required to ensure the DBMS checks the validity of data inputs' do\n skip 'A manual review is required to ensure the DBMS checks the validity of data inputs'\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61615.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61785.rb", "line": 1 }, - "id": "V-61615" + "id": "V-61785" }, { - "title": "The DBMS must enforce Discretionary Access Control (DAC) policy\n allowing users to specify and control sharing by named individuals, groups of\n individuals, or by both, limiting propagation of access rights and including or\n excluding access to the granularity of a single user.", - "desc": "Access control policies (e.g., identity-based policies, role-based\n policies, attribute-based policies) and access enforcement mechanisms (e.g.,\n access control lists, access control matrices, cryptography) are employed by\n organizations to control access between users (or processes acting on behalf of\n users) and objects (e.g., devices, files, records, processes, programs,\n domains).\n\n DAC is a type of access control methodology serving as a means of\n restricting access to objects and data based on the identity of subjects and/or\n groups to which they belong. It is discretionary in the sense that application\n users with the appropriate permissions to access an application resource or\n data have the discretion to pass that permission on to another user either\n directly or indirectly.\n\n Data protection requirements may result in a DAC policy being specified as\n part of the application design. Discretionary access controls would be employed\n at the application level to restrict and control access to application objects\n and data thereby providing increased information security for the organization.\n\n When DAC controls are employed, those controls must limit sharing to named\n application users, groups of users, or both. The application DAC controls must\n also limit the propagation of access rights and have the ability to exclude\n access to data down to the granularity of a single user.\n\n Databases using DAC must have the ability for the owner of an object or\n information to assign or revoke rights to view or modify the object or\n information. If the owner of an object or information does not have rights to\n exclude access to an object or information at a user level, users may gain\n access to objects and information they are not authorized to view/modify.", + "title": "The system must provide a report generation capability for audit\n reduction data.", + "desc": "In support of Audit Review, Analysis, and Reporting requirements,\n audit reduction is a technique used to reduce the volume of audit records in\n order to facilitate a manual review.\n\n Before a security review is conducted, information systems and/or\n applications with an audit reduction capability may remove many audit records\n known to have little security significance. This is generally accomplished by\n removing records generated by specified classes of events, such as records\n generated by nightly backups.\n\n In order to identify and report on what (repetitive) data has been removed\n via the use of audit reduction, the application must provide a capability to\n generate reports containing what values were removed by the audit reduction.\n\n Audit reduction does not alter original audit records. An audit reduction\n capability provides support for near real-time audit review and analysis based\n on policy-based requirements and after-the-fact investigations of security\n incidents.\n\n Reporting tools employing audit reduction methods must not alter the\n original audit data. An example of a tool employing audit reduction methods is\n the Windows Event Viewer tool which is used to view and analyze audit logs on\n Windows systems.\n\n The lack of reporting tools for audit reduction can require the DBA, or\n others responsible for reviewing audit logs, to sort through large amounts of\n data in order to find relevant records. This can cause important audit records\n to be missed.", "descriptions": { - "default": "Access control policies (e.g., identity-based policies, role-based\n policies, attribute-based policies) and access enforcement mechanisms (e.g.,\n access control lists, access control matrices, cryptography) are employed by\n organizations to control access between users (or processes acting on behalf of\n users) and objects (e.g., devices, files, records, processes, programs,\n domains).\n\n DAC is a type of access control methodology serving as a means of\n restricting access to objects and data based on the identity of subjects and/or\n groups to which they belong. It is discretionary in the sense that application\n users with the appropriate permissions to access an application resource or\n data have the discretion to pass that permission on to another user either\n directly or indirectly.\n\n Data protection requirements may result in a DAC policy being specified as\n part of the application design. Discretionary access controls would be employed\n at the application level to restrict and control access to application objects\n and data thereby providing increased information security for the organization.\n\n When DAC controls are employed, those controls must limit sharing to named\n application users, groups of users, or both. The application DAC controls must\n also limit the propagation of access rights and have the ability to exclude\n access to data down to the granularity of a single user.\n\n Databases using DAC must have the ability for the owner of an object or\n information to assign or revoke rights to view or modify the object or\n information. If the owner of an object or information does not have rights to\n exclude access to an object or information at a user level, users may gain\n access to objects and information they are not authorized to view/modify." + "default": "In support of Audit Review, Analysis, and Reporting requirements,\n audit reduction is a technique used to reduce the volume of audit records in\n order to facilitate a manual review.\n\n Before a security review is conducted, information systems and/or\n applications with an audit reduction capability may remove many audit records\n known to have little security significance. This is generally accomplished by\n removing records generated by specified classes of events, such as records\n generated by nightly backups.\n\n In order to identify and report on what (repetitive) data has been removed\n via the use of audit reduction, the application must provide a capability to\n generate reports containing what values were removed by the audit reduction.\n\n Audit reduction does not alter original audit records. An audit reduction\n capability provides support for near real-time audit review and analysis based\n on policy-based requirements and after-the-fact investigations of security\n incidents.\n\n Reporting tools employing audit reduction methods must not alter the\n original audit data. An example of a tool employing audit reduction methods is\n the Windows Event Viewer tool which is used to view and analyze audit logs on\n Windows systems.\n\n The lack of reporting tools for audit reduction can require the DBA, or\n others responsible for reviewing audit logs, to sort through large amounts of\n data in order to find relevant records. This can cause important audit records\n to be missed." }, - "impact": 0.5, + "impact": 0.3, "refs": [], "tags": { - "gtitle": "SRG-APP-000036-DB-000174", - "gid": "V-61577", - "rid": "SV-76067r1_rule", - "stig_id": "O121-C2-003000", - "fix_id": "F-67493r1_fix", + "gtitle": "SRG-APP-000114-DB-000054", + "gid": "V-61969", + "rid": "SV-76459r1_rule", + "stig_id": "O121-C3-008800", + "fix_id": "F-67889r1_fix", "cci": [ - "CCI-002165" + "CCI-001878" ], "nist": [ - "AC-3 (4)", + "AU-7 a", "Rev_4" ], "false_negatives": null, @@ -977,34 +1023,30 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Check DBMS settings to determine if users are able to assign\n and revoke rights to the objects and information that they own. If users cannot\n assign or revoke rights to the objects and information that they own to groups,\n roles, or individual users, this is a finding.", - "fix": "Modify DBMS settings to allow users to assign or revoke access\n rights to objects and information owned by the user. The ability to grant or\n revoke rights must include the ability to grant or revoke those rights down to\n the granularity of a single user.\n\n (Note: In most cases, no fix will be necessary. This is default functionality\n for Oracle.)" + "check": "Verify that audit reduction capabilities are in place for the\n Oracle audit data. Since Oracle has no reduction capability per se, a\n third-party tool or in-house-developed software must be in place to provide\n this functionality. This must include the ability to report on the excluded\n audit data.\n\n If this capability has not been implemented, this is a finding.", + "fix": "Deploy software capable of performing audit data reduction and of\n reporting on the excluded audit data." }, - "code": "control 'V-61577' do\n title \"The DBMS must enforce Discretionary Access Control (DAC) policy\n allowing users to specify and control sharing by named individuals, groups of\n individuals, or by both, limiting propagation of access rights and including or\n excluding access to the granularity of a single user.\"\n desc \"Access control policies (e.g., identity-based policies, role-based\n policies, attribute-based policies) and access enforcement mechanisms (e.g.,\n access control lists, access control matrices, cryptography) are employed by\n organizations to control access between users (or processes acting on behalf of\n users) and objects (e.g., devices, files, records, processes, programs,\n domains).\n\n DAC is a type of access control methodology serving as a means of\n restricting access to objects and data based on the identity of subjects and/or\n groups to which they belong. It is discretionary in the sense that application\n users with the appropriate permissions to access an application resource or\n data have the discretion to pass that permission on to another user either\n directly or indirectly.\n\n Data protection requirements may result in a DAC policy being specified as\n part of the application design. Discretionary access controls would be employed\n at the application level to restrict and control access to application objects\n and data thereby providing increased information security for the organization.\n\n When DAC controls are employed, those controls must limit sharing to named\n application users, groups of users, or both. The application DAC controls must\n also limit the propagation of access rights and have the ability to exclude\n access to data down to the granularity of a single user.\n\n Databases using DAC must have the ability for the owner of an object or\n information to assign or revoke rights to view or modify the object or\n information. If the owner of an object or information does not have rights to\n exclude access to an object or information at a user level, users may gain\n access to objects and information they are not authorized to view/modify.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000036-DB-000174'\n tag \"gid\": 'V-61577'\n tag \"rid\": 'SV-76067r1_rule'\n tag \"stig_id\": 'O121-C2-003000'\n tag \"fix_id\": 'F-67493r1_fix'\n tag \"cci\": ['CCI-002165']\n tag \"nist\": ['AC-3 (4)', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Check DBMS settings to determine if users are able to assign\n and revoke rights to the objects and information that they own. If users cannot\n assign or revoke rights to the objects and information that they own to groups,\n roles, or individual users, this is a finding.\"\n tag \"fix\": \"Modify DBMS settings to allow users to assign or revoke access\n rights to objects and information owned by the user. The ability to grant or\n revoke rights must include the ability to grant or revoke those rights down to\n the granularity of a single user.\n\n (Note: In most cases, no fix will be necessary. This is default functionality\n for Oracle.)\"\n describe 'A manual review is required to ensure the DBMS enforces Discretionary Access Control (DAC) policy\n allowing users to specify and control sharing by named individuals, groups of\n individuals, or by both, limiting propagation of access rights and including or\n excluding access to the granularity of a single user.' do\n skip 'A manual review is required to ensure the DBMS enforces Discretionary Access Control (DAC) policy\n allowing users to specify and control sharing by named individuals, groups of\n individuals, or by both, limiting propagation of access rights and including or\n excluding access to the granularity of a single user.'\n end\nend\n", + "code": "control 'V-61969' do\n title \"The system must provide a report generation capability for audit\n reduction data.\"\n desc \"In support of Audit Review, Analysis, and Reporting requirements,\n audit reduction is a technique used to reduce the volume of audit records in\n order to facilitate a manual review.\n\n Before a security review is conducted, information systems and/or\n applications with an audit reduction capability may remove many audit records\n known to have little security significance. This is generally accomplished by\n removing records generated by specified classes of events, such as records\n generated by nightly backups.\n\n In order to identify and report on what (repetitive) data has been removed\n via the use of audit reduction, the application must provide a capability to\n generate reports containing what values were removed by the audit reduction.\n\n Audit reduction does not alter original audit records. An audit reduction\n capability provides support for near real-time audit review and analysis based\n on policy-based requirements and after-the-fact investigations of security\n incidents.\n\n Reporting tools employing audit reduction methods must not alter the\n original audit data. An example of a tool employing audit reduction methods is\n the Windows Event Viewer tool which is used to view and analyze audit logs on\n Windows systems.\n\n The lack of reporting tools for audit reduction can require the DBA, or\n others responsible for reviewing audit logs, to sort through large amounts of\n data in order to find relevant records. This can cause important audit records\n to be missed.\n \"\n impact 0.3\n tag \"gtitle\": 'SRG-APP-000114-DB-000054'\n tag \"gid\": 'V-61969'\n tag \"rid\": 'SV-76459r1_rule'\n tag \"stig_id\": 'O121-C3-008800'\n tag \"fix_id\": 'F-67889r1_fix'\n tag \"cci\": ['CCI-001878']\n tag \"nist\": ['AU-7 a', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Verify that audit reduction capabilities are in place for the\n Oracle audit data. Since Oracle has no reduction capability per se, a\n third-party tool or in-house-developed software must be in place to provide\n this functionality. This must include the ability to report on the excluded\n audit data.\n\n If this capability has not been implemented, this is a finding.\"\n tag \"fix\": \"Deploy software capable of performing audit data reduction and of\n reporting on the excluded audit data.\"\n describe 'A manual review is required to ensure the system provides a report generation capability for audit\n reduction data' do\n skip 'A manual review is required to ensure the system provides a report generation capability for audit\n reduction data'\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61577.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61969.rb", "line": 1 }, - "id": "V-61577" + "id": "V-61969" }, { - "title": "Connections by mid-tier web and application systems to the Oracle DBMS\n from a DMZ or external network must be encrypted.\n ", - "desc": "Multi-tier systems may be configured with the database and connecting\n middle-tier system located on an internal network, with the database located on\n an internal network behind a firewall and the middle-tier system located in a\n DMZ. In cases where either or both systems are located in the DMZ (or on\n networks external to DoD), network communications between the systems must be\n encrypted.", + "title": "Object permissions granted to PUBLIC must be restricted.", + "desc": "Permissions on objects may be granted to the user group PUBLIC.\n Because every database user is a member of the PUBLIC group, granting object\n permissions to PUBLIC gives all users in the database access to that object. In\n a secure environment, granting object permissions to PUBLIC must be restricted\n to those objects that all users are allowed to access. The policy does not\n require object permissions assigned to PUBLIC by the installation of Oracle\n Database server components be revoked.", "descriptions": { - "default": "Multi-tier systems may be configured with the database and connecting\n middle-tier system located on an internal network, with the database located on\n an internal network behind a firewall and the middle-tier system located in a\n DMZ. In cases where either or both systems are located in the DMZ (or on\n networks external to DoD), network communications between the systems must be\n encrypted." + "default": "Permissions on objects may be granted to the user group PUBLIC.\n Because every database user is a member of the PUBLIC group, granting object\n permissions to PUBLIC gives all users in the database access to that object. In\n a secure environment, granting object permissions to PUBLIC must be restricted\n to those objects that all users are allowed to access. The policy does not\n require object permissions assigned to PUBLIC by the installation of Oracle\n Database server components be revoked." }, "impact": 0, - "refs": [ - { - "ref": [] - } - ], + "refs": [], "tags": { "gtitle": "SRG-APP-000516-DB-999900", - "gid": "V-61447", - "rid": "SV-75937r2_rule", - "stig_id": "O121-BP-023000", - "fix_id": "F-67363r2_fix", + "gid": "V-61439", + "rid": "SV-75929r3_rule", + "stig_id": "O121-BP-022600", + "fix_id": "F-67355r2_fix", "cci": [ "CCI-000366" ], @@ -1022,39 +1064,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Review the System Security Plan for remote applications that\n access and use the database.\n\n For each remote application or application server, determine whether\n communications between it and the DBMS are encrypted. If any are not encrypted,\n this is a finding.", - "fix": "Configure communications between the DBMS and remote\n applications/application servers to use DoD-approved encryption." + "check": "A default Oracle Database installation provides a set of\n predefined administrative accounts and non-administrative accounts. These are\n accounts that have special privileges required to administer areas of the\n database, such as the “CREATE ANY TABLE” or “ALTER SESSION” privilege, or\n “EXECUTE” privileges on packages owned by the SYS schema. The default\n tablespace for administrative accounts is either “SYSTEM” or “SYSAUX”.\n Non-administrative user accounts only have the minimum privileges needed to\n perform their jobs. Their default tablespace is “USERS”.\n\n To protect these accounts from unauthorized access, the installation process\n expires and locks most of these accounts, except where noted below. The\n database administrator is responsible for unlocking and resetting these\n accounts, as required.\n\n Non-Administrative Accounts - Expired and locked:\n APEX_PUBLIC_USER, DIP, FLOWS_040100*, FLOWS_FILES, MDDATA, ORACLE_OCM,\n SPATIAL_CSW_ADMIN_USR, SPATIAL_WFS_ADMIN_USR, XS$NULL\n\n Administrative Accounts - Expired and Locked:\n ANONYMOUS, CTXSTS, EXFSYS, LBACSYS, MDSYS, OLAPSYS, OEDDATA, OWBSYS,\n ORDPLUGINS, ORDSYS, OUTLN, SI_INFORMTN_SCHEMA, WK_TEST, WK_SYS, WKPROXY, WMSYS,\n XDB\n\n Administrative Accounts - Open:\n DBSNMP, MGMT_VIEW, SYS, SYSMAN, SYSTEM\n\n * Subject to change based on version installed\n\n Run the SQL query:\n\n select owner ||'.'|| table_name ||':'|| privilege from dba_tab_privs\n where grantee = 'PUBLIC';\n and owner not in\n ();\n\n (With respect to the list of special accounts that are excluded from this\n requirement, it is expected that the DBA will maintain the list to suit local\n circumstances, adding special accounts as necessary and removing any that are\n not supposed to be in use in the Oracle deployment that is under review.)\n\n If there are any records returned that are not Oracle product accounts, and are\n not documented and authorized, this is a finding.\n\n Note: This check may return false positives where other Oracle product accounts\n are not included in the exclusion list.", + "fix": "Revoke any privileges granted to PUBLIC for objects that are not\n owned by Oracle product accounts.\n\n From SQL*Plus:\n\n revoke [privilege name] from [user name] on [object name];\n\n Assign permissions to custom application user roles based on job functions:\n\n From SQL*Plus:\n\n grant [privilege name] to [user role] on [object name];" }, - "code": " control 'V-61447' do\n impact 0.0\n describe 'This control is not applicable on oracle within aws rds, as aws manages the operating system in which the oracle database is running on' do\n skip 'This control is not applicable on oracle within aws rds, as aws manages the operating system in which the oracle database is running on'\n end\n end\n", + "code": "control 'V-61439' do\n title 'Object permissions granted to PUBLIC must be restricted.'\n desc \"Permissions on objects may be granted to the user group PUBLIC.\n Because every database user is a member of the PUBLIC group, granting object\n permissions to PUBLIC gives all users in the database access to that object. In\n a secure environment, granting object permissions to PUBLIC must be restricted\n to those objects that all users are allowed to access. The policy does not\n require object permissions assigned to PUBLIC by the installation of Oracle\n Database server components be revoked.\"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000516-DB-999900'\n tag \"gid\": 'V-61439'\n tag \"rid\": 'SV-75929r3_rule'\n tag \"stig_id\": 'O121-BP-022600'\n tag \"fix_id\": 'F-67355r2_fix'\n tag \"cci\": ['CCI-000366']\n tag \"nist\": ['CM-6 b', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"A default Oracle Database installation provides a set of\n predefined administrative accounts and non-administrative accounts. These are\n accounts that have special privileges required to administer areas of the\n database, such as the “CREATE ANY TABLE” or “ALTER SESSION” privilege, or\n “EXECUTE” privileges on packages owned by the SYS schema. The default\n tablespace for administrative accounts is either “SYSTEM” or “SYSAUX”.\n Non-administrative user accounts only have the minimum privileges needed to\n perform their jobs. Their default tablespace is “USERS”.\n\n To protect these accounts from unauthorized access, the installation process\n expires and locks most of these accounts, except where noted below. The\n database administrator is responsible for unlocking and resetting these\n accounts, as required.\n\n Non-Administrative Accounts - Expired and locked:\n APEX_PUBLIC_USER, DIP, FLOWS_040100*, FLOWS_FILES, MDDATA, ORACLE_OCM,\n SPATIAL_CSW_ADMIN_USR, SPATIAL_WFS_ADMIN_USR, XS$NULL\n\n Administrative Accounts - Expired and Locked:\n ANONYMOUS, CTXSTS, EXFSYS, LBACSYS, MDSYS, OLAPSYS, OEDDATA, OWBSYS,\n ORDPLUGINS, ORDSYS, OUTLN, SI_INFORMTN_SCHEMA, WK_TEST, WK_SYS, WKPROXY, WMSYS,\n XDB\n\n Administrative Accounts - Open:\n DBSNMP, MGMT_VIEW, SYS, SYSMAN, SYSTEM\n\n * Subject to change based on version installed\n\n Run the SQL query:\n\n select owner ||'.'|| table_name ||':'|| privilege from dba_tab_privs\n where grantee = 'PUBLIC';\n and owner not in\n ();\n\n (With respect to the list of special accounts that are excluded from this\n requirement, it is expected that the DBA will maintain the list to suit local\n circumstances, adding special accounts as necessary and removing any that are\n not supposed to be in use in the Oracle deployment that is under review.)\n\n If there are any records returned that are not Oracle product accounts, and are\n not documented and authorized, this is a finding.\n\n Note: This check may return false positives where other Oracle product accounts\n are not included in the exclusion list.\"\n tag \"fix\": \"Revoke any privileges granted to PUBLIC for objects that are not\n owned by Oracle product accounts.\n\n From SQL*Plus:\n\n revoke [privilege name] from [user name] on [object name];\n\n Assign permissions to custom application user roles based on job functions:\n\n From SQL*Plus:\n\n grant [privilege name] to [user role] on [object name];\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n users_with_public_access = sql.query(\"select DISTINCT owner from dba_tab_privs where grantee = 'PUBLIC';\").column('owner').uniq\n\n if users_with_public_access.empty?\n impact 0.0\n describe 'There are no oracle users with access to PUBLIC, control N/A' do\n skip 'There are no oracle users with access to PUBLIC'\n end\n else\n users_with_public_access.each do |user|\n describe \"oracle user: #{user} with access to PUBLIC\" do\n subject { user }\n it { should be_in input('users_allowed_access_to_public')}\n end\n end\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61447.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61439.rb", "line": 1 }, - "id": "V-61447" + "id": "V-61439" }, { - "title": "Network access to the DBMS must be restricted to authorized personnel.", - "desc": "Restricting remote access to specific, trusted systems helps prevent\n access by unauthorized and potentially malicious users.", + "title": "The DBMS must isolate security functions from nonsecurity functions by\n means of separate security domains.", + "desc": "Security functions are defined as \"the hardware, software, and/or\n firmware of the information system responsible for enforcing the system\n security policy and supporting the isolation of code and data on which the\n protection is based\".\n\n Developers and implementers can increase the assurance in security\n functions by employing well-defined security policy models, structured,\n disciplined, and rigorous hardware and software development techniques, and\n sound system/security engineering principles.\n\n Database Management Systems typically separate security functionality from\n non-security functionality via separate databases or schemas. Database objects\n or code implementing security functionality must not be commingled with objects\n or code implementing application logic. When security and non-security\n functionality is commingled, users who have access to non-security\n functionality may be able to access security functionality.", "descriptions": { - "default": "Restricting remote access to specific, trusted systems helps prevent\n access by unauthorized and potentially malicious users." + "default": "Security functions are defined as \"the hardware, software, and/or\n firmware of the information system responsible for enforcing the system\n security policy and supporting the isolation of code and data on which the\n protection is based\".\n\n Developers and implementers can increase the assurance in security\n functions by employing well-defined security policy models, structured,\n disciplined, and rigorous hardware and software development techniques, and\n sound system/security engineering principles.\n\n Database Management Systems typically separate security functionality from\n non-security functionality via separate databases or schemas. Database objects\n or code implementing security functionality must not be commingled with objects\n or code implementing application logic. When security and non-security\n functionality is commingled, users who have access to non-security\n functionality may be able to access security functionality." }, - "impact": 0, - "refs": [ - { - "ref": [] - } - ], + "impact": 0.5, + "refs": [], "tags": { - "gtitle": "SRG-APP-000516-DB-999900", - "gid": "V-61515", - "rid": "SV-76005r2_rule", - "stig_id": "O121-BP-025600", - "fix_id": "F-67431r1_fix", + "gtitle": "SRG-APP-000233-DB-000124", + "gid": "V-61775", + "rid": "SV-76265r1_rule", + "stig_id": "O121-C2-018500", + "fix_id": "F-67691r1_fix", "cci": [ - "CCI-000366" + "CCI-001084" ], "nist": [ - "CM-6 b", + "SC-3", "Rev_4" ], "false_negatives": null, @@ -1067,35 +1105,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "IP address restriction may be defined for the database\n listener, by use of the Oracle Connection Manager or by an external network\n device.\n\n Identify the method used to enforce address restriction (interview or System\n Security Plan review).\n\n If enforced by the database listener, then review the SQLNET.ORA file located\n in the ORACLE_HOME/network/admin directory (note: this assumes that a single\n sqlnet.ora file, in the default location, is in use; please see the\n supplemental file \"Non-default sqlnet.ora configurations.pdf\" for how to find\n multiple and/or differently located sqlnet.ora files) or the directory\n indicated by the TNS_ADMIN environment variable or registry setting.\n\n If the following entries do not exist, then restriction by IP address is not\n configured and is a finding.\n\n tcp.validnode_checking=YES\n tcp.invited_nodes=(IP1, IP2, IP3)\n\n If enforced by an Oracle Connection Manager, then review the CMAN.ORA file for\n the Connection Manager (located in the TNS_ADMIN or ORACLE_HOME/network/admin\n directory for the connection manager).\n\n If a RULE entry allows all addresses (\"/32\") or does not match the address\n range specified in the System Security Plan, this is a finding.\n\n (rule=(src=[IP]/27)(dst=[IP])(srv=*)(act=accept))\n\n Note: an IP address with a \"/\" indicates acceptance by subnet mask where the\n number after the \"/\" is the left most number of bits in the address that must\n match for the rule to apply.\n\n If this rule is database-specific, then determine if the SERVICE_NAMES\n parameter is set:\n\n From SQL*PLUS:\n\n select value from v$parameter where name = 'service_names';\n\n If SERVICE_NAMES is set in the initialization file for the database instance,\n use (srv=[service name]), else, use (srv=*) if not set or rule applies to all\n databases on the DBMS server.\n\n If network access restriction is performed by an external device, validate ACLs\n are in place to prohibit unauthorized access to the DBMS. To do this, find the\n IP address of the database server (destination address) and source address\n (authorized IPs) in the System Security Plan. Confirm only authorized IPs from\n the System Security Plan are allowed access to the DBMS.", - "fix": "Configure the database listener to restrict access by IP address\n or set up an external device to restrict network access to the DBMS." + "check": "Check DBMS settings to determine whether objects or code\n implementing security functionality are located in a separate security domain,\n such as a separate database or schema created specifically for security\n functionality.\n\n If security-related database objects or code are not kept separate, this is a\n finding.\n\n The Oracle elements of security functionality, such as the roles, permissions,\n and profiles, along with password complexity requirements, are stored in\n separate schemas in the database. Review any site-specific applications\n security modules built into the database and determine what schema they are\n located in and take appropriate action. The Oracle objects will be in the\n Oracle Data Dictionary.", + "fix": "Locate security-related database objects and code in a separate\n database, schema, or other separate security domain from database objects and\n code implementing application logic. (This is the default behavior for\n Oracle.) Review any site-specific applications security modules built into the\n database: determine what schema they are located in and take appropriate\n action." }, - "code": " control 'V-61515' do\n impact 0.0\n describe 'This control is not applicable on oracle within aws rds, as aws manages the operating system in which the oracle database is running on' do\n skip 'This control is not applicable on oracle within aws rds, as aws manages the operating system in which the oracle database is running on'\n end\n end\n", + "code": "control 'V-61775' do\n title \"The DBMS must isolate security functions from nonsecurity functions by\n means of separate security domains.\"\n desc \"Security functions are defined as \\\"the hardware, software, and/or\n firmware of the information system responsible for enforcing the system\n security policy and supporting the isolation of code and data on which the\n protection is based\\\".\n\n Developers and implementers can increase the assurance in security\n functions by employing well-defined security policy models, structured,\n disciplined, and rigorous hardware and software development techniques, and\n sound system/security engineering principles.\n\n Database Management Systems typically separate security functionality from\n non-security functionality via separate databases or schemas. Database objects\n or code implementing security functionality must not be commingled with objects\n or code implementing application logic. When security and non-security\n functionality is commingled, users who have access to non-security\n functionality may be able to access security functionality.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000233-DB-000124'\n tag \"gid\": 'V-61775'\n tag \"rid\": 'SV-76265r1_rule'\n tag \"stig_id\": 'O121-C2-018500'\n tag \"fix_id\": 'F-67691r1_fix'\n tag \"cci\": ['CCI-001084']\n tag \"nist\": ['SC-3', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Check DBMS settings to determine whether objects or code\n implementing security functionality are located in a separate security domain,\n such as a separate database or schema created specifically for security\n functionality.\n\n If security-related database objects or code are not kept separate, this is a\n finding.\n\n The Oracle elements of security functionality, such as the roles, permissions,\n and profiles, along with password complexity requirements, are stored in\n separate schemas in the database. Review any site-specific applications\n security modules built into the database and determine what schema they are\n located in and take appropriate action. The Oracle objects will be in the\n Oracle Data Dictionary.\"\n tag \"fix\": \"Locate security-related database objects and code in a separate\n database, schema, or other separate security domain from database objects and\n code implementing application logic. (This is the default behavior for\n Oracle.) Review any site-specific applications security modules built into the\n database: determine what schema they are located in and take appropriate\n action.\"\n describe 'A manual review is required to ensure the DBMS isolates security functions from nonsecurity functions by\n means of separate security domains' do\n skip 'A manual review is required to ensure the DBMS isolates security functions from nonsecurity functions by\n means of separate security domains'\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61515.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61775.rb", "line": 1 }, - "id": "V-61515" + "id": "V-61775" }, { - "title": "The OS must limit privileges to change the DBMS software resident\n within software libraries (including privileged programs).", - "desc": "When dealing with change control issues, it should be noted, any\n changes to the hardware, software, and/or firmware components of the\n information system and/or application can potentially have significant effects\n on the overall security of the system.\n\n If the application were to allow any user to make changes to software\n libraries, then those changes might be implemented without undergoing the\n appropriate testing and approvals that are part of a robust change management\n process.\n\n This requirement is contingent upon the language in which the application\n is programmed, as many application architectures in use today incorporate their\n software libraries into, and make them inseparable from, their compiled\n distributions, rendering them static and version-dependent. However, this\n requirement does apply to applications with software libraries accessible and\n configurable as in the case of interpreted languages.\n\n Accordingly, only qualified and authorized individuals shall be allowed to\n obtain access to information system components for purposes of initiating\n changes, including upgrades and modifications.\n\n The DBMS software libraries contain the executables used by the DBMS to\n operate. Unauthorized access to the libraries can result in malicious\n alteration. This may in turn jeopardize data stored in the DBMS and/or\n operation of the host system.", + "title": "The DBMS must only generate error messages that provide information\n necessary for corrective actions without revealing organization-defined\n sensitive or potentially harmful information in error logs and administrative\n messages that could be exploited.", + "desc": "Any application providing too much information in error logs and in\n administrative messages to the screen risks compromising the data and security\n of the application and system. The structure and content of error messages\n needs to be carefully considered by the organization and development team.\n\n The extent to which the application is able to identify and handle error\n conditions is guided by organizational policy and operational requirements.\n Sensitive information includes account numbers, social security numbers, and\n credit card numbers.\n\n Databases can inadvertently provide a wealth of information to an attacker\n through improperly handled error messages. In addition to sensitive business or\n personal information, database errors can provide host names, IP addresses,\n user names, and other system information not required for troubleshooting but\n very useful to someone targeting the system.\n\n This calls for inspection of application source code, which will require\n collaboration with the application developers. It is recognized that in many\n cases, the database administrator (DBA) is organizationally separate from the\n application developers and may have limited, if any, access to source code.\n Nevertheless, protections of this type are so important to the secure operation\n of databases that they must not be ignored. At a minimum, the DBA must attempt\n to obtain assurances from the development organization that this issue has been\n addressed and must document what has been discovered.", "descriptions": { - "default": "When dealing with change control issues, it should be noted, any\n changes to the hardware, software, and/or firmware components of the\n information system and/or application can potentially have significant effects\n on the overall security of the system.\n\n If the application were to allow any user to make changes to software\n libraries, then those changes might be implemented without undergoing the\n appropriate testing and approvals that are part of a robust change management\n process.\n\n This requirement is contingent upon the language in which the application\n is programmed, as many application architectures in use today incorporate their\n software libraries into, and make them inseparable from, their compiled\n distributions, rendering them static and version-dependent. However, this\n requirement does apply to applications with software libraries accessible and\n configurable as in the case of interpreted languages.\n\n Accordingly, only qualified and authorized individuals shall be allowed to\n obtain access to information system components for purposes of initiating\n changes, including upgrades and modifications.\n\n The DBMS software libraries contain the executables used by the DBMS to\n operate. Unauthorized access to the libraries can result in malicious\n alteration. This may in turn jeopardize data stored in the DBMS and/or\n operation of the host system." + "default": "Any application providing too much information in error logs and in\n administrative messages to the screen risks compromising the data and security\n of the application and system. The structure and content of error messages\n needs to be carefully considered by the organization and development team.\n\n The extent to which the application is able to identify and handle error\n conditions is guided by organizational policy and operational requirements.\n Sensitive information includes account numbers, social security numbers, and\n credit card numbers.\n\n Databases can inadvertently provide a wealth of information to an attacker\n through improperly handled error messages. In addition to sensitive business or\n personal information, database errors can provide host names, IP addresses,\n user names, and other system information not required for troubleshooting but\n very useful to someone targeting the system.\n\n This calls for inspection of application source code, which will require\n collaboration with the application developers. It is recognized that in many\n cases, the database administrator (DBA) is organizationally separate from the\n application developers and may have limited, if any, access to source code.\n Nevertheless, protections of this type are so important to the secure operation\n of databases that they must not be ignored. At a minimum, the DBA must attempt\n to obtain assurances from the development organization that this issue has been\n addressed and must document what has been discovered." }, - "impact": 0, + "impact": 0.5, "refs": [], "tags": { - "gtitle": "SRG-APP-000133-DB-000207", - "gid": "V-61869", - "rid": "SV-76359r1_rule", - "stig_id": "O121-OS-011200", - "fix_id": "F-67785r1_fix", + "gtitle": "SRG-APP-000266-DB-000162", + "gid": "V-61791", + "rid": "SV-76281r2_rule", + "stig_id": "O121-C2-019900", + "fix_id": "F-67707r1_fix", "cci": [ - "CCI-001499" + "CCI-001312" ], "nist": [ - "CM-5 (6)", + "SI-11 a", "Rev_4" ], "false_negatives": null, @@ -1108,35 +1146,36 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Review permissions that control access to the DBMS software\n libraries. The software library location may be determined from vendor\n documentation or service/process executable paths.\n\n DBA accounts, the DBMS process account, the DBMS software\n installation/maintenance account, SA accounts, if access by them is required\n for some operational level of support such as backups, and the host system\n itself require access. Any others should be scrutinized and a reason for access\n provided by the DBA.\n\n If accounts that are not required and authorized to have access to the software\n library location do have access, this is a finding.\n\n Check to see which users have been granted DBA. Work from a basis of least\n privilege. Provide the least amount of privilege required to accomplish the\n job.\n\n SQL> select * from dba_role_privs where granted_role = 'DBA';", - "fix": "Restrict access to the DBMS software libraries to accounts that\n require access based on job function." + "check": "Check DBMS settings and custom database and application code to\n verify error messages do not contain information beyond what is needed for\n troubleshooting the issue.\n\n If database errors contain PII data, sensitive business data, or information\n useful for identifying the host system, this is a finding.\n\n Notes on Oracle's approach to this issue: Out of the box, Oracle covers this.\n For example, if a user does not have access to a table, the error is just that\n the table or view does not exist. The Oracle database is not going to display a\n Social Security Number in an error code unless an application is programmed to\n do so. Oracle applications will not expose the actual transactional data to a\n screen. The only way Oracle will capture this information is to enable\n specific logging levels. Custom code would require a review to ensure\n compliance.", + "fix": "Configure DBMS and custom database and application code not to\n divulge sensitive information or information useful for system identification\n in error information." }, - "code": "control 'V-61869' do\n title \"The OS must limit privileges to change the DBMS software resident\n within software libraries (including privileged programs).\"\n desc \"When dealing with change control issues, it should be noted, any\n changes to the hardware, software, and/or firmware components of the\n information system and/or application can potentially have significant effects\n on the overall security of the system.\n\n If the application were to allow any user to make changes to software\n libraries, then those changes might be implemented without undergoing the\n appropriate testing and approvals that are part of a robust change management\n process.\n\n This requirement is contingent upon the language in which the application\n is programmed, as many application architectures in use today incorporate their\n software libraries into, and make them inseparable from, their compiled\n distributions, rendering them static and version-dependent. However, this\n requirement does apply to applications with software libraries accessible and\n configurable as in the case of interpreted languages.\n\n Accordingly, only qualified and authorized individuals shall be allowed to\n obtain access to information system components for purposes of initiating\n changes, including upgrades and modifications.\n\n The DBMS software libraries contain the executables used by the DBMS to\n operate. Unauthorized access to the libraries can result in malicious\n alteration. This may in turn jeopardize data stored in the DBMS and/or\n operation of the host system.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000133-DB-000207'\n tag \"gid\": 'V-61869'\n tag \"rid\": 'SV-76359r1_rule'\n tag \"stig_id\": 'O121-OS-011200'\n tag \"fix_id\": 'F-67785r1_fix'\n tag \"cci\": ['CCI-001499']\n tag \"nist\": ['CM-5 (6)', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Review permissions that control access to the DBMS software\n libraries. The software library location may be determined from vendor\n documentation or service/process executable paths.\n\n DBA accounts, the DBMS process account, the DBMS software\n installation/maintenance account, SA accounts, if access by them is required\n for some operational level of support such as backups, and the host system\n itself require access. Any others should be scrutinized and a reason for access\n provided by the DBA.\n\n If accounts that are not required and authorized to have access to the software\n library location do have access, this is a finding.\n\n Check to see which users have been granted DBA. Work from a basis of least\n privilege. Provide the least amount of privilege required to accomplish the\n job.\n\n SQL> select * from dba_role_privs where granted_role = 'DBA';\"\n tag \"fix\": \"Restrict access to the DBMS software libraries to accounts that\n require access based on job function.\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n dba_users = sql.query(\"select * from dba_role_privs where granted_role = 'DBA';\").column('grantee').uniq\n if dba_users.empty?\n impact 0.0\n describe \"There are no oracle DBA's, control N/A\" do\n skip \"There are no oracle DBA's, control N/A\"\n end\n else\n dba_users.each do |user|\n describe \"oracle DBA's users: #{user}\" do\n subject { user }\n it { should be_in input('oracle_dbas') }\n end\n end\n end\nend\n", + "code": "control 'V-61791' do\n title \"The DBMS must only generate error messages that provide information\n necessary for corrective actions without revealing organization-defined\n sensitive or potentially harmful information in error logs and administrative\n messages that could be exploited.\"\n desc \"Any application providing too much information in error logs and in\n administrative messages to the screen risks compromising the data and security\n of the application and system. The structure and content of error messages\n needs to be carefully considered by the organization and development team.\n\n The extent to which the application is able to identify and handle error\n conditions is guided by organizational policy and operational requirements.\n Sensitive information includes account numbers, social security numbers, and\n credit card numbers.\n\n Databases can inadvertently provide a wealth of information to an attacker\n through improperly handled error messages. In addition to sensitive business or\n personal information, database errors can provide host names, IP addresses,\n user names, and other system information not required for troubleshooting but\n very useful to someone targeting the system.\n\n This calls for inspection of application source code, which will require\n collaboration with the application developers. It is recognized that in many\n cases, the database administrator (DBA) is organizationally separate from the\n application developers and may have limited, if any, access to source code.\n Nevertheless, protections of this type are so important to the secure operation\n of databases that they must not be ignored. At a minimum, the DBA must attempt\n to obtain assurances from the development organization that this issue has been\n addressed and must document what has been discovered.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000266-DB-000162'\n tag \"gid\": 'V-61791'\n tag \"rid\": 'SV-76281r2_rule'\n tag \"stig_id\": 'O121-C2-019900'\n tag \"fix_id\": 'F-67707r1_fix'\n tag \"cci\": ['CCI-001312']\n tag \"nist\": ['SI-11 a', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Check DBMS settings and custom database and application code to\n verify error messages do not contain information beyond what is needed for\n troubleshooting the issue.\n\n If database errors contain PII data, sensitive business data, or information\n useful for identifying the host system, this is a finding.\n\n Notes on Oracle's approach to this issue: Out of the box, Oracle covers this.\n For example, if a user does not have access to a table, the error is just that\n the table or view does not exist. The Oracle database is not going to display a\n Social Security Number in an error code unless an application is programmed to\n do so. Oracle applications will not expose the actual transactional data to a\n screen. The only way Oracle will capture this information is to enable\n specific logging levels. Custom code would require a review to ensure\n compliance.\"\n tag \"fix\": \"Configure DBMS and custom database and application code not to\n divulge sensitive information or information useful for system identification\n in error information.\"\n describe 'A manual review is required to ensure the DBMS only generates error messages that provide information\n necessary for corrective actions without revealing organization-defined\n sensitive or potentially harmful information in error logs and administrative\n messages that could be exploited.' do\n skip 'A manual review is required to ensure the DBMS only generates error messages that provide information\n necessary for corrective actions without revealing organization-defined\n sensitive or potentially harmful information in error logs and administrative\n messages that could be exploited.'\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61869.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61791.rb", "line": 1 }, - "id": "V-61869" + "id": "V-61791" }, { - "title": "Oracle must back up user-level information per a defined frequency.", - "desc": "Information system backup is a critical step in maintaining data\n assurance and availability.\n\n User-level information is data generated by information system and/or\n application users. In order to assure availability of this data in the event of\n a system failure, DoD organizations are required to ensure user-generated data\n is backed up at a defined frequency. This includes data stored on file systems,\n within databases or within any other storage media.\n\n Applications performing backups must be capable of backing up user-level\n information per the DoD-defined frequency.\n\n Databases that do not backup information regularly risk the loss of that\n information in the event of a system failure. Most databases contain\n functionality to allow regular backups; it is important that this functionality\n is enabled and configured correctly to prevent data loss.", + "title": "A single database connection configuration file must not be used to\n configure all database clients.", + "desc": "Applications employ the concept of least privilege for specific duties\n and information systems (including specific functions, ports, protocols, and\n services). The concept of least privilege is also applied to information system\n processes, ensuring that the processes operate at privilege levels no higher\n than necessary to accomplish required organizational missions and/or functions.\n Organizations consider the creation of additional processes, roles, and\n information system accounts as necessary to achieve least privilege.\n Organizations also apply least privilege concepts to the design, development,\n implementation, and operations of information systems.\n\n Many sites distribute a single client database connection configuration\n file to all site database users that contains network access information for\n all databases on the site. Such a file provides information to access databases\n not required by all users that may assist in unauthorized access attempts.", "descriptions": { - "default": "Information system backup is a critical step in maintaining data\n assurance and availability.\n\n User-level information is data generated by information system and/or\n application users. In order to assure availability of this data in the event of\n a system failure, DoD organizations are required to ensure user-generated data\n is backed up at a defined frequency. This includes data stored on file systems,\n within databases or within any other storage media.\n\n Applications performing backups must be capable of backing up user-level\n information per the DoD-defined frequency.\n\n Databases that do not backup information regularly risk the loss of that\n information in the event of a system failure. Most databases contain\n functionality to allow regular backups; it is important that this functionality\n is enabled and configured correctly to prevent data loss." + "default": "Applications employ the concept of least privilege for specific duties\n and information systems (including specific functions, ports, protocols, and\n services). The concept of least privilege is also applied to information system\n processes, ensuring that the processes operate at privilege levels no higher\n than necessary to accomplish required organizational missions and/or functions.\n Organizations consider the creation of additional processes, roles, and\n information system accounts as necessary to achieve least privilege.\n Organizations also apply least privilege concepts to the design, development,\n implementation, and operations of information systems.\n\n Many sites distribute a single client database connection configuration\n file to all site database users that contains network access information for\n all databases on the site. Such a file provides information to access databases\n not required by all users that may assist in unauthorized access attempts." }, "impact": 0.5, "refs": [], "tags": { - "gtitle": "SRG-APP-000145-DB-000095", - "gid": "V-61693", - "rid": "SV-76183r2_rule", - "stig_id": "O121-C2-012200", - "fix_id": "F-67609r1_fix", + "gtitle": "SRG-APP-000062-DB-000012", + "gid": "V-61583", + "rid": "SV-76073r1_rule", + "stig_id": "O121-C2-003600", + "fix_id": "F-67499r1_fix", "cci": [ - "CCI-000535" + "CCI-000366", + "CCI-002220" ], "nist": [ - "CP-9 (a)", + "AC-5 c", "Rev_4" ], "false_negatives": null, @@ -1149,30 +1188,30 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Review DBMS settings and site documentation to determine\n whether Oracle is configured to back up user-level data according to a defined\n frequency.\n\n If it is not, this is a finding.\n\n (The V$RMAN_STATUS view displays the finished and on-going RMAN jobs. For\n on-going jobs, this view displays progress and status.)", - "fix": "Configure the Oracle DBMS to back up user-level data on a defined\n frequency." + "check": "Review procedures for providing database connection information\n to users/user workstations. If procedures do not indicate or implement\n restrictions to connections required by the particular user, this is a finding.\n\n Note: This check is specific for the DBMS host system and not directed at\n client systems (client systems are included in the Application STIG/Checklist);\n however, detection of unauthorized client connections to the DBMS host system\n obtained through log files should be performed regularly and documented where\n authorized.", + "fix": "Implement procedures to supply database connection information to\n only those databases authorized for the user." }, - "code": "control 'V-61693' do\n title 'Oracle must back up user-level information per a defined frequency.'\n desc \"Information system backup is a critical step in maintaining data\n assurance and availability.\n\n User-level information is data generated by information system and/or\n application users. In order to assure availability of this data in the event of\n a system failure, DoD organizations are required to ensure user-generated data\n is backed up at a defined frequency. This includes data stored on file systems,\n within databases or within any other storage media.\n\n Applications performing backups must be capable of backing up user-level\n information per the DoD-defined frequency.\n\n Databases that do not backup information regularly risk the loss of that\n information in the event of a system failure. Most databases contain\n functionality to allow regular backups; it is important that this functionality\n is enabled and configured correctly to prevent data loss.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000145-DB-000095'\n tag \"gid\": 'V-61693'\n tag \"rid\": 'SV-76183r2_rule'\n tag \"stig_id\": 'O121-C2-012200'\n tag \"fix_id\": 'F-67609r1_fix'\n tag \"cci\": ['CCI-000535']\n tag \"nist\": ['CP-9 (a)', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Review DBMS settings and site documentation to determine\n whether Oracle is configured to back up user-level data according to a defined\n frequency.\n\n If it is not, this is a finding.\n\n (The V$RMAN_STATUS view displays the finished and on-going RMAN jobs. For\n on-going jobs, this view displays progress and status.)\"\n tag \"fix\": \"Configure the Oracle DBMS to back up user-level data on a defined\n frequency.\"\n describe 'A manual review is required to ensure Oracle backs up user-level information per a defined frequency' do\n skip 'A manual review is required to ensure Oracle backs up user-level information per a defined frequency'\n end\nend\n", + "code": "control 'V-61583' do\n title \"A single database connection configuration file must not be used to\n configure all database clients.\"\n desc \"Applications employ the concept of least privilege for specific duties\n and information systems (including specific functions, ports, protocols, and\n services). The concept of least privilege is also applied to information system\n processes, ensuring that the processes operate at privilege levels no higher\n than necessary to accomplish required organizational missions and/or functions.\n Organizations consider the creation of additional processes, roles, and\n information system accounts as necessary to achieve least privilege.\n Organizations also apply least privilege concepts to the design, development,\n implementation, and operations of information systems.\n\n Many sites distribute a single client database connection configuration\n file to all site database users that contains network access information for\n all databases on the site. Such a file provides information to access databases\n not required by all users that may assist in unauthorized access attempts.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000062-DB-000012'\n tag \"gid\": 'V-61583'\n tag \"rid\": 'SV-76073r1_rule'\n tag \"stig_id\": 'O121-C2-003600'\n tag \"fix_id\": 'F-67499r1_fix'\n tag \"cci\": ['CCI-000366', 'CCI-002220']\n tag \"nist\": ['CM-6 b', 'Rev_4']\n tag \"nist\": ['AC-5 c', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Review procedures for providing database connection information\n to users/user workstations. If procedures do not indicate or implement\n restrictions to connections required by the particular user, this is a finding.\n\n Note: This check is specific for the DBMS host system and not directed at\n client systems (client systems are included in the Application STIG/Checklist);\n however, detection of unauthorized client connections to the DBMS host system\n obtained through log files should be performed regularly and documented where\n authorized.\"\n tag \"fix\": \"Implement procedures to supply database connection information to\n only those databases authorized for the user.\"\n describe 'A manual review is required to ensure a single database connection configuration file is not used to\n configure all database clients' do\n skip 'A manual review is required to ensure a single database connection configuration file is not used to\n configure all database clients'\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61693.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61583.rb", "line": 1 }, - "id": "V-61693" + "id": "V-61583" }, { - "title": "Unauthorized database links must not be defined and active.", - "desc": "DBMS links provide a communication and data transfer path definition\n between two databases that may be used by malicious users to discover and\n obtain unauthorized access to remote systems. Database links between production\n and development DBMSs provide a means for developers to access production data\n not authorized for their access or to introduce untested or unauthorized\n applications to the production database. Only protected, controlled, and\n authorized downloads of any production data to use for development may be\n allowed. Only applications that have completed the configuration management\n process may be introduced by the application object owner account to the\n production system.", + "title": "The directories assigned to the LOG_ARCHIVE_DEST* parameters must be\n protected from unauthorized access.", + "desc": "The LOG_ARCHIVE_DEST parameter is used to specify the directory to\n which Oracle archive logs are written. Where the DBMS availability and recovery\n to a specific point in time is critical, the protection of archive log files is\n critical. Archive log files may also contain unencrypted sensitive data. If\n written to an inadequately protected or invalidated directory, the archive log\n files may be accessed by unauthorized persons or processes.", "descriptions": { - "default": "DBMS links provide a communication and data transfer path definition\n between two databases that may be used by malicious users to discover and\n obtain unauthorized access to remote systems. Database links between production\n and development DBMSs provide a means for developers to access production data\n not authorized for their access or to introduce untested or unauthorized\n applications to the production database. Only protected, controlled, and\n authorized downloads of any production data to use for development may be\n allowed. Only applications that have completed the configuration management\n process may be introduced by the application object owner account to the\n production system." + "default": "The LOG_ARCHIVE_DEST parameter is used to specify the directory to\n which Oracle archive logs are written. Where the DBMS availability and recovery\n to a specific point in time is critical, the protection of archive log files is\n critical. Archive log files may also contain unencrypted sensitive data. If\n written to an inadequately protected or invalidated directory, the archive log\n files may be accessed by unauthorized persons or processes." }, - "impact": 0, + "impact": 0.5, "refs": [], "tags": { "gtitle": "SRG-APP-000516-DB-999900", - "gid": "V-61451", - "rid": "SV-75941r1_rule", - "stig_id": "O121-BP-023200", - "fix_id": "F-67367r1_fix", + "gid": "V-61463", + "rid": "SV-75953r1_rule", + "stig_id": "O121-BP-023800", + "fix_id": "F-67379r1_fix", "cci": [ "CCI-000366" ], @@ -1190,35 +1229,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "From SQL*Plus:\n select db_link||': '||host from dba_db_links;\n\n If no links are returned, this check is not a finding.\n\n Review documentation for definitions of authorized database links to external\n interfaces.\n\n The documentation should include:\n\n - Any remote access to the database\n - The purpose or function of the remote connection\n - Any access to data or procedures stored externally to the local DBMS\n - Any network ports or protocols used by remote connections, whether the remote\n connection is to a production, test, or development system\n - Any security accounts used by DBMS to access remote resources or objects\n\n If any unauthorized database links are defined or the definitions do not match\n the documentation, this is a finding.\n\n Note: findings for production-development links under this check are assigned\n to the production database only.\n\n If any database links are defined between the production database and any test\n or development databases, this is a finding.\n\n If remote interface documentation does not exist or is incomplete, this is a\n finding.", - "fix": "Document all remote or external interfaces used by the DBMS to\n connect to or allow connections from remote or external sources.\n\n Include with the documentation as appropriate, any network ports or protocols,\n security accounts, and the sensitivity of any data exchanged.\n\n Do not define or configure database links between production databases and test\n or development databases.\n\n Note: Oracle Database Advanced Replication is deprecated in Oracle Database\n 12c. Use Oracle GoldenGate to replace all features of Advanced Replication,\n including multimaster replication, updatable materialized views, hierarchical\n materialized views, and deployment templates." + "check": "From SQL*Plus:\n\n select log_mode from v$database;\n select value from v$parameter where name = 'log_archive_dest';\n select value from v$parameter where name = 'log_archive_duplex_dest';\n select name, value from v$parameter where name LIKE 'log_archive_dest_%';\n select value from v$parameter where name = 'db_recovery_file_dest';\n\n If the value returned for LOG_MODE is NOARCHIVELOG, this check is not a finding.\n\n If a value is not returned for LOG_ARCHIVE_DEST and no values are returned for\n any of the LOG_ARCHIVE_DEST_[1-10] parameters, and no value is returned for\n DB_RECOVERY_FILE_DEST, this is a finding.\n\n Note: LOG_ARCHIVE_DEST and LOG_ARCHIVE_DUPLEX_DEST are incompatible with the\n LOG_ARCHIVE_DEST_n parameters, and must be defined as the null string (' ')\n when any LOG_ARCHIVE_DEST_n parameter has a value other than a null string.\n\n On UNIX Systems:\n\n ls -ld [pathname]\n\n Substitute [pathname] with the directory paths listed from the above SQL\n statements for log_archive_dest and log_archive_duplex_dest.\n\n If permissions are granted for world access, this is a finding.\n\n On Windows Systems (From Windows Explorer):\n\n Browse to the directory specified.\n\n Select and right-click on the directory, select Properties, select the Security\n tab.\n\n If permissions are granted to everyone, this is a finding.\n\n If any account other than the Oracle process and software owner accounts,\n Administrators, DBAs, System group or developers authorized to write and debug\n applications on this database are listed, this is a finding.", + "fix": "Specify a valid and protected directory for archive log files.\n\n Restrict access to the Oracle process and software owner accounts, DBAs, and\n backup operator accounts." }, - "code": "control 'V-61451' do\n title 'Unauthorized database links must not be defined and active.'\n desc \"DBMS links provide a communication and data transfer path definition\n between two databases that may be used by malicious users to discover and\n obtain unauthorized access to remote systems. Database links between production\n and development DBMSs provide a means for developers to access production data\n not authorized for their access or to introduce untested or unauthorized\n applications to the production database. Only protected, controlled, and\n authorized downloads of any production data to use for development may be\n allowed. Only applications that have completed the configuration management\n process may be introduced by the application object owner account to the\n production system.\"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000516-DB-999900'\n tag \"gid\": 'V-61451'\n tag \"rid\": 'SV-75941r1_rule'\n tag \"stig_id\": 'O121-BP-023200'\n tag \"fix_id\": 'F-67367r1_fix'\n tag \"cci\": ['CCI-000366']\n tag \"nist\": ['CM-6 b', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"From SQL*Plus:\n select db_link||': '||host from dba_db_links;\n\n If no links are returned, this check is not a finding.\n\n Review documentation for definitions of authorized database links to external\n interfaces.\n\n The documentation should include:\n\n - Any remote access to the database\n - The purpose or function of the remote connection\n - Any access to data or procedures stored externally to the local DBMS\n - Any network ports or protocols used by remote connections, whether the remote\n connection is to a production, test, or development system\n - Any security accounts used by DBMS to access remote resources or objects\n\n If any unauthorized database links are defined or the definitions do not match\n the documentation, this is a finding.\n\n Note: findings for production-development links under this check are assigned\n to the production database only.\n\n If any database links are defined between the production database and any test\n or development databases, this is a finding.\n\n If remote interface documentation does not exist or is incomplete, this is a\n finding.\"\n tag \"fix\": \"Document all remote or external interfaces used by the DBMS to\n connect to or allow connections from remote or external sources.\n\n Include with the documentation as appropriate, any network ports or protocols,\n security accounts, and the sensitivity of any data exchanged.\n\n Do not define or configure database links between production databases and test\n or development databases.\n\n Note: Oracle Database Advanced Replication is deprecated in Oracle Database\n 12c. Use Oracle GoldenGate to replace all features of Advanced Replication,\n including multimaster replication, updatable materialized views, hierarchical\n materialized views, and deployment templates.\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n db_links = sql.query('SELECT DB_LINK FROM DBA_DB_LINKS;').column('db_link').uniq\n if db_links.empty?\n impact 0.0\n describe 'There are no oracle database links defined, control N/A' do\n skip 'There are no oracle database links defined, control N/A'\n end\n else\n db_links.each do |link|\n describe \"The defined oracle database link: #{link}\" do\n subject { link }\n it { should be_in input('allowed_db_links') }\n end\n end\n end\nend\n", + "code": "control 'V-61463' do\n title \"The directories assigned to the LOG_ARCHIVE_DEST* parameters must be\n protected from unauthorized access.\"\n desc \"The LOG_ARCHIVE_DEST parameter is used to specify the directory to\n which Oracle archive logs are written. Where the DBMS availability and recovery\n to a specific point in time is critical, the protection of archive log files is\n critical. Archive log files may also contain unencrypted sensitive data. If\n written to an inadequately protected or invalidated directory, the archive log\n files may be accessed by unauthorized persons or processes.\"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000516-DB-999900'\n tag \"gid\": 'V-61463'\n tag \"rid\": 'SV-75953r1_rule'\n tag \"stig_id\": 'O121-BP-023800'\n tag \"fix_id\": 'F-67379r1_fix'\n tag \"cci\": ['CCI-000366']\n tag \"nist\": ['CM-6 b', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"From SQL*Plus:\n\n select log_mode from v$database;\n select value from v$parameter where name = 'log_archive_dest';\n select value from v$parameter where name = 'log_archive_duplex_dest';\n select name, value from v$parameter where name LIKE 'log_archive_dest_%';\n select value from v$parameter where name = 'db_recovery_file_dest';\n\n If the value returned for LOG_MODE is NOARCHIVELOG, this check is not a finding.\n\n If a value is not returned for LOG_ARCHIVE_DEST and no values are returned for\n any of the LOG_ARCHIVE_DEST_[1-10] parameters, and no value is returned for\n DB_RECOVERY_FILE_DEST, this is a finding.\n\n Note: LOG_ARCHIVE_DEST and LOG_ARCHIVE_DUPLEX_DEST are incompatible with the\n LOG_ARCHIVE_DEST_n parameters, and must be defined as the null string (' ')\n when any LOG_ARCHIVE_DEST_n parameter has a value other than a null string.\n\n On UNIX Systems:\n\n ls -ld [pathname]\n\n Substitute [pathname] with the directory paths listed from the above SQL\n statements for log_archive_dest and log_archive_duplex_dest.\n\n If permissions are granted for world access, this is a finding.\n\n On Windows Systems (From Windows Explorer):\n\n Browse to the directory specified.\n\n Select and right-click on the directory, select Properties, select the Security\n tab.\n\n If permissions are granted to everyone, this is a finding.\n\n If any account other than the Oracle process and software owner accounts,\n Administrators, DBAs, System group or developers authorized to write and debug\n applications on this database are listed, this is a finding.\"\n tag \"fix\": \"Specify a valid and protected directory for archive log files.\n\n Restrict access to the Oracle process and software owner accounts, DBAs, and\n backup operator accounts.\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n log_archive_dest = sql.query(\"select value from v$parameter where name = 'log_archive_dest';\").column('value')\n\n describe 'The oracle database log_archive_dest parameter' do\n subject { log_archive_dest }\n it { should_not cmp [' '] }\n end\n\n parameter = sql.query(\"select DISTINCT value from v$parameter where name LIKE 'log_archive_dest_%';\").column('value')\n\n describe 'The oracle database value for log_archive_dest parameter' do\n subject { parameter }\n it { should_not cmp [' '] }\n end\n\n db_recovery_file_dest = sql.query(\"select value from v$parameter where name = 'db_recovery_file_dest';\").column('value').uniq\n\n describe 'The oracle database db_recovery_file_dest parameter' do\n subject { db_recovery_file_dest }\n it { should_not cmp [' '] }\n end\n\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61451.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61463.rb", "line": 1 }, - "id": "V-61451" + "id": "V-61463" }, { - "title": "The DBMS must automatically audit account disabling actions, to the\n extent such information is available.", - "desc": "When application accounts are disabled, user accessibility is\n affected. Accounts are utilized for identifying individual application users or\n for identifying the application processes themselves.\n\n In order to detect and respond to events affecting user accessibility and\n application processing, applications must audit account disabling actions and,\n as required, notify the appropriate individuals so they can investigate the\n event.\n\n Such a capability greatly reduces the risk that application accessibility\n will be negatively affected for extended periods of time and provides logging\n that can be used for forensic purposes.\n\n Note that user authentication and account management should be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP.\n\n However, notwithstanding how accounts are managed, Oracle auditing must\n always be configured to capture account-disabling actions, to the extent such\n information is available.\n\n Note that some Oracle architectural details limit the ability to capture\n this information. There is a difference between actions taken by a user that\n generate an audit record and actions by the database itself, which do not\n generate an audit record. If an account is locked because of an expiration\n event, it is done by the database without involving the action of a user.\n Failed logins are logged user interactions, but the subsequent locking of the\n account, although initiated by user actions, is a function of the database.", + "title": "The DBMS must provide the ability to write specified audit record\n content to a centralized audit log repository.", + "desc": "Information system auditing capability is critical for accurate\n forensic analysis. Audit record content that may be necessary to satisfy the\n requirement of this control includes but is not limited: timestamps, source\n and destination IP addresses, user/process identifiers, event descriptions,\n application specific events, success/fail indications, file names involved,\n access control or flow control rules invoked.\n\n Centralized management of audit records and logs provides for efficiency in\n maintenance and management of records, as well as, the backup and archiving of\n those records. When organizations define application components requiring\n centralized audit log management, applications need to support that requirement.\n\n Database audit records not stored in a centralized audit log management\n tool may be overlooked during investigation of a security incident or may be\n subject to intentional or accidental manipulation by privileged users of the\n database.", "descriptions": { - "default": "When application accounts are disabled, user accessibility is\n affected. Accounts are utilized for identifying individual application users or\n for identifying the application processes themselves.\n\n In order to detect and respond to events affecting user accessibility and\n application processing, applications must audit account disabling actions and,\n as required, notify the appropriate individuals so they can investigate the\n event.\n\n Such a capability greatly reduces the risk that application accessibility\n will be negatively affected for extended periods of time and provides logging\n that can be used for forensic purposes.\n\n Note that user authentication and account management should be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP.\n\n However, notwithstanding how accounts are managed, Oracle auditing must\n always be configured to capture account-disabling actions, to the extent such\n information is available.\n\n Note that some Oracle architectural details limit the ability to capture\n this information. There is a difference between actions taken by a user that\n generate an audit record and actions by the database itself, which do not\n generate an audit record. If an account is locked because of an expiration\n event, it is done by the database without involving the action of a user.\n Failed logins are logged user interactions, but the subsequent locking of the\n account, although initiated by user actions, is a function of the database." + "default": "Information system auditing capability is critical for accurate\n forensic analysis. Audit record content that may be necessary to satisfy the\n requirement of this control includes but is not limited: timestamps, source\n and destination IP addresses, user/process identifiers, event descriptions,\n application specific events, success/fail indications, file names involved,\n access control or flow control rules invoked.\n\n Centralized management of audit records and logs provides for efficiency in\n maintenance and management of records, as well as, the backup and archiving of\n those records. When organizations define application components requiring\n centralized audit log management, applications need to support that requirement.\n\n Database audit records not stored in a centralized audit log management\n tool may be overlooked during investigation of a security incident or may be\n subject to intentional or accidental manipulation by privileged users of the\n database." }, "impact": 0.5, "refs": [], "tags": { - "gtitle": "SRG-APP-000028-DB-000187", - "gid": "V-61571", - "rid": "SV-76061r4_rule", - "stig_id": "O121-C2-002400", - "fix_id": "F-67487r2_fix", + "gtitle": "SRG-APP-000102-DB-000045", + "gid": "V-61871", + "rid": "SV-76361r1_rule", + "stig_id": "O121-P2-008100", + "fix_id": "F-67787r1_fix", "cci": [ - "CCI-001404" + "CCI-001844" ], "nist": [ - "AC-2 (4)", + "AU-3 (2)", "Rev_4" ], "false_negatives": null, @@ -1231,30 +1270,30 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Check Oracle settings (and also OS settings and/or\n enterprise-level authentication/access mechanisms settings) to determine if\n account disabling actions are being audited. If account disabling actions are\n not being audited by Oracle, this is a finding.\n\n If Standard Auditing is used:\n To see if Oracle is configured to capture audit data, enter the following\n SQL*Plus command:\n SHOW PARAMETER AUDIT_TRAIL\n or the following SQL query:\n SELECT * FROM SYS.V$PARAMETER WHERE NAME = 'audit_trail';\n If Oracle returns the value 'NONE', this is a finding.\n\n If Unified Auditing is used:\n To see if Oracle is configured to capture audit data including account\n disabling, enter the following SQL*Plus command:\n SELECT ' Account disabling is not being audited. '\n FROM dual\n WHERE (SELECT Count(*)\n FROM (select policy_name , audit_option from audit_unified_policies\n WHERE audit_option = 'ALTER USER'\n and policy_name in (select policy_name from audit_unified_enabled_policies\n where user_name='ALL USERS'))) = 0\n OR (SELECT value\n FROM v$option\n WHERE parameter = 'Unified Auditing') != 'TRUE';\n\n If Oracle returns \"no rows selected\", this is not a finding.", - "fix": "Configure Oracle to audit account disabling actions.\n\n If Standard Auditing is used:\n Use this process to ensure auditable events are captured:\n ALTER SYSTEM SET AUDIT_TRAIL= SCOPE=SPFILE;\n Audit trail type can be 'OS', 'DB', 'DB,EXTENDED', 'XML' or 'XML,EXTENDED'.\n After executing this statement, it may be necessary to shut down and restart\n the Oracle database.\n\n If Unified Auditing is used:\n To ensure auditable events are captured:\n Link the oracle binary with uniaud_on, and then restart the database. Oracle\n Database Upgrade Guide describes how to enable unified auditing. Reference\n V-61625 for information on how to configure a policy to audit account disabling.\n\n For more information on the configuration of auditing, refer to the following\n documents:\n \"Auditing Database Activity\" in the Oracle Database 2 Day + Security Guide:\n http://docs.oracle.com/database/121/TDPSG/tdpsg_auditing.htm#TDPSG50000\n \"Monitoring Database Activity with Auditing\" in the Oracle Database Security\n Guide:\n http://docs.oracle.com/database/121/DBSEG/part_6.htm#CCHEHCGI\n \"DBMS_AUDIT_MGMT\" in the Oracle Database PL/SQL Packages and Types Reference:\n http://docs.oracle.com/database/121/ARPLS/d_audit_mgmt.htm#ARPLS241\n Oracle Database Upgrade Guide:\n http://docs.oracle.com/database/121/UPGRD/afterup.htm#UPGRD52810" + "check": "If the organization does not require the use of a centralized\n audit log repository, this is not a finding.\n\n If the organization requires the use of a centralized audit log repository,\n continue.\n\n Check that Oracle PL/SQL code or other software is in place to copy or transfer\n the specified audit record content to a centralized audit log repository. If\n it is not, this is a finding.\n\n Check that permissions are set on the Oracle audit trail tables and on the\n target repository to enable the required transfer of audit data. If they are\n not, this is a finding.\n\n Verify that the specified audit record content is indeed copied or transferred\n to the central repository. If it is not, this is a finding.", + "fix": "If the organization requires the use of a centralized audit log\n repository, employ PL/SQL code or other software to copy or transfer the\n specified audit record content to the repository.\n\n Ensure that permissions are set to enable transfer of the data.\n\n If, after the preceding steps, the transfer is not succeeding, diagnose and\n repair the problem.\n\n For more information on the configuration of auditing, refer to the following\n documents:\n \"Auditing Database Activity\" in the Oracle Database 2 Day + Security Guide:\n http://docs.oracle.com/database/121/TDPSG/tdpsg_auditing.htm#TDPSG50000\n \"Monitoring Database Activity with Auditing\" in the Oracle Database Security\n Guide:\n http://docs.oracle.com/database/121/DBSEG/part_6.htm#CCHEHCGI\n \"DBMS_AUDIT_MGMT\" in the Oracle Database PL/SQL Packages and Types Reference:\n http://docs.oracle.com/database/121/ARPLS/d_audit_mgmt.htm#ARPLS241" }, - "code": "control 'V-61571' do\n title \"The DBMS must automatically audit account disabling actions, to the\n extent such information is available.\"\n desc \"When application accounts are disabled, user accessibility is\n affected. Accounts are utilized for identifying individual application users or\n for identifying the application processes themselves.\n\n In order to detect and respond to events affecting user accessibility and\n application processing, applications must audit account disabling actions and,\n as required, notify the appropriate individuals so they can investigate the\n event.\n\n Such a capability greatly reduces the risk that application accessibility\n will be negatively affected for extended periods of time and provides logging\n that can be used for forensic purposes.\n\n Note that user authentication and account management should be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP.\n\n However, notwithstanding how accounts are managed, Oracle auditing must\n always be configured to capture account-disabling actions, to the extent such\n information is available.\n\n Note that some Oracle architectural details limit the ability to capture\n this information. There is a difference between actions taken by a user that\n generate an audit record and actions by the database itself, which do not\n generate an audit record. If an account is locked because of an expiration\n event, it is done by the database without involving the action of a user.\n Failed logins are logged user interactions, but the subsequent locking of the\n account, although initiated by user actions, is a function of the database.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000028-DB-000187'\n tag \"gid\": 'V-61571'\n tag \"rid\": 'SV-76061r4_rule'\n tag \"stig_id\": 'O121-C2-002400'\n tag \"fix_id\": 'F-67487r2_fix'\n tag \"cci\": ['CCI-001404']\n tag \"nist\": ['AC-2 (4)', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Check Oracle settings (and also OS settings and/or\n enterprise-level authentication/access mechanisms settings) to determine if\n account disabling actions are being audited. If account disabling actions are\n not being audited by Oracle, this is a finding.\n\n If Standard Auditing is used:\n To see if Oracle is configured to capture audit data, enter the following\n SQL*Plus command:\n SHOW PARAMETER AUDIT_TRAIL\n or the following SQL query:\n SELECT * FROM SYS.V$PARAMETER WHERE NAME = 'audit_trail';\n If Oracle returns the value 'NONE', this is a finding.\n\n If Unified Auditing is used:\n To see if Oracle is configured to capture audit data including account\n disabling, enter the following SQL*Plus command:\n SELECT ' Account disabling is not being audited. '\n FROM dual\n WHERE (SELECT Count(*)\n FROM (select policy_name , audit_option from audit_unified_policies\n WHERE audit_option = 'ALTER USER'\n and policy_name in (select policy_name from audit_unified_enabled_policies\n where user_name='ALL USERS'))) = 0\n OR (SELECT value\n FROM v$option\n WHERE parameter = 'Unified Auditing') != 'TRUE';\n\n If Oracle returns \\\"no rows selected\\\", this is not a finding.\"\n tag \"fix\": \"Configure Oracle to audit account disabling actions.\n\n If Standard Auditing is used:\n Use this process to ensure auditable events are captured:\n ALTER SYSTEM SET AUDIT_TRAIL= SCOPE=SPFILE;\n Audit trail type can be 'OS', 'DB', 'DB,EXTENDED', 'XML' or 'XML,EXTENDED'.\n After executing this statement, it may be necessary to shut down and restart\n the Oracle database.\n\n If Unified Auditing is used:\n To ensure auditable events are captured:\n Link the oracle binary with uniaud_on, and then restart the database. Oracle\n Database Upgrade Guide describes how to enable unified auditing. Reference\n V-61625 for information on how to configure a policy to audit account disabling.\n\n For more information on the configuration of auditing, refer to the following\n documents:\n \\\"Auditing Database Activity\\\" in the Oracle Database 2 Day + Security Guide:\n http://docs.oracle.com/database/121/TDPSG/tdpsg_auditing.htm#TDPSG50000\n \\\"Monitoring Database Activity with Auditing\\\" in the Oracle Database Security\n Guide:\n http://docs.oracle.com/database/121/DBSEG/part_6.htm#CCHEHCGI\n \\\"DBMS_AUDIT_MGMT\\\" in the Oracle Database PL/SQL Packages and Types Reference:\n http://docs.oracle.com/database/121/ARPLS/d_audit_mgmt.htm#ARPLS241\n Oracle Database Upgrade Guide:\n http://docs.oracle.com/database/121/UPGRD/afterup.htm#UPGRD52810\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n standard_auditing_used = input('standard_auditing_used')\n unified_auditing_used = input('unified_auditing_used')\n\n describe.one do\n describe 'Standard auditing is in use for audit purposes' do\n subject { standard_auditing_used }\n it { should be true }\n end\n\n describe 'Unified auditing is in use for audit purposes' do\n subject { unified_auditing_used }\n it { should be true }\n end\n end\n\n audit_trail = sql.query(\"select value from v$parameter where name = 'audit_trail';\").column('value')\n\n if standard_auditing_used\n describe 'The oracle database audit_trail parameter' do\n subject { audit_trail }\n it { should_not cmp 'NONE' }\n end\n end\n\n unified_auditing = sql.query(\"SELECT value FROM V$OPTION WHERE PARAMETER = 'Unified Auditing';\").column('value')\n\n if unified_auditing_used\n describe 'The oracle database unified auditing parameter' do\n subject { unified_auditing }\n it { should_not cmp 'FALSE' }\n end\n\n unified_auditing_events = sql.query(\"SELECT ' Account disabling is not being audited. '\n FROM dual\n WHERE (SELECT Count(*)\n FROM (select policy_name , audit_option from audit_unified_policies\n WHERE audit_option = 'ALTER USER'\n and policy_name in (select policy_name from audit_unified_enabled_policies\n where user_name='ALL USERS'))) = 0\n OR (SELECT value\n FROM v$option\n WHERE parameter = 'Unified Auditing') != 'TRUE';\").column('Account disabling is not being audited.').uniq\n\n describe 'The unified auditing data capture for account disabling actions' do\n subject { unified_auditing_events.to_s }\n it { should_not cmp '[nil]' }\n end\n end\nend\n", + "code": "control 'V-61871' do\n title \"The DBMS must provide the ability to write specified audit record\n content to a centralized audit log repository.\"\n desc \"Information system auditing capability is critical for accurate\n forensic analysis. Audit record content that may be necessary to satisfy the\n requirement of this control includes but is not limited: timestamps, source\n and destination IP addresses, user/process identifiers, event descriptions,\n application specific events, success/fail indications, file names involved,\n access control or flow control rules invoked.\n\n Centralized management of audit records and logs provides for efficiency in\n maintenance and management of records, as well as, the backup and archiving of\n those records. When organizations define application components requiring\n centralized audit log management, applications need to support that requirement.\n\n Database audit records not stored in a centralized audit log management\n tool may be overlooked during investigation of a security incident or may be\n subject to intentional or accidental manipulation by privileged users of the\n database.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000102-DB-000045'\n tag \"gid\": 'V-61871'\n tag \"rid\": 'SV-76361r1_rule'\n tag \"stig_id\": 'O121-P2-008100'\n tag \"fix_id\": 'F-67787r1_fix'\n tag \"cci\": ['CCI-001844']\n tag \"nist\": ['AU-3 (2)', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"If the organization does not require the use of a centralized\n audit log repository, this is not a finding.\n\n If the organization requires the use of a centralized audit log repository,\n continue.\n\n Check that Oracle PL/SQL code or other software is in place to copy or transfer\n the specified audit record content to a centralized audit log repository. If\n it is not, this is a finding.\n\n Check that permissions are set on the Oracle audit trail tables and on the\n target repository to enable the required transfer of audit data. If they are\n not, this is a finding.\n\n Verify that the specified audit record content is indeed copied or transferred\n to the central repository. If it is not, this is a finding.\"\n tag \"fix\": \"If the organization requires the use of a centralized audit log\n repository, employ PL/SQL code or other software to copy or transfer the\n specified audit record content to the repository.\n\n Ensure that permissions are set to enable transfer of the data.\n\n If, after the preceding steps, the transfer is not succeeding, diagnose and\n repair the problem.\n\n For more information on the configuration of auditing, refer to the following\n documents:\n \\\"Auditing Database Activity\\\" in the Oracle Database 2 Day + Security Guide:\n http://docs.oracle.com/database/121/TDPSG/tdpsg_auditing.htm#TDPSG50000\n \\\"Monitoring Database Activity with Auditing\\\" in the Oracle Database Security\n Guide:\n http://docs.oracle.com/database/121/DBSEG/part_6.htm#CCHEHCGI\n \\\"DBMS_AUDIT_MGMT\\\" in the Oracle Database PL/SQL Packages and Types Reference:\n http://docs.oracle.com/database/121/ARPLS/d_audit_mgmt.htm#ARPLS241\"\n describe 'A manual review is required to ensure the DBMS provides the ability to write specified audit record\n content to a centralized audit log repository' do\n skip 'A manual review is required to ensure the DBMS provides the ability to write specified audit record\n content to a centralized audit log repository'\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61571.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61871.rb", "line": 1 }, - "id": "V-61571" + "id": "V-61871" }, { - "title": "The directories assigned to the LOG_ARCHIVE_DEST* parameters must be\n protected from unauthorized access.", - "desc": "The LOG_ARCHIVE_DEST parameter is used to specify the directory to\n which Oracle archive logs are written. Where the DBMS availability and recovery\n to a specific point in time is critical, the protection of archive log files is\n critical. Archive log files may also contain unencrypted sensitive data. If\n written to an inadequately protected or invalidated directory, the archive log\n files may be accessed by unauthorized persons or processes.", + "title": "Disk space used by audit trail(s) must be monitored; audit records\n must be regularly or continuously off-loaded to a centralized log management\n system.", + "desc": "It is critical when a system is at risk of failing to process audit\n logs as required; it detects and takes action to mitigate the failure. Audit\n processing failures include: software/hardware errors, failures in the audit\n capturing mechanisms, and audit storage capacity being reached or exceeded.\n Applications are required to be capable of either directly performing or\n calling system-level functionality performing defined actions upon detection of\n an application audit log processing failure.\n\n The Security Requirements Guide says, \"A failure of database auditing will\n result in either the database continuing to function without auditing or in a\n complete halt to database operations. The database must be capable of taking\n organization-defined actions to avoid either a complete halt to processing or\n processing transactions in an unaudited manner.\"\n\n This STIG requirement mandates the implementation of a method to mitigate\n Oracle's inability to automatically reuse audit trail space on a first-in,\n first-out basis.", "descriptions": { - "default": "The LOG_ARCHIVE_DEST parameter is used to specify the directory to\n which Oracle archive logs are written. Where the DBMS availability and recovery\n to a specific point in time is critical, the protection of archive log files is\n critical. Archive log files may also contain unencrypted sensitive data. If\n written to an inadequately protected or invalidated directory, the archive log\n files may be accessed by unauthorized persons or processes." + "default": "It is critical when a system is at risk of failing to process audit\n logs as required; it detects and takes action to mitigate the failure. Audit\n processing failures include: software/hardware errors, failures in the audit\n capturing mechanisms, and audit storage capacity being reached or exceeded.\n Applications are required to be capable of either directly performing or\n calling system-level functionality performing defined actions upon detection of\n an application audit log processing failure.\n\n The Security Requirements Guide says, \"A failure of database auditing will\n result in either the database continuing to function without auditing or in a\n complete halt to database operations. The database must be capable of taking\n organization-defined actions to avoid either a complete halt to processing or\n processing transactions in an unaudited manner.\"\n\n This STIG requirement mandates the implementation of a method to mitigate\n Oracle's inability to automatically reuse audit trail space on a first-in,\n first-out basis." }, "impact": 0.5, "refs": [], "tags": { - "gtitle": "SRG-APP-000516-DB-999900", - "gid": "V-61463", - "rid": "SV-75953r1_rule", - "stig_id": "O121-BP-023800", - "fix_id": "F-67379r1_fix", + "gtitle": "SRG-APP-000109-DB-000049", + "gid": "V-61853", + "rid": "SV-76343r1_rule", + "stig_id": "O121-N2-008601", + "fix_id": "F-67769r1_fix", "cci": [ "CCI-000366" ], @@ -1272,35 +1311,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "From SQL*Plus:\n\n select log_mode from v$database;\n select value from v$parameter where name = 'log_archive_dest';\n select value from v$parameter where name = 'log_archive_duplex_dest';\n select name, value from v$parameter where name LIKE 'log_archive_dest_%';\n select value from v$parameter where name = 'db_recovery_file_dest';\n\n If the value returned for LOG_MODE is NOARCHIVELOG, this check is not a finding.\n\n If a value is not returned for LOG_ARCHIVE_DEST and no values are returned for\n any of the LOG_ARCHIVE_DEST_[1-10] parameters, and no value is returned for\n DB_RECOVERY_FILE_DEST, this is a finding.\n\n Note: LOG_ARCHIVE_DEST and LOG_ARCHIVE_DUPLEX_DEST are incompatible with the\n LOG_ARCHIVE_DEST_n parameters, and must be defined as the null string (' ')\n when any LOG_ARCHIVE_DEST_n parameter has a value other than a null string.\n\n On UNIX Systems:\n\n ls -ld [pathname]\n\n Substitute [pathname] with the directory paths listed from the above SQL\n statements for log_archive_dest and log_archive_duplex_dest.\n\n If permissions are granted for world access, this is a finding.\n\n On Windows Systems (From Windows Explorer):\n\n Browse to the directory specified.\n\n Select and right-click on the directory, select Properties, select the Security\n tab.\n\n If permissions are granted to everyone, this is a finding.\n\n If any account other than the Oracle process and software owner accounts,\n Administrators, DBAs, System group or developers authorized to write and debug\n applications on this database are listed, this is a finding.", - "fix": "Specify a valid and protected directory for archive log files.\n\n Restrict access to the Oracle process and software owner accounts, DBAs, and\n backup operator accounts." + "check": "Review the procedures, manual and/or automated, for monitoring\n the space used by audit trail(s) and for off-loading audit records to a\n centralized log management system.\n\n If the procedures do not exist, this is a finding.\n\n If the procedures exist, request evidence that they are followed. If the\n evidence indicates that the procedures are not followed, this is a finding.\n\n If the procedures exist, inquire if the system has ever run out of audit trail\n space in the last two years or since the last system upgrade, whichever is more\n recent. If it has run out of space in this period, and the procedures have not\n been updated to compensate, this is a finding.", + "fix": "Modify DBMS, OS, or third-party logging application settings to\n alert appropriate personnel when a specific percentage of log storage capacity\n is reached.\n\n For ease of management, it is recommended that the audit tables be kept in a\n dedicated tablespace.\n\n If Oracle Enterprise Manager is in use, the capability to issue such an alert\n is built in and configurable via the console so an email can be sent to a\n designated administrator.\n\n If Enterprise Manager is unavailable, the following script can be used to\n monitor storage space; this can be combined with additional code to email the\n appropriate administrator so they can take action.\n\n sqlplus connect as sysdba\n\n set pagesize 300\n set linesize 120\n column sumb format 9,999,999,999,999\n column extents format 999999\n column bytes format 9,999,999,999,999\n column largest format 9,999,999,999,999\n column Tot_Size format 9,999,999,999,999\n column Tot_Free format 9,999,999,999,999\n column Pct_Free format 9,999,999,999,999\n column Chunks_Free format 9,999,999,999,999\n column Max_Free format 9,999,999,999,999\n set echo off\n spool TSINFO.txt\n PROMPT SPACE AVAILABLE IN TABLESPACES\n select a.tablespace_name,sum(a.tots) Tot_Size,\n sum(a.sumb) Tot_Free,\n sum(a.sumb)*100/sum(a.tots) Pct_Free,\n sum(a.largest) Max_Free,sum(a.chunks) Chunks_Free\n from\n (\n select tablespace_name,0 tots,sum(bytes) sumb,\n max(bytes) largest,count(*) chunks\n from dba_free_space a\n group by tablespace_name\n union\n select tablespace_name,sum(bytes) tots,0,0,0 from\n dba_data_files\n group by tablespace_name) a\n group by a.tablespace_name;\n\n Sample Output\n\n SPACE AVAILABLE IN TABLESPACES\n\n TABLESPACE_NAME TOT_SIZE TOT_FREE PCT_FREE\n MAX_FREE CHUNKS_FREE\n ------------------------------ ------------ ------------ ------------\n ------------ ------------\n DES2 41,943,040 30,935,040 74\n 30,935,040 1\n DES2_I 31,457,280 23,396,352 74\n 23,396,352 1\n RBS 60,817,408 57,085,952 94\n 52,426,752 16\n SYSTEM 94,371,840 5,386,240 6\n 5,013,504 3\n TEMP 563,200 561,152 100\n 133,120 5\n TOOLS 120,586,240 89,407,488 74\n 78,190,592 12\n USERS 1,048,576 26,624 3\n 26,624 1" }, - "code": "control 'V-61463' do\n title \"The directories assigned to the LOG_ARCHIVE_DEST* parameters must be\n protected from unauthorized access.\"\n desc \"The LOG_ARCHIVE_DEST parameter is used to specify the directory to\n which Oracle archive logs are written. Where the DBMS availability and recovery\n to a specific point in time is critical, the protection of archive log files is\n critical. Archive log files may also contain unencrypted sensitive data. If\n written to an inadequately protected or invalidated directory, the archive log\n files may be accessed by unauthorized persons or processes.\"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000516-DB-999900'\n tag \"gid\": 'V-61463'\n tag \"rid\": 'SV-75953r1_rule'\n tag \"stig_id\": 'O121-BP-023800'\n tag \"fix_id\": 'F-67379r1_fix'\n tag \"cci\": ['CCI-000366']\n tag \"nist\": ['CM-6 b', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"From SQL*Plus:\n\n select log_mode from v$database;\n select value from v$parameter where name = 'log_archive_dest';\n select value from v$parameter where name = 'log_archive_duplex_dest';\n select name, value from v$parameter where name LIKE 'log_archive_dest_%';\n select value from v$parameter where name = 'db_recovery_file_dest';\n\n If the value returned for LOG_MODE is NOARCHIVELOG, this check is not a finding.\n\n If a value is not returned for LOG_ARCHIVE_DEST and no values are returned for\n any of the LOG_ARCHIVE_DEST_[1-10] parameters, and no value is returned for\n DB_RECOVERY_FILE_DEST, this is a finding.\n\n Note: LOG_ARCHIVE_DEST and LOG_ARCHIVE_DUPLEX_DEST are incompatible with the\n LOG_ARCHIVE_DEST_n parameters, and must be defined as the null string (' ')\n when any LOG_ARCHIVE_DEST_n parameter has a value other than a null string.\n\n On UNIX Systems:\n\n ls -ld [pathname]\n\n Substitute [pathname] with the directory paths listed from the above SQL\n statements for log_archive_dest and log_archive_duplex_dest.\n\n If permissions are granted for world access, this is a finding.\n\n On Windows Systems (From Windows Explorer):\n\n Browse to the directory specified.\n\n Select and right-click on the directory, select Properties, select the Security\n tab.\n\n If permissions are granted to everyone, this is a finding.\n\n If any account other than the Oracle process and software owner accounts,\n Administrators, DBAs, System group or developers authorized to write and debug\n applications on this database are listed, this is a finding.\"\n tag \"fix\": \"Specify a valid and protected directory for archive log files.\n\n Restrict access to the Oracle process and software owner accounts, DBAs, and\n backup operator accounts.\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n log_archive_dest = sql.query(\"select value from v$parameter where name = 'log_archive_dest';\").column('value')\n\n describe 'The oracle database log_archive_dest parameter' do\n subject { log_archive_dest }\n it { should_not cmp [' '] }\n end\n\n parameter = sql.query(\"select DISTINCT value from v$parameter where name LIKE 'log_archive_dest_%';\").column('value')\n\n describe 'The oracle database value for log_archive_dest parameter' do\n subject { parameter }\n it { should_not cmp [' '] }\n end\n\n db_recovery_file_dest = sql.query(\"select value from v$parameter where name = 'db_recovery_file_dest';\").column('value').uniq\n\n describe 'The oracle database db_recovery_file_dest parameter' do\n subject { db_recovery_file_dest }\n it { should_not cmp [' '] }\n end\n\nend\n", + "code": "control 'V-61853' do\n title \"Disk space used by audit trail(s) must be monitored; audit records\n must be regularly or continuously off-loaded to a centralized log management\n system.\"\n desc \"It is critical when a system is at risk of failing to process audit\n logs as required; it detects and takes action to mitigate the failure. Audit\n processing failures include: software/hardware errors, failures in the audit\n capturing mechanisms, and audit storage capacity being reached or exceeded.\n Applications are required to be capable of either directly performing or\n calling system-level functionality performing defined actions upon detection of\n an application audit log processing failure.\n\n The Security Requirements Guide says, \\\"A failure of database auditing will\n result in either the database continuing to function without auditing or in a\n complete halt to database operations. The database must be capable of taking\n organization-defined actions to avoid either a complete halt to processing or\n processing transactions in an unaudited manner.\\\"\n\n This STIG requirement mandates the implementation of a method to mitigate\n Oracle's inability to automatically reuse audit trail space on a first-in,\n first-out basis.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000109-DB-000049'\n tag \"gid\": 'V-61853'\n tag \"rid\": 'SV-76343r1_rule'\n tag \"stig_id\": 'O121-N2-008601'\n tag \"fix_id\": 'F-67769r1_fix'\n tag \"cci\": ['CCI-000366']\n tag \"nist\": ['CM-6 b', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Review the procedures, manual and/or automated, for monitoring\n the space used by audit trail(s) and for off-loading audit records to a\n centralized log management system.\n\n If the procedures do not exist, this is a finding.\n\n If the procedures exist, request evidence that they are followed. If the\n evidence indicates that the procedures are not followed, this is a finding.\n\n If the procedures exist, inquire if the system has ever run out of audit trail\n space in the last two years or since the last system upgrade, whichever is more\n recent. If it has run out of space in this period, and the procedures have not\n been updated to compensate, this is a finding.\"\n tag \"fix\": \"Modify DBMS, OS, or third-party logging application settings to\n alert appropriate personnel when a specific percentage of log storage capacity\n is reached.\n\n For ease of management, it is recommended that the audit tables be kept in a\n dedicated tablespace.\n\n If Oracle Enterprise Manager is in use, the capability to issue such an alert\n is built in and configurable via the console so an email can be sent to a\n designated administrator.\n\n If Enterprise Manager is unavailable, the following script can be used to\n monitor storage space; this can be combined with additional code to email the\n appropriate administrator so they can take action.\n\n sqlplus connect as sysdba\n\n set pagesize 300\n set linesize 120\n column sumb format 9,999,999,999,999\n column extents format 999999\n column bytes format 9,999,999,999,999\n column largest format 9,999,999,999,999\n column Tot_Size format 9,999,999,999,999\n column Tot_Free format 9,999,999,999,999\n column Pct_Free format 9,999,999,999,999\n column Chunks_Free format 9,999,999,999,999\n column Max_Free format 9,999,999,999,999\n set echo off\n spool TSINFO.txt\n PROMPT SPACE AVAILABLE IN TABLESPACES\n select a.tablespace_name,sum(a.tots) Tot_Size,\n sum(a.sumb) Tot_Free,\n sum(a.sumb)*100/sum(a.tots) Pct_Free,\n sum(a.largest) Max_Free,sum(a.chunks) Chunks_Free\n from\n (\n select tablespace_name,0 tots,sum(bytes) sumb,\n max(bytes) largest,count(*) chunks\n from dba_free_space a\n group by tablespace_name\n union\n select tablespace_name,sum(bytes) tots,0,0,0 from\n dba_data_files\n group by tablespace_name) a\n group by a.tablespace_name;\n\n Sample Output\n\n SPACE AVAILABLE IN TABLESPACES\n\n TABLESPACE_NAME TOT_SIZE TOT_FREE PCT_FREE\n MAX_FREE CHUNKS_FREE\n ------------------------------ ------------ ------------ ------------\n ------------ ------------\n DES2 41,943,040 30,935,040 74\n 30,935,040 1\n DES2_I 31,457,280 23,396,352 74\n 23,396,352 1\n RBS 60,817,408 57,085,952 94\n 52,426,752 16\n SYSTEM 94,371,840 5,386,240 6\n 5,013,504 3\n TEMP 563,200 561,152 100\n 133,120 5\n TOOLS 120,586,240 89,407,488 74\n 78,190,592 12\n USERS 1,048,576 26,624 3\n 26,624 1\"\n describe 'A manual review is required to ensure the Disk space used by audit trail(s) is monitored, and that audit records\n are regularly or continuously off-loaded to a centralized log management system' do\n skip 'A manual review is required to ensure the Disk space used by audit trail(s) is monitored, and that audit records\n are regularly or continuously off-loaded to a centralized log management system'\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61463.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61853.rb", "line": 1 }, - "id": "V-61463" + "id": "V-61853" }, { - "title": "DBMS must conduct backups of system-level information per\n organization-defined frequency that is consistent with recovery time and\n recovery point objectives.", - "desc": "Information system backup is a critical step in maintaining data\n assurance and availability.\n\n System-level information includes: system-state information, operating\n system and application software, and licenses.\n\n Backups shall be consistent with organizational recovery time and recovery\n point objectives.\n\n Databases that do not back up information regularly risk the loss of that\n information in the event of a system failure. Most databases contain\n functionality to allow regular backups; it is important that this functionality\n is enabled and configured correctly to prevent data loss.", + "title": "The DBMS must automatically terminate emergency accounts after an\n organization-defined time period for each type of account.", + "desc": "Emergency application accounts are typically created due to an\n unforeseen operational event or could ostensibly be used in the event of a\n vendor support visit where a support representative requires a temporary unique\n account in order to perform diagnostic testing or conduct some other\n support-related activity. When these types of accounts are created, there is a\n risk that the temporary account may remain in place and active after the\n support representative has left.\n\n In the event emergency application accounts are required, the application\n must ensure accounts that are designated as temporary in nature shall\n automatically terminate these accounts after an organization-defined time\n period. Such a process and capability greatly reduces the risk that accounts\n will be misused, hijacked, or application data compromised.\n\n Note that user authentication and account management must be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP. This requirement applies to cases where it is necessary to\n have accounts directly managed by Oracle.\n\n If it is possible for any temporary emergency accounts to be created and\n managed by Oracle, then the DBMS or application must provide or utilize a\n mechanism to automatically terminate such accounts after an\n organization-defined time period.\n\n Emergency database accounts must be automatically terminated after an\n organization-defined time period in order to mitigate the risk of the account\n being misused.", "descriptions": { - "default": "Information system backup is a critical step in maintaining data\n assurance and availability.\n\n System-level information includes: system-state information, operating\n system and application software, and licenses.\n\n Backups shall be consistent with organizational recovery time and recovery\n point objectives.\n\n Databases that do not back up information regularly risk the loss of that\n information in the event of a system failure. Most databases contain\n functionality to allow regular backups; it is important that this functionality\n is enabled and configured correctly to prevent data loss." + "default": "Emergency application accounts are typically created due to an\n unforeseen operational event or could ostensibly be used in the event of a\n vendor support visit where a support representative requires a temporary unique\n account in order to perform diagnostic testing or conduct some other\n support-related activity. When these types of accounts are created, there is a\n risk that the temporary account may remain in place and active after the\n support representative has left.\n\n In the event emergency application accounts are required, the application\n must ensure accounts that are designated as temporary in nature shall\n automatically terminate these accounts after an organization-defined time\n period. Such a process and capability greatly reduces the risk that accounts\n will be misused, hijacked, or application data compromised.\n\n Note that user authentication and account management must be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP. This requirement applies to cases where it is necessary to\n have accounts directly managed by Oracle.\n\n If it is possible for any temporary emergency accounts to be created and\n managed by Oracle, then the DBMS or application must provide or utilize a\n mechanism to automatically terminate such accounts after an\n organization-defined time period.\n\n Emergency database accounts must be automatically terminated after an\n organization-defined time period in order to mitigate the risk of the account\n being misused." }, "impact": 0.5, "refs": [], "tags": { - "gtitle": "SRG-APP-000146-DB-000099", - "gid": "V-61701", - "rid": "SV-76191r1_rule", - "stig_id": "O121-C2-012600", - "fix_id": "F-67617r1_fix", + "gtitle": "SRG-APP-000234-DB-000157", + "gid": "V-61777", + "rid": "SV-76267r1_rule", + "stig_id": "O121-C2-018600", + "fix_id": "F-67693r1_fix", "cci": [ - "CCI-000537" + "CCI-001682" ], "nist": [ - "CP-9 (b)", + "AC-2 (2)", "Rev_4" ], "false_negatives": null, @@ -1313,21 +1352,21 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Review DBMS and OS backup configuration to determine that\n system-level data is backed up in according with organization-defined frequency.\n\n If the system-level data of the DBMS is not backed up to the\n organization-defined frequency, this is a finding.", - "fix": "Utilize DBMS, OS, or third-party product(s) to meet the\n requirement of backing up system data according to the organization-defined\n frequency." + "check": "If the organization has a policy, consistently enforced,\n forbidding the creation of emergency or temporary accounts, this is not a\n finding.\n\n Check DBMS settings, OS settings, and/or enterprise-level authentication/access\n mechanisms settings to determine if emergency accounts are being automatically\n terminated by the system after an organization-defined time period. Check also\n for custom code (scheduled jobs, procedures, triggers, etc.) for achieving\n this.\n\n If emergency accounts are not being terminated after an organization-defined\n time period, this is a finding.", + "fix": "Create a profile specifically for emergency or temporary\n accounts. When creating the accounts, assign them to this profile. Configure\n DBMS, OS, and/or enterprise-level authentication/access mechanisms, or\n implement custom code, to terminate accounts with this profile after an\n organization-defined time period." }, - "code": "control 'V-61701' do\n title \"DBMS must conduct backups of system-level information per\n organization-defined frequency that is consistent with recovery time and\n recovery point objectives.\"\n desc \"Information system backup is a critical step in maintaining data\n assurance and availability.\n\n System-level information includes: system-state information, operating\n system and application software, and licenses.\n\n Backups shall be consistent with organizational recovery time and recovery\n point objectives.\n\n Databases that do not back up information regularly risk the loss of that\n information in the event of a system failure. Most databases contain\n functionality to allow regular backups; it is important that this functionality\n is enabled and configured correctly to prevent data loss.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000146-DB-000099'\n tag \"gid\": 'V-61701'\n tag \"rid\": 'SV-76191r1_rule'\n tag \"stig_id\": 'O121-C2-012600'\n tag \"fix_id\": 'F-67617r1_fix'\n tag \"cci\": ['CCI-000537']\n tag \"nist\": ['CP-9 (b)', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Review DBMS and OS backup configuration to determine that\n system-level data is backed up in according with organization-defined frequency.\n\n If the system-level data of the DBMS is not backed up to the\n organization-defined frequency, this is a finding.\"\n tag \"fix\": \"Utilize DBMS, OS, or third-party product(s) to meet the\n requirement of backing up system data according to the organization-defined\n frequency.\"\n describe 'A manual is required to ensure the DBMS conducts backups of system-level information per\n organization-defined frequency that is consistent with recovery time and\n recovery point objectives' do\n skip 'A manual is required to ensure the DBMS conducts backups of system-level information per\n organization-defined frequency that is consistent with recovery time and\n recovery point objectives'\n end\nend\n", + "code": "control 'V-61777' do\n title \"The DBMS must automatically terminate emergency accounts after an\n organization-defined time period for each type of account.\"\n desc \"Emergency application accounts are typically created due to an\n unforeseen operational event or could ostensibly be used in the event of a\n vendor support visit where a support representative requires a temporary unique\n account in order to perform diagnostic testing or conduct some other\n support-related activity. When these types of accounts are created, there is a\n risk that the temporary account may remain in place and active after the\n support representative has left.\n\n In the event emergency application accounts are required, the application\n must ensure accounts that are designated as temporary in nature shall\n automatically terminate these accounts after an organization-defined time\n period. Such a process and capability greatly reduces the risk that accounts\n will be misused, hijacked, or application data compromised.\n\n Note that user authentication and account management must be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP. This requirement applies to cases where it is necessary to\n have accounts directly managed by Oracle.\n\n If it is possible for any temporary emergency accounts to be created and\n managed by Oracle, then the DBMS or application must provide or utilize a\n mechanism to automatically terminate such accounts after an\n organization-defined time period.\n\n Emergency database accounts must be automatically terminated after an\n organization-defined time period in order to mitigate the risk of the account\n being misused.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000234-DB-000157'\n tag \"gid\": 'V-61777'\n tag \"rid\": 'SV-76267r1_rule'\n tag \"stig_id\": 'O121-C2-018600'\n tag \"fix_id\": 'F-67693r1_fix'\n tag \"cci\": ['CCI-001682']\n tag \"nist\": ['AC-2 (2)', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"If the organization has a policy, consistently enforced,\n forbidding the creation of emergency or temporary accounts, this is not a\n finding.\n\n Check DBMS settings, OS settings, and/or enterprise-level authentication/access\n mechanisms settings to determine if emergency accounts are being automatically\n terminated by the system after an organization-defined time period. Check also\n for custom code (scheduled jobs, procedures, triggers, etc.) for achieving\n this.\n\n If emergency accounts are not being terminated after an organization-defined\n time period, this is a finding.\"\n tag \"fix\": \"Create a profile specifically for emergency or temporary\n accounts. When creating the accounts, assign them to this profile. Configure\n DBMS, OS, and/or enterprise-level authentication/access mechanisms, or\n implement custom code, to terminate accounts with this profile after an\n organization-defined time period.\"\n describe 'A manual review is required to ensure the DBMS automatically terminates emergency accounts after an\n organization-defined time period for each type of account' do\n skip 'A manual review is required to ensure the DBMS automatically terminates emergency accounts after an\n organization-defined time period for each type of account'\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61701.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61777.rb", "line": 1 }, - "id": "V-61701" + "id": "V-61777" }, { - "title": "DBMS passwords must not be stored in compiled, encoded, or encrypted\n batch jobs or compiled, encoded, or encrypted application source code.", - "desc": "Password maximum lifetime is the maximum period of time, (typically\n in days) a user's password may be in effect before the user is forced to change\n it.\n\n Passwords need to be changed at specific policy-based intervals as per\n policy. Any password, no matter how complex, can eventually be cracked.\n\n One method of minimizing this risk is to use complex passwords and\n periodically change them. If the application does not limit the lifetime of\n passwords and force users to change their passwords, there is the risk that the\n system and/or application passwords could be compromised.\n\n The storage of passwords in application source or batch job code that is\n compiled, encoded, or encrypted prevents compliance with password expiration\n and other management requirements, as well as provides another means for\n potential discovery.\n\n This requirement applies equally to those accounts managed by Oracle and\n those managed and authenticated by the OS or an enterprise-wide mechanism.\n\n This requirement should not be construed as prohibiting or discouraging the\n encryption of source code, which remains an advisable precaution.\n\n Transport Layer Security (TLS) is the successor protocol to Secure Sockets\n Layer (SSL). Although the Oracle configuration parameters have names including\n 'SSL', such as SSL_VERSION and SSL_CIPHER_SUITES, they refer to TLS.\n\n This calls for inspection of application source code, which will require\n collaboration with the application developers. It is recognized that in many\n cases, the database administrator (DBA) is organizationally separate from the\n application developers and may have limited, if any, access to source code.\n Nevertheless, protections of this type are so important to the secure operation\n of databases that they must not be ignored. At a minimum, the DBA must attempt\n to obtain assurances from the development organization that this issue has been\n addressed and must document what has been discovered.", + "title": "The DBMS must use multifactor authentication for network access to\n non-privileged accounts.", + "desc": "Multifactor authentication is defined as using two or more factors to\n achieve authentication.\n\n Factors include:\n (i) Something a user knows (e.g., password/PIN);\n (ii) Something a user has (e.g., cryptographic identification device,\n token); or\n (iii) Something a user is (e.g., biometric).\n\n A non-privileged account is defined as an information system account with\n authorizations of a regular or non-privileged user.\n\n Network access is defined as access to an information system by a user (or\n a process acting on behalf of a user) communicating through a network (e.g.,\n local area network, wide area network, Internet).\n\n The lack of multifactor authentication makes it much easier for an attacker\n to gain unauthorized access to a system.\n\n Transport Layer Security (TLS) is the successor protocol to Secure Sockets\n Layer (SSL). Although the Oracle configuration parameters have names including\n 'SSL', such as SSL_VERSION and SSL_CIPHER_SUITES, they refer to TLS.", "descriptions": { - "default": "Password maximum lifetime is the maximum period of time, (typically\n in days) a user's password may be in effect before the user is forced to change\n it.\n\n Passwords need to be changed at specific policy-based intervals as per\n policy. Any password, no matter how complex, can eventually be cracked.\n\n One method of minimizing this risk is to use complex passwords and\n periodically change them. If the application does not limit the lifetime of\n passwords and force users to change their passwords, there is the risk that the\n system and/or application passwords could be compromised.\n\n The storage of passwords in application source or batch job code that is\n compiled, encoded, or encrypted prevents compliance with password expiration\n and other management requirements, as well as provides another means for\n potential discovery.\n\n This requirement applies equally to those accounts managed by Oracle and\n those managed and authenticated by the OS or an enterprise-wide mechanism.\n\n This requirement should not be construed as prohibiting or discouraging the\n encryption of source code, which remains an advisable precaution.\n\n Transport Layer Security (TLS) is the successor protocol to Secure Sockets\n Layer (SSL). Although the Oracle configuration parameters have names including\n 'SSL', such as SSL_VERSION and SSL_CIPHER_SUITES, they refer to TLS.\n\n This calls for inspection of application source code, which will require\n collaboration with the application developers. It is recognized that in many\n cases, the database administrator (DBA) is organizationally separate from the\n application developers and may have limited, if any, access to source code.\n Nevertheless, protections of this type are so important to the secure operation\n of databases that they must not be ignored. At a minimum, the DBA must attempt\n to obtain assurances from the development organization that this issue has been\n addressed and must document what has been discovered." + "default": "Multifactor authentication is defined as using two or more factors to\n achieve authentication.\n\n Factors include:\n (i) Something a user knows (e.g., password/PIN);\n (ii) Something a user has (e.g., cryptographic identification device,\n token); or\n (iii) Something a user is (e.g., biometric).\n\n A non-privileged account is defined as an information system account with\n authorizations of a regular or non-privileged user.\n\n Network access is defined as access to an information system by a user (or\n a process acting on behalf of a user) communicating through a network (e.g.,\n local area network, wide area network, Internet).\n\n The lack of multifactor authentication makes it much easier for an attacker\n to gain unauthorized access to a system.\n\n Transport Layer Security (TLS) is the successor protocol to Secure Sockets\n Layer (SSL). Although the Oracle configuration parameters have names including\n 'SSL', such as SSL_VERSION and SSL_CIPHER_SUITES, they refer to TLS." }, "impact": 0, "refs": [ @@ -1336,16 +1375,16 @@ } ], "tags": { - "gtitle": "SRG-APP-000174-DB-000079", - "gid": "V-61737", - "rid": "SV-76227r3_rule", - "stig_id": "O121-C2-015100", - "fix_id": "F-67653r2_fix", + "gtitle": "SRG-APP-000150-DB-000105", + "gid": "V-61705", + "rid": "SV-76195r2_rule", + "stig_id": "O121-C2-013000", + "fix_id": "F-67621r1_fix", "cci": [ - "CCI-000199" + "CCI-000766" ], "nist": [ - "IA-5 (1) (d)", + "IA-2 (2)", "Rev_4" ], "false_negatives": null, @@ -1358,35 +1397,39 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Review application source code required to be encoded or\n encrypted for database accounts used by applications or batch jobs to access\n the database.\n\n Review source batch job code prior to compiling, encoding, or encrypting for\n database accounts used by applications or the batch jobs themselves to access\n the database.\n\n Determine if the compiled, encoded, or encrypted application source code or\n batch jobs contain passwords used for authentication to the database.\n\n If any of the identified compiled, encoded, or encrypted application source\n code or batch job code do contain passwords used for authentication to the\n database, this is a finding.\n\n - - - - -\n The check would depend on the information provided by the DBA. In a default\n Oracle installation, all passwords are stored in an encrypted manner. Ask the\n DBA if they have created an External Password Store for applications, batch\n jobs, and scripts to use.\n\n Secure External Password Store\n\n Can store password credentials for connecting to databases by using a\n client-side Oracle wallet. An Oracle wallet is a secure software container that\n stores authentication and signing credentials.\n\n This wallet usage can simplify large-scale deployments that rely on password\n credentials for connecting to databases. When this feature is configured,\n application code, batch jobs, and scripts no longer need embedded user names\n and passwords. This reduces risk because the passwords are no longer exposed,\n and password management policies are more easily enforced without changing\n application code whenever user names or passwords change.\n\n The external password store of the wallet is separate from the area where\n public key infrastructure (PKI) credentials are stored. Consequently, cannot\n use Oracle Wallet Manager to manage credentials in the external password store\n of the wallet. Instead, use the command-line utility mkstore to manage these\n credentials.\n\n How Does the External Password Store Work?\n\n Typically, users (and as applications, batch jobs, and scripts) connect to\n databases by using a standard CONNECT statement that specifies a database\n connection string. This string can include a user name and password, and an\n Oracle Net service name identifying the database on an Oracle Database network.\n If the password is omitted, the connection prompts the user for the password.\n\n For example, the service name could be the URL that identifies that database,\n or a TNS alias entered in the tnsnames.ora file in the database. Another\n possibility is a host:port:sid string.\n\n The following examples are standard CONNECT statements that could be used for a\n client that is not configured to use the external password store:\n\n CONNECT salesapp@sales_db.us.example.com\n Enter password: password\n\n CONNECT salesapp@orasales\n Enter password: password\n\n CONNECT salesapp@ourhost37:1527:DB17\n Enter password: password\n\n In these examples, salesapp is the user name, with the unique connection string\n for the database shown as specified in three different ways. Could use its URL\n sales_db.us.example.com, or its TNS alias, orasales, from the tnsnames.ora\n file, or its host:port:sid string.\n\n However, when clients are configured to use the secure external password store,\n applications can connect to a database with the following CONNECT statement\n syntax, without specifying database logon credentials:\n\n CONNECT /@db_connect_string\n\n CONNECT /@db_connect_string AS SYSDBA\n\n CONNECT /@db_connect_string AS SYSOPER\n\n In this specification, db_connect_string is a valid connection string to access\n the intended database, such as the service name, URL, or alias as shown in the\n earlier examples. Each user account must have its own unique connection string;\n cannot create one connection string for multiple users.\n\n In this case, the database credentials, user name and password, are securely\n stored in an Oracle wallet created for this purpose. The autologon feature of\n this wallet is turned on, so the system does not need a password to open the\n wallet. From the wallet, it gets the credentials to access the database for the\n user they represent.", - "fix": "Design DBMS application code and batch job code that is compiled,\n encoded or encrypted, to NOT contain passwords.\n\n - - - - -\n Oracle provides the capability to provide for a secure external password\n facility. Use the Oracle mkstore to create a secure storage area for passwords\n for applications, batch jobs, and scripts to use or deploy a site-authorized\n facility to perform this function.\n\n Check to see what has been stored in the Oracle External Password Store\n\n To view all contents of a client wallet external password store, check specific\n credentials by viewing them. Listing the external password store contents\n provides information can use to decide whether to add or delete credentials\n from the store. To list the contents of the external password store, enter the\n following command at the command line:\n\n $ mkstore -wrl wallet_location -listCredential\n\n For example:\n\n $ mkstore -wrl c:\\oracle\\product\\12.1.0\\db_1\\wallets -listCredential\n\n The wallet_location specifies the path to the directory where the wallet, whose\n external password store contents is to be viewed, is located. This command\n lists all of the credential database service names (aliases) and the\n corresponding user name (schema) for that database. Passwords are not listed.\n\n Configuring Clients to Use the External Password Store\n\n If the client is already configured to use external authentication, such as\n Windows native authentication or Transport Layer Security (TLS), then Oracle\n Database uses that authentication method. The same credentials used for this\n type of authentication are typically also used to log on to the database.\n\n For clients not using such authentication methods or wanting to override them\n for database authentication, can set the SQLNET.WALLET_OVERRIDE parameter in\n sqlnet.ora to TRUE. The default value for SQLNET.WALLET_OVERRIDE is FALSE,\n allowing standard use of authentication credentials as before.\n\n If wanting a client to use the secure external password store feature, then\n perform the following configuration task:\n\n 1. Create a wallet on the client by using the following syntax at the command\n line:\n\n mkstore -wrl wallet_location -create\n\n For example:\n\n mkstore -wrl c:\\oracle\\product\\12.1.0\\db_1\\wallets -create\n Enter password: password\n\n The wallet_location is the path to the directory where the wallet is to be\n created and stored. This command creates an Oracle wallet with the autologon\n feature enabled at the location specified. The autologon feature enables the\n client to access the wallet contents without supplying a password.\n\n The mkstore utility -create option uses password complexity verification.\n\n 2. Create database connection credentials in the wallet by using the following\n syntax at the command line:\n\n mkstore -wrl wallet_location -createCredential db_connect_string username\n Enter password: password\n\n For example:\n\n mkstore -wrl c:\\oracle\\product\\12.1.0\\db_1\\wallets -createCredential\n oracle system\n Enter password: password\n\n In this specification:\n\n The wallet_location is the path to the directory where the wallet was created.\n The db_connect_string used in the CONNECT /@db_connect_string statement must be\n identical to the db_connect_string specified in the -createCredential command.\n\n The db_connect_string is the TNS alias used to specify the database in the\n tnsnames.ora file or any service name used to identify the database on an\n Oracle network. By default, tnsnames.ora is located in the\n $ORACLE_HOME/network/admin directory on UNIX systems and in ORACLE_HOME etwork\\admin on Windows.\n\n The username is the database logon credential. When prompted, enter the\n password for this user.\n\n 3. In the client sqlnet.ora file, enter the WALLET_LOCATION parameter and set\n it to the directory location of the wallet created in Step 1. For example, if\n the wallet was created in\n $ORACLE_HOME/network/admin and Oracle home is set to /private/ora12,\n then need to enter the following into your client sqlnet.ora file:\n\n WALLET_LOCATION =\n (SOURCE =\n (METHOD = FILE)\n (METHOD_DATA =\n (DIRECTORY = /private/ora12/network/admin)\n )\n )\n\n 4. In the client sqlnet.ora file, enter the SQLNET.WALLET_OVERRIDE parameter\n and set it to TRUE as follows:\n\n SQLNET.WALLET_OVERRIDE = TRUE\n\n setting causes all CONNECT /@db_connect_string statements to use the\n information in the wallet at the specified location to authenticate to\n databases.\n\n When external authentication is in use, an authenticated user with such a\n wallet can use the CONNECT /@db_connect_string syntax to access the previously\n specified databases without providing a user name and password. However, if a\n user fails that external authentication, then these connect statements also\n fail.\n\n Below is a sample sqlnet.ora file with the WALLET_LOCATION and the\n SQLNET.WALLET_OVERRIDE parameters set as described in Steps 3 and 4.\n\n Below is a sample SQLNET.ORA File with Wallet Parameters Set\n\n WALLET_LOCATION =\n (SOURCE =\n (METHOD = FILE)\n (METHOD_DATA =\n (DIRECTORY = /private/ora12/network/admin)\n )\n )\n\n SQLNET.WALLET_OVERRIDE = TRUE\n SSL_CLIENT_AUTHENTICATION = FALSE\n SSL_VERSION = 1.2 or 1.1\n\n Note: \"SSL_VERSION = 1.2 or 1.1\" is the actual value, not a suggestion to\n use one or the other.\n\n (Note: this assumes that a single sqlnet.ora file, in the default location, is\n in use. Please see the supplemental file, \"Non-default sqlnet.ora\n configurations.pdf\" for how to find multiple and/or differently-located\n sqlnet.ora files.)" + "check": "Review DBMS settings, OS settings, and/or enterprise-level\n authentication/access mechanism settings to determine whether users logging on\n to non-privileged accounts via a network are required to use multifactor\n authentication.\n\n If users logging on to non-privileged accounts via a network are not required\n to use multifactor authentication, this is a finding.\n\n Use authentication to prove the identities of users who are attempting to log\n on to the database. Authenticating user identity is imperative in distributed\n environments, without which there can be little confidence in network security.\n Passwords are the most common means of authentication. Oracle Database enables\n strong authentication with Oracle authentication adapters that support various\n third-party authentication services, including TLS with digital certificates.\n\n If the $ORACLE_HOME/network/admin/sqlnet.ora contains entries similar to the\n following, TLS is enabled.\n (Note: This assumes that a single sqlnet.ora file, in the default location, is\n in use. Please see the supplemental file \"Non-default sqlnet.ora\n configurations.pdf\" for how to find multiple and/or differently located\n sqlnet.ora files.)\n\n SQLNET.AUTHENTICATION_SERVICES= (BEQ, TCPS)\n SSL_VERSION = 1.2 or 1.1\n SSL_CLIENT_AUTHENTICATION = TRUE\n WALLET_LOCATION =\n (SOURCE =\n (METHOD = FILE)\n (METHOD_DATA =\n (DIRECTORY = /u01/app/oracle/product/12.1.0/dbhome_1/owm/wallets)\n )\n )\n\n SSL_CIPHER_SUITES= (SSL_RSA_WITH_AES_256_CBC_SHA384)\n ADR_BASE = /u01/app/oracle\n\n Note: \"SSL_VERSION = 1.2 or 1.1\" is the actual value, not a suggestion to\n use one or the other.", + "fix": "Configure DBMS, OS and/or enterprise-level authentication/access\n mechanism to require multifactor authentication for network users logging on to\n non-privileged accounts.\n\n If appropriate, enable support for Transport Layer Security (TLS) protocols and\n multifactor authentication through the use of Smart Cards (CAC/PIV)." }, - "code": " control 'V-61737' do\n impact 0.0\n describe 'This control is not applicable on oracle within aws rds, as aws manages the operating system in which the oracle database is running on' do\n skip 'This control is not applicable on oracle within aws rds, as aws manages the operating system in which the oracle database is running on'\n end\n end\n", + "code": " control 'V-61705' do\n impact 0.0\n describe 'This control is not applicable on oracle within aws rds, as aws manages the operating system in which the oracle database is running on' do\n skip 'This control is not applicable on oracle within aws rds, as aws manages the operating system in which the oracle database is running on'\n end\n end\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61737.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61705.rb", "line": 1 }, - "id": "V-61737" + "id": "V-61705" }, { - "title": "All use of privileged accounts must be audited.", - "desc": "This is intended to limit exposure, by making it possible to trace any\n unauthorized access, by a privileged user account or role that has permissions\n on security functions or security-relevant information, to other data or\n functionality.", - "descriptions": { - "default": "This is intended to limit exposure, by making it possible to trace any\n unauthorized access, by a privileged user account or role that has permissions\n on security functions or security-relevant information, to other data or\n functionality." + "title": "The DBMS must support organizational requirements to enforce minimum\n password length.", + "desc": "Password complexity, or strength, is a measure of the effectiveness of\n a password in resisting attempts at guessing and brute-force attacks.\n\n To meet password policy requirements, passwords need to be changed at\n specific policy-based intervals.\n\n If the information system or application allows the user to consecutively\n reuse their password when that password has exceeded its defined lifetime, the\n end result is a password that is not changed as per policy requirements.\n\n Weak passwords are a primary target for attack to gain unauthorized access\n to databases and other systems. Where username/password is used for\n identification and authentication to the database, requiring the use of strong\n passwords can help prevent simple and more sophisticated methods for guessing\n at passwords.\n\n Note that user authentication and account management must be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP. This requirement applies to cases where it is necessary to\n have accounts directly managed by Oracle.", + "descriptions": { + "default": "Password complexity, or strength, is a measure of the effectiveness of\n a password in resisting attempts at guessing and brute-force attacks.\n\n To meet password policy requirements, passwords need to be changed at\n specific policy-based intervals.\n\n If the information system or application allows the user to consecutively\n reuse their password when that password has exceeded its defined lifetime, the\n end result is a password that is not changed as per policy requirements.\n\n Weak passwords are a primary target for attack to gain unauthorized access\n to databases and other systems. Where username/password is used for\n identification and authentication to the database, requiring the use of strong\n passwords can help prevent simple and more sophisticated methods for guessing\n at passwords.\n\n Note that user authentication and account management must be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP. This requirement applies to cases where it is necessary to\n have accounts directly managed by Oracle." }, "impact": 0.5, - "refs": [], + "refs": [ + { + "ref": [] + } + ], "tags": { - "gtitle": "SRG-APP-000063-DB-000018", - "gid": "V-61595", - "rid": "SV-76085r2_rule", - "stig_id": "O121-C2-004200", - "fix_id": "F-67511r1_fix", + "gtitle": "SRG-APP-000164-DB-000082", + "gid": "V-61719", + "rid": "SV-76209r1_rule", + "stig_id": "O121-C2-013900", + "fix_id": "F-67635r1_fix", "cci": [ - "CCI-000366" + "CCI-000205" ], "nist": [ - "CM-6 b", + "IA-5 (1) (a)", "Rev_4" ], "false_negatives": null, @@ -1399,35 +1442,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Review auditing configuration.\n\n If it is possible for a privileged user/role to access non-security functions\n or information without having the action recorded in the audit log, this is a\n finding.\n\n To obtain a list of unified auditing policies that have been defined, run the\n query:\n SELECT unique policy_name from AUDIT_UNIFIED_POLICIES;\n\n To obtain a list of unified auditing policies that have been enabled and the\n users for which it has been enabled, run the query:\n SELECT unique policy_name, user_name from AUDIT_UNIFIED_ENABLED_POLICIES;\n\n Unless otherwise required, verify that user_name is set to 'ALL USERS' to\n insure that the activity of administrative users is being logged.", - "fix": "Configure DBMS auditing so that all use of privileged accounts is\n recorded in the audit log." + "check": "If all user accounts are authenticated by the OS or an\n enterprise-level authentication/access mechanism, and not by Oracle, this is\n not a finding.\n\n For each profile that can be applied to accounts where authentication is under\n Oracle's control, determine the password verification function, if any, that is\n in use:\n\n SELECT * FROM SYS.DBA_PROFILES\n WHERE RESOURCE_NAME = 'PASSWORD_VERIFY_FUNCTION'\n [AND PROFILE NOT IN ()]\n ORDER BY PROFILE;\n\n Bearing in mind that a profile can inherit from another profile, and the root\n profile is called DEFAULT, determine the name of the password verification\n function effective for each profile.\n\n If, for any profile, the function name is null, this is a finding.\n\n For each password verification function, examine its source code.\n\n If it does not enforce the DoD-defined minimum length (15 unless otherwise\n specified), this is a finding.", + "fix": "If all user accounts are authenticated by the OS or an\n enterprise-level authentication/access mechanism, and not by Oracle, no fix to\n the DBMS is required.\n\n If any user accounts are managed by Oracle: Develop, test and implement a\n password verification function that enforces DoD requirements.\n\n (Oracle supplies a sample function called ORA12C_STRONG_VERIFY_FUNCTION, in the\n script file\n /RDBMS/ADMIN/utlpwdmg.sql. This can be used as the starting point\n for a customized function.)" }, - "code": "control 'V-61595' do\n title 'All use of privileged accounts must be audited.'\n desc \"This is intended to limit exposure, by making it possible to trace any\n unauthorized access, by a privileged user account or role that has permissions\n on security functions or security-relevant information, to other data or\n functionality.\"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000063-DB-000018'\n tag \"gid\": 'V-61595'\n tag \"rid\": 'SV-76085r2_rule'\n tag \"stig_id\": 'O121-C2-004200'\n tag \"fix_id\": 'F-67511r1_fix'\n tag \"cci\": ['CCI-000366']\n tag \"nist\": ['CM-6 b', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Review auditing configuration.\n\n If it is possible for a privileged user/role to access non-security functions\n or information without having the action recorded in the audit log, this is a\n finding.\n\n To obtain a list of unified auditing policies that have been defined, run the\n query:\n SELECT unique policy_name from AUDIT_UNIFIED_POLICIES;\n\n To obtain a list of unified auditing policies that have been enabled and the\n users for which it has been enabled, run the query:\n SELECT unique policy_name, user_name from AUDIT_UNIFIED_ENABLED_POLICIES;\n\n Unless otherwise required, verify that user_name is set to 'ALL USERS' to\n insure that the activity of administrative users is being logged.\"\n tag \"fix\": \"Configure DBMS auditing so that all use of privileged accounts is\n recorded in the audit log.\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n unified_auditing_policies_defined = sql.query('SELECT unique policy_name from AUDIT_UNIFIED_POLICIES;').column('policy_name')\n\n describe 'The list of unified auditing policies defined' do\n subject { unified_auditing_policies_defined }\n it { should_not be_empty }\n end\n\n users_being_audited = sql.query('SELECT unique user_name from AUDIT_UNIFIED_ENABLED_POLICIES;').column('user_name')\n\n describe 'The list of users being audited' do\n subject { users_being_audited }\n it { should include 'ALL USERS' }\n end\nend\n", + "code": "control 'V-61719' do\n title \"The DBMS must support organizational requirements to enforce minimum\n password length.\"\n desc \"Password complexity, or strength, is a measure of the effectiveness of\n a password in resisting attempts at guessing and brute-force attacks.\n\n To meet password policy requirements, passwords need to be changed at\n specific policy-based intervals.\n\n If the information system or application allows the user to consecutively\n reuse their password when that password has exceeded its defined lifetime, the\n end result is a password that is not changed as per policy requirements.\n\n Weak passwords are a primary target for attack to gain unauthorized access\n to databases and other systems. Where username/password is used for\n identification and authentication to the database, requiring the use of strong\n passwords can help prevent simple and more sophisticated methods for guessing\n at passwords.\n\n Note that user authentication and account management must be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP. This requirement applies to cases where it is necessary to\n have accounts directly managed by Oracle.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000164-DB-000082'\n tag \"gid\": 'V-61719'\n tag \"rid\": 'SV-76209r1_rule'\n tag \"stig_id\": 'O121-C2-013900'\n tag \"fix_id\": 'F-67635r1_fix'\n tag \"cci\": ['CCI-000205']\n tag \"nist\": ['IA-5 (1) (a)', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"If all user accounts are authenticated by the OS or an\n enterprise-level authentication/access mechanism, and not by Oracle, this is\n not a finding.\n\n For each profile that can be applied to accounts where authentication is under\n Oracle's control, determine the password verification function, if any, that is\n in use:\n\n SELECT * FROM SYS.DBA_PROFILES\n WHERE RESOURCE_NAME = 'PASSWORD_VERIFY_FUNCTION'\n [AND PROFILE NOT IN ()]\n ORDER BY PROFILE;\n\n Bearing in mind that a profile can inherit from another profile, and the root\n profile is called DEFAULT, determine the name of the password verification\n function effective for each profile.\n\n If, for any profile, the function name is null, this is a finding.\n\n For each password verification function, examine its source code.\n\n If it does not enforce the DoD-defined minimum length (15 unless otherwise\n specified), this is a finding.\"\n tag \"fix\": \"If all user accounts are authenticated by the OS or an\n enterprise-level authentication/access mechanism, and not by Oracle, no fix to\n the DBMS is required.\n\n If any user accounts are managed by Oracle: Develop, test and implement a\n password verification function that enforces DoD requirements.\n\n (Oracle supplies a sample function called ORA12C_STRONG_VERIFY_FUNCTION, in the\n script file\n /RDBMS/ADMIN/utlpwdmg.sql. This can be used as the starting point\n for a customized function.)\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n query = %{\n SELECT PROFILE, RESOURCE_NAME, LIMIT FROM DBA_PROFILES WHERE PROFILE =\n '%s' AND RESOURCE_NAME = 'PASSWORD_VERIFY_FUNCTION'\n }\n\n user_profiles = sql.query('SELECT profile FROM dba_users;').column('profile').uniq\n\n user_profiles.each do |profile|\n next if profile == \"RDSADMIN\"\n password_verify_function = sql.query(format(query, profile: profile)).column('limit')\n\n describe \"The oracle database account password verify function for profile: #{profile}\" do\n subject { password_verify_function }\n it { should_not eq ['NULL'] }\n end\n end\n if user_profiles.empty?\n describe 'There are no user profiles, therefore this control is NA' do\n skip 'There are no user profiles, therefore this control is NA'\n end\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61595.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61719.rb", "line": 1 }, - "id": "V-61595" + "id": "V-61719" }, { - "title": "DBMS production application and data directories must be protected\n from developers on shared production/development DBMS host systems.", - "desc": "Developer roles must not be assigned DBMS administrative privileges to\n production DBMS application and data directories. The separation of production\n DBA and developer roles helps protect the production system from unauthorized,\n malicious or unintentional interruption due to development activities.", + "title": "Unused database components that are integrated in the DBMS and cannot\n be uninstalled must be disabled.", + "desc": "Information systems are capable of providing a wide variety of\n functions and services. Some of the functions and services, provided by\n default, may not be necessary to support essential organizational operations\n (e.g., key missions, functions).\n\n It is detrimental for applications to provide, or install by default,\n functionality exceeding requirements or mission objectives. Examples include,\n but are not limited to, installing advertising software, demonstrations, or\n browser plug-ins not related to requirements or providing a wide array of\n functionality not required for the mission.\n\n Applications must adhere to the principles of least functionality by\n providing only essential capabilities.\n\n Unused, unnecessary DBMS components increase the attack vector for the DBMS\n by introducing additional targets for attack. By minimizing the services and\n applications installed on the system, the number of potential vulnerabilities\n is reduced. Components of the system that are unused and cannot be uninstalled\n must be disabled.", "descriptions": { - "default": "Developer roles must not be assigned DBMS administrative privileges to\n production DBMS application and data directories. The separation of production\n DBA and developer roles helps protect the production system from unauthorized,\n malicious or unintentional interruption due to development activities." + "default": "Information systems are capable of providing a wide variety of\n functions and services. Some of the functions and services, provided by\n default, may not be necessary to support essential organizational operations\n (e.g., key missions, functions).\n\n It is detrimental for applications to provide, or install by default,\n functionality exceeding requirements or mission objectives. Examples include,\n but are not limited to, installing advertising software, demonstrations, or\n browser plug-ins not related to requirements or providing a wide array of\n functionality not required for the mission.\n\n Applications must adhere to the principles of least functionality by\n providing only essential capabilities.\n\n Unused, unnecessary DBMS components increase the attack vector for the DBMS\n by introducing additional targets for attack. By minimizing the services and\n applications installed on the system, the number of potential vulnerabilities\n is reduced. Components of the system that are unused and cannot be uninstalled\n must be disabled." }, - "impact": 0.5, + "impact": 0, "refs": [], "tags": { - "gtitle": "SRG-APP-000516-DB-999900", - "gid": "V-61487", - "rid": "SV-75977r1_rule", - "stig_id": "O121-BP-024100", - "fix_id": "F-67403r1_fix", + "gtitle": "SRG-APP-000141-DB-000092", + "gid": "V-61681", + "rid": "SV-76171r2_rule", + "stig_id": "O121-C2-011700", + "fix_id": "F-67595r3_fix", "cci": [ - "CCI-000366" + "CCI-000381" ], "nist": [ - "CM-6 b", + "CM-7 a", "Rev_4" ], "false_negatives": null, @@ -1440,30 +1483,34 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "If the DBMS or DBMS host is not shared by production and\n development activities, this check is not a finding.\n\n Review OS DBA group membership.\n\n If any developer accounts, as identified in the System Security Plan, have been\n assigned DBA privileges, this is a finding.\n\n Note: Though shared production/non-production DBMS installations was allowed\n under previous database STIG guidance, doing so may place it in violation of\n OS, Application, Network or Enclave STIG guidance. Ensure that any shared\n production/non-production DBMS installation meets STIG guidance requirements at\n all levels or mitigate any conflicts in STIG guidance with the AO.", - "fix": "Create separate DBMS host OS groups for developer and production\n DBAs.\n\n Do not assign production DBA OS group membership to accounts used for\n development.\n\n Remove development accounts from production DBA OS group membership.\n\n Recommend establishing a dedicated DBMS host for production DBMS installations.\n A dedicated host system in this case refers to an instance of the operating\n system at a minimum. The operating system may reside on a virtual host machine\n where supported by the DBMS vendor." + "check": "Run this query to check to see what integrated components are\n installed in the database:\n\n SELECT parameter, value\n from v$option\n where parameter in\n (\n 'Data Mining',\n 'Oracle Database Extensions for .NET',\n 'OLAP',\n 'Partitioning',\n 'Real Application Testing'\n );\n\n This will return all of the relevant database options and their status. TRUE\n means that the option is installed. If the option is not installed, the option\n will be set to FALSE.\n\n Review the options and check the system documentation to see what is required.\n If all listed components are authorized to be in use, this is not a finding.\n\n If any unused components or features are listed by the query as TRUE, this is a\n finding.", + "fix": "In the system documentation list the integrated components\n required for operation of applications that will be accessing the DBMS.\n\n For Oracle Database 12.1, only the following components can be enabled/disabled:\n\n Oracle Data Mining (dm)\n Oracle Database Extensions for .NET (ode_net)\n Oracle OLAP (olap)\n Oracle Partitioning (partitioning)\n Real Application Testing (rat)\n\n Use the chopt utility (an Oracle-supplied operating system command that resides\n in the /bin directory) to disable each option that should not\n be available. The command format is\n\n chopt