From 898c3e68f30dab66bfc12e2b355cff85e206b6ff Mon Sep 17 00:00:00 2001 From: MITRE SAF Date: Thu, 11 Jul 2024 00:06:09 +0000 Subject: [PATCH] Automated ingestion of profiles Signed-off-by: MITRE SAF --- ...rds-oracle-database-12c-stig-baseline.json | 7428 ++++---- ...onical-ubuntu-16.04-lts-stig-baseline.json | 9646 +++++----- ...onical-ubuntu-20.04-lts-stig-baseline.json | 6710 +++---- ...crunchy-data-postgresql-stig-baseline.json | 3942 ++-- ...ql-server-2014-database-stig-baseline.json | 1412 +- ...ql-server-2014-instance-stig-baseline.json | 3156 ++-- .../microsoft-windows-10-stig-baseline.json | 10460 +++++------ ...oft-windows-server-2016-stig-baseline.json | 10642 +++++------ ...oft-windows-server-2019-stig-baseline.json | 11452 ++++++------ ...b-enterprise-advanced-3-stig-baseline.json | 1826 +- .../data/baselineProfiles/nginx-baseline.json | 1276 +- .../nginx-stigready-baseline.json | 3134 ++-- .../oracle-database-12c-stig-baseline.json | 6810 +++---- ...time-environment-7-unix-stig-baseline.json | 292 +- ...time-environment-8-unix-stig-baseline.json | 510 +- .../oracle-mysql-ee-5.7-cis-baseline.json | 1680 +- .../baselineProfiles/pgstigcheck-inspec.json | 3902 ++-- ...dhat-enterprise-linux-6-stig-baseline.json | 9088 +++++----- ...dhat-enterprise-linux-7-stig-baseline.json | 11674 ++++++------ ...dhat-enterprise-linux-8-stig-baseline.json | 15066 ++++++++-------- ...pplication-platform-6.3-stig-baseline.json | 2250 +-- ...security-configuration-guide-baseline.json | 166 +- 22 files changed, 61261 insertions(+), 61261 deletions(-) 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 501f01ef..25626b5b 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,28 @@ "supports": [], "controls": [ { - "title": "Database backup procedures must be defined, documented, and\n implemented.", - "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 Database backups provide the required means to restore databases after\n compromise or loss. Backups help reduce the vulnerability to unauthorized\n access or hardware loss.", + "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.", "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 Database backups provide the required means to restore databases after\n compromise or loss. Backups help reduce the vulnerability to unauthorized\n access or hardware loss." + "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." }, - "impact": 0.5, - "refs": [], + "impact": 0, + "refs": [ + { + "ref": [] + } + ], "tags": { - "gtitle": "SRG-APP-000145-DB-000096", - "gid": "V-61695", - "rid": "SV-76185r1_rule", - "stig_id": "O121-C2-012300", - "fix_id": "F-67611r1_fix", + "gtitle": "SRG-APP-000516-DB-999900", + "gid": "V-61533", + "rid": "SV-76023r1_rule", + "stig_id": "O121-BP-026500", + "fix_id": "F-67449r1_fix", "cci": [ - "CCI-000535" + "CCI-000366" ], "nist": [ - "CP-9 (a)", + "CM-6 b", "Rev_4" ], "false_negatives": null, @@ -50,39 +54,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Review the database backup procedures and implementation\n evidence. Evidence of implementation includes records of backup events and\n physical review of backup media.\n\n Evidence should match the backup plan as recorded in the system documentation.\n\n If backup procedures do not exist or are not implemented in accordance with the\n procedures, this is a finding.\n\n - - - - -\n The Oracle recommended process for backup and recovery is Oracle RMAN. If\n Oracle RMAN is deployed, execute the following commands to ensure that the\n evidence of the implementation of the backup policy includes validating that\n the files are restorable:\n\n Validating Database Files with BACKUP VALIDATE\n --Use the BACKUP VALIDATE command to do the following:\n --Check datafiles for physical and logical block corruption\n --Confirm that all database files exist and are in the correct locations\n --When BACKUP VALIDATE is run, RMAN reads the files to be backed up in their\n entirety, as it would during a real backup. RMAN does not, however, actually\n produce any backup sets or image copies.\n --Cannot use the BACKUPSET, MAXCORRUPT, or PROXY parameters with BACKUP\n VALIDATE.\n --To validate files with the BACKUP VALIDATE command:\n 1. Start RMAN and connect to a target database and recovery catalog (if used).\n 2. Run the BACKUP VALIDATE command.\n\n For example, can validate that all database files and archived logs can be\n backed up by running a command as shown in the following example. This command\n checks for physical corruptions only.\n\n BACKUP VALIDATE\n DATABASE\n ARCHIVELOG ALL;\n\n To check for logical corruptions in addition to physical corruptions, run the\n following variation of the preceding command:\n\n BACKUP VALIDATE\n CHECK LOGICAL\n DATABASE\n ARCHIVELOG ALL;\n\n In the preceding examples, the RMAN client displays the same output that it\n would if it were really backing up the files. If RMAN cannot back up one or\n more of the files, then it issues an error message.\n\n Validating Backups Before Restoring Them\n\n Run RESTORE ... VALIDATE to test whether RMAN can restore a specific file or\n set of files from a backup. RMAN chooses which backups to use. The database\n must be mounted or open for this command. Do not have to take datafiles\n off-line when validating the restore of datafiles, because validation of\n backups of the datafiles only reads the backups and does not affect the\n production datafiles. When validating files on disk or tape, RMAN reads all\n blocks in the backup piece or image copy. RMAN also validates off-site backups.\n The validation is identical to a real restore operation except that RMAN does\n not write output files.\n\n To validate backups with the RESTORE command:\n 1. Run the RESTORE command with the VALIDATE option.\n\n This following example illustrates validating the restore of the database and\n all archived redo logs:\n\n RESTORE DATABASE VALIDATE;\n RESTORE ARCHIVELOG ALL VALIDATE;\n\n If an RMAN error stack is not generated, then skip the subsequent steps. The\n lack of error messages means that RMAN had confirmed that it can use these\n backups successfully during a real restore and recovery.\n\n 2. If error messages are seen in the output and one is the RMAN-06026 message,\n then investigate the cause of the problem. If possible, correct the problem\n that is preventing RMAN from validating the backups and retry the validation.\n The following error means that RMAN cannot restore one or more of the specified\n files from available backups:\n\n RMAN-06026: some targets not found - aborting restore\n The following sample output shows that RMAN encountered a problem reading the\n specified backup:\n\n RMAN-03009: failure of restore command on c1 channel at 12-DEC-14 23:22:30\n ORA-19505: failed to identify file \"oracle/dbs/1fafv9gl_1_1\"\n ORA-27037: unable to obtain file status\n SVR4 Error: 2: No such file or directory\n Additional information: 3", - "fix": "Develop, document, and implement database backup procedures." + "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" }, - "code": "control 'V-61695' do\n title \"Database backup procedures must be defined, documented, and\n implemented.\"\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 Database backups provide the required means to restore databases after\n compromise or loss. Backups help reduce the vulnerability to unauthorized\n access or hardware loss.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000145-DB-000096'\n tag \"gid\": 'V-61695'\n tag \"rid\": 'SV-76185r1_rule'\n tag \"stig_id\": 'O121-C2-012300'\n tag \"fix_id\": 'F-67611r1_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 the database backup procedures and implementation\n evidence. Evidence of implementation includes records of backup events and\n physical review of backup media.\n\n Evidence should match the backup plan as recorded in the system documentation.\n\n If backup procedures do not exist or are not implemented in accordance with the\n procedures, this is a finding.\n\n - - - - -\n The Oracle recommended process for backup and recovery is Oracle RMAN. If\n Oracle RMAN is deployed, execute the following commands to ensure that the\n evidence of the implementation of the backup policy includes validating that\n the files are restorable:\n\n Validating Database Files with BACKUP VALIDATE\n --Use the BACKUP VALIDATE command to do the following:\n --Check datafiles for physical and logical block corruption\n --Confirm that all database files exist and are in the correct locations\n --When BACKUP VALIDATE is run, RMAN reads the files to be backed up in their\n entirety, as it would during a real backup. RMAN does not, however, actually\n produce any backup sets or image copies.\n --Cannot use the BACKUPSET, MAXCORRUPT, or PROXY parameters with BACKUP\n VALIDATE.\n --To validate files with the BACKUP VALIDATE command:\n 1. Start RMAN and connect to a target database and recovery catalog (if used).\n 2. Run the BACKUP VALIDATE command.\n\n For example, can validate that all database files and archived logs can be\n backed up by running a command as shown in the following example. This command\n checks for physical corruptions only.\n\n BACKUP VALIDATE\n DATABASE\n ARCHIVELOG ALL;\n\n To check for logical corruptions in addition to physical corruptions, run the\n following variation of the preceding command:\n\n BACKUP VALIDATE\n CHECK LOGICAL\n DATABASE\n ARCHIVELOG ALL;\n\n In the preceding examples, the RMAN client displays the same output that it\n would if it were really backing up the files. If RMAN cannot back up one or\n more of the files, then it issues an error message.\n\n Validating Backups Before Restoring Them\n\n Run RESTORE ... VALIDATE to test whether RMAN can restore a specific file or\n set of files from a backup. RMAN chooses which backups to use. The database\n must be mounted or open for this command. Do not have to take datafiles\n off-line when validating the restore of datafiles, because validation of\n backups of the datafiles only reads the backups and does not affect the\n production datafiles. When validating files on disk or tape, RMAN reads all\n blocks in the backup piece or image copy. RMAN also validates off-site backups.\n The validation is identical to a real restore operation except that RMAN does\n not write output files.\n\n To validate backups with the RESTORE command:\n 1. Run the RESTORE command with the VALIDATE option.\n\n This following example illustrates validating the restore of the database and\n all archived redo logs:\n\n RESTORE DATABASE VALIDATE;\n RESTORE ARCHIVELOG ALL VALIDATE;\n\n If an RMAN error stack is not generated, then skip the subsequent steps. The\n lack of error messages means that RMAN had confirmed that it can use these\n backups successfully during a real restore and recovery.\n\n 2. If error messages are seen in the output and one is the RMAN-06026 message,\n then investigate the cause of the problem. If possible, correct the problem\n that is preventing RMAN from validating the backups and retry the validation.\n The following error means that RMAN cannot restore one or more of the specified\n files from available backups:\n\n RMAN-06026: some targets not found - aborting restore\n The following sample output shows that RMAN encountered a problem reading the\n specified backup:\n\n RMAN-03009: failure of restore command on c1 channel at 12-DEC-14 23:22:30\n ORA-19505: failed to identify file \\\"oracle/dbs/1fafv9gl_1_1\\\"\n ORA-27037: unable to obtain file status\n SVR4 Error: 2: No such file or directory\n Additional information: 3\"\n tag \"fix\": 'Develop, document, and implement database backup procedures.'\n describe 'A manual review is required to ensure database backup procedures are defined, documented, and\n implemented.' do\n skip 'A manual review is required to ensure database backup procedures are defined, documented, and\n implemented.'\n end\nend\n", + "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", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61695.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61533.rb", "line": 1 }, - "id": "V-61695" + "id": "V-61533" }, { - "title": "The DBMS must map the authenticated identity to the user account using\n PKI-based authentication.", - "desc": "The cornerstone of the PKI is the private key used to encrypt or\n digitally sign information. The key by itself is a cryptographic value that\n does not contain specific user information.\n\n When including the DBMS in the Private Key Infrastructure, the\n authenticated user must map directly to a user account in the DBMS. If the user\n account is not directly tied to the authenticated identity, there is no way to\n know which, if any, database user account has been authorized.\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": "Oracle instance names must not contain Oracle version numbers.", + "desc": "Service names may be discovered by unauthenticated users. If the\n service name includes version numbers or other database product information, a\n malicious user may use that information to develop a targeted attack.", "descriptions": { - "default": "The cornerstone of the PKI is the private key used to encrypt or\n digitally sign information. The key by itself is a cryptographic value that\n does not contain specific user information.\n\n When including the DBMS in the Private Key Infrastructure, the\n authenticated user must map directly to a user account in the DBMS. If the user\n account is not directly tied to the authenticated identity, there is no way to\n know which, if any, database user account has been authorized.\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": "Service names may be discovered by unauthenticated users. If the\n service name includes version numbers or other database product information, a\n malicious user may use that information to develop a targeted attack." }, - "impact": 0, - "refs": [ - { - "ref": [] - } - ], + "impact": 0.5, + "refs": [], "tags": { - "gtitle": "SRG-APP-000177-DB-000069", - "gid": "V-61743", - "rid": "SV-76233r2_rule", - "stig_id": "O121-C2-015500", - "fix_id": "F-67659r1_fix", + "gtitle": "SRG-APP-000516-DB-999900", + "gid": "V-61413", + "rid": "SV-75903r1_rule", + "stig_id": "O121-BP-021300", + "fix_id": "F-67329r1_fix", "cci": [ - "CCI-000187" + "CCI-000366" ], "nist": [ - "IA-5 (2) (c)", + "CM-6 b", "Rev_4" ], "false_negatives": null, @@ -95,39 +95,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Review DBMS configuration to verify DBMS user accounts are\n being mapped directly to authenticated identity information being passed via\n the PKI.\n\n If user accounts are not being mapped to authenticated identity information\n being passed via the PKI, this is 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. Security\n administrators use Oracle Wallet Manager to manage security credentials on the\n server.\n\n If the $ORACLE_HOME/network/admin/sqlnet.ora contains the following entries,\n TLS is installed. (Note: This assumes that a single sqlnet.ora file, in the\n 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 WALLET_LOCATION = (SOURCE=\n (METHOD = FILE)\n (METHOD_DATA =\n DIRECTORY=/wallet)\n\n SSL_CIPHER_SUITES=(SSL_cipher_suiteExample)\n SSL_VERSION = 1.2 or 1.1\n SSL_CLIENT_AUTHENTICATION=FALSE/TRUE\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 the DBMS to map the authenticated identity directly to\n the DBMS user account." + "check": "From SQL*Plus:\n\n select instance_name from v$instance;\n select version from v$instance;\n\n If the instance name returned references the Oracle release number, this is a\n finding.\n\n Numbers used that include version numbers by coincidence are not a finding.\n\n The DBA should be able to relate the significance of the presence of a digit in\n the SID.", + "fix": "Follow the instructions in Oracle MetaLink Note 15390.1 (and\n related documents) to change the SID for the database without re-creating the\n database to a value that does not identify the Oracle version." }, - "code": " control 'V-61743' 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-61413' do\n title 'Oracle instance names must not contain Oracle version numbers.'\n desc \"Service names may be discovered by unauthenticated users. If the\n service name includes version numbers or other database product information, a\n malicious user may use that information to develop a targeted attack.\"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000516-DB-999900'\n tag \"gid\": 'V-61413'\n tag \"rid\": 'SV-75903r1_rule'\n tag \"stig_id\": 'O121-BP-021300'\n tag \"fix_id\": 'F-67329r1_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 instance_name from v$instance;\n select version from v$instance;\n\n If the instance name returned references the Oracle release number, this is a\n finding.\n\n Numbers used that include version numbers by coincidence are not a finding.\n\n The DBA should be able to relate the significance of the presence of a digit in\n the SID.\"\n tag \"fix\": \"Follow the instructions in Oracle MetaLink Note 15390.1 (and\n related documents) to change the SID for the database without re-creating the\n database to a value that does not identify the Oracle version.\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n version = sql.query('select version from v$instance;').column('version')\n db_instance_name = sql.query('select instance_name from v$instance;').column('instance_name')\n\n describe 'The oracle database instance name' do\n subject { db_instance_name }\n it { should_not include version.to_s }\n end\n\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61743.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61413.rb", "line": 1 }, - "id": "V-61743" + "id": "V-61413" }, { - "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": "Oracle roles granted using the WITH ADMIN OPTION must not be granted\n to unauthorized accounts.", + "desc": "The WITH ADMIN OPTION allows the grantee to grant a role to another\n database account. Best security practice restricts the privilege of assigning\n privileges to authorized personnel. Authorized personnel include DBAs, object\n owners, and, where designed and included in the application's functions,\n application administrators. Restricting privilege-granting functions to\n authorized accounts can help decrease mismanagement of privileges and wrongful\n assignments to unauthorized accounts.", "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": "The WITH ADMIN OPTION allows the grantee to grant a role to another\n database account. Best security practice restricts the privilege of assigning\n privileges to authorized personnel. Authorized personnel include DBAs, object\n owners, and, where designed and included in the application's functions,\n application administrators. Restricting privilege-granting functions to\n authorized accounts can help decrease mismanagement of privileges and wrongful\n assignments to unauthorized accounts." }, "impact": 0, - "refs": [ - { - "ref": [] - } - ], + "refs": [], "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-000516-DB-999900", + "gid": "V-61437", + "rid": "SV-75927r3_rule", + "stig_id": "O121-BP-022500", + "fix_id": "F-67353r2_fix", "cci": [ - "CCI-000199" + "CCI-000366" ], "nist": [ - "IA-5 (1) (d)", + "CM-6 b", "Rev_4" ], "false_negatives": null, @@ -140,21 +136,21 @@ "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": "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\n\n * Subject to change based on version installed\n\n Run the SQL statement:\n\n select grantee||': '||granted_role from dba_role_privs\n where admin_option = 'YES' and grantee not in\n (select distinct owner from dba_objects)\n and grantee not in\n (select grantee from dba_role_privs\n where granted_role = 'DBA')\n order by grantee;\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 Review the System Security Plan to confirm any grantees listed are\n ISSO-authorized DBA accounts or application administration roles.\n\n If any grantees listed are not authorized and documented, this is a finding.", + "fix": "Revoke assignment of roles with the WITH ADMIN OPTION from\n unauthorized grantees and re-grant them without the option if required.\n\n SQL statements to remove the admin option from an unauthorized grantee:\n revoke from ;\n grant to ;\n\n Restrict use of the WITH ADMIN OPTION to authorized administrators.\n\n Document authorized role assignments with the WITH ADMIN OPTION in the System\n Security Plan." }, - "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-61437' do\n title \"Oracle roles granted using the WITH ADMIN OPTION must not be granted\n to unauthorized accounts.\"\n desc \"The WITH ADMIN OPTION allows the grantee to grant a role to another\n database account. Best security practice restricts the privilege of assigning\n privileges to authorized personnel. Authorized personnel include DBAs, object\n owners, and, where designed and included in the application's functions,\n application administrators. Restricting privilege-granting functions to\n authorized accounts can help decrease mismanagement of privileges and wrongful\n assignments to unauthorized accounts.\"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000516-DB-999900'\n tag \"gid\": 'V-61437'\n tag \"rid\": 'SV-75927r3_rule'\n tag \"stig_id\": 'O121-BP-022500'\n tag \"fix_id\": 'F-67353r2_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\n\n * Subject to change based on version installed\n\n Run the SQL statement:\n\n select grantee||': '||granted_role from dba_role_privs\n where admin_option = 'YES' and grantee not in\n (select distinct owner from dba_objects)\n and grantee not in\n (select grantee from dba_role_privs\n where granted_role = 'DBA')\n order by grantee;\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 Review the System Security Plan to confirm any grantees listed are\n ISSO-authorized DBA accounts or application administration roles.\n\n If any grantees listed are not authorized and documented, this is a finding.\"\n tag \"fix\": \"Revoke assignment of roles with the WITH ADMIN OPTION from\n unauthorized grantees and re-grant them without the option if required.\n\n SQL statements to remove the admin option from an unauthorized grantee:\n revoke from ;\n grant to ;\n\n Restrict use of the WITH ADMIN OPTION to authorized administrators.\n\n Document authorized role assignments with the WITH ADMIN OPTION in the System\n 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 users_with_admin_option = sql.query(\"select grantee from dba_role_privs\n where admin_option = 'YES' and grantee not in\n (select distinct owner from dba_objects)\n and grantee not in\n (select grantee from dba_role_privs\n where granted_role = 'DBA')\n order by grantee;\").column('grantee').uniq\n if users_with_admin_option.empty?\n impact 0.0\n describe 'There are no oracle users with the admin option, therefore control N/A' do\n skip 'There are no oracle users with the admin option, therefore control N/A'\n end\n else\n users_with_admin_option.each do |user|\n describe \"oracle users with admin option: #{user}\" do\n subject { user }\n it { should be_in input('allowed_dbadmin_users') }\n end\n end\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61737.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61437.rb", "line": 1 }, - "id": "V-61737" + "id": "V-61437" }, { - "title": "The DBMS must terminate the network connection associated with a\n communications session at the end of the session or 15 minutes of inactivity.", - "desc": "Non-local maintenance and diagnostic activities are those activities\n conducted by individuals communicating through a network, either an external\n network (e.g., the Internet) or an internal network.\n\n The act of managing systems and applications includes the ability to access\n sensitive application information, such as system configuration details,\n diagnostic information, user information, and potentially sensitive application\n data.\n\n When applications provide a remote management capability inherent to the\n application, the application needs to ensure all sessions and network\n connections are terminated when non-local maintenance is completed.\n\n When network connections are left open after the database session has\n closed, the network session is open to session hijacking.\n\n The Oracle Listener inherently meets most of this SRG requirement. When a\n user logs off, or times out, or encounters an unrecoverable network fault, the\n Oracle Listener terminates all sessions and network connections. The remaining\n aspect of the requirement, the timeout because of inactivity, is configurable.", + "title": "Administrative privileges must be assigned to database accounts via\n database roles.", + "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 Privileges granted outside the context of the application user job function\n are more likely to go unmanaged or without oversight for authorization.\n Maintenance of privileges using roles defined for discrete job functions offers\n improved oversight of application user privilege assignments and helps to\n protect against unauthorized privilege assignment.", "descriptions": { - "default": "Non-local maintenance and diagnostic activities are those activities\n conducted by individuals communicating through a network, either an external\n network (e.g., the Internet) or an internal network.\n\n The act of managing systems and applications includes the ability to access\n sensitive application information, such as system configuration details,\n diagnostic information, user information, and potentially sensitive application\n data.\n\n When applications provide a remote management capability inherent to the\n application, the application needs to ensure all sessions and network\n connections are terminated when non-local maintenance is completed.\n\n When network connections are left open after the database session has\n closed, the network session is open to session hijacking.\n\n The Oracle Listener inherently meets most of this SRG requirement. When a\n user logs off, or times out, or encounters an unrecoverable network fault, the\n Oracle Listener terminates all sessions and network connections. The remaining\n aspect of the requirement, the timeout because of inactivity, is configurable." + "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 Privileges granted outside the context of the application user job function\n are more likely to go unmanaged or without oversight for authorization.\n Maintenance of privileges using roles defined for discrete job functions offers\n improved oversight of application user privilege assignments and helps to\n protect against unauthorized privilege assignment." }, "impact": 0.5, "refs": [ @@ -163,16 +159,17 @@ } ], "tags": { - "gtitle": "SRG-APP-000190-DB-000137", - "gid": "V-61757", - "rid": "SV-76247r2_rule", - "stig_id": "O121-C2-016500", - "fix_id": "F-67673r2_fix", + "gtitle": "SRG-APP-000062-DB-000034", + "gid": "V-61591", + "rid": "SV-76081r3_rule", + "stig_id": "O121-C2-004000", + "fix_id": "F-67507r1_fix", "cci": [ - "CCI-001133" + "CCI-000366", + "CCI-002220" ], "nist": [ - "SC-10", + "AC-5 c", "Rev_4" ], "false_negatives": null, @@ -185,30 +182,30 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Review DBMS settings, OS settings, and vendor documentation to\n verify network connections are terminated when a database communications\n session is ended or after 15 minutes of inactivity.\n\n If the network connection is not terminated, this is a finding.\n\n The defined duration for these timeouts 15 minutes, except to fulfill\n documented and validated mission requirements.", - "fix": "Configure DBMS and/or OS settings to disconnect network sessions\n when database communication sessions have ended or after the DoD-defined period\n of inactivity.\n\n To configure this in Oracle, modify each relevant profile. The resource name\n is IDLE_TIME, which is expressed in minutes. Using PPPPPP as an example of a\n profile, set the timeout to 15 minutes with:\n ALTER PROFILE PPPPPP LIMIT IDLE_TIME 15;" + "check": "Review accounts for direct assignment of administrative\n privileges. Connected as SYSDBA, run the query:\n SELECT grantee, privilege\n FROM dba_sys_privs\n WHERE grantee IN\n (\n SELECT username\n FROM dba_users\n WHERE username NOT IN\n (\n 'XDB', 'SYSTEM', 'SYS', 'LBACSYS',\n 'DVSYS', 'DVF', 'SYSMAN_RO',\n 'SYSMAN_BIPLATFORM', 'SYSMAN_MDS',\n 'SYSMAN_OPSS', 'SYSMAN_STB', 'DBSNMP',\n 'SYSMAN', 'APEX_040200', 'WMSYS',\n 'SYSDG', 'SYSBACKUP', 'SPATIAL_WFS_ADMIN_USR',\n 'SPATIAL_CSW_ADMIN_US', 'GSMCATUSER',\n 'OLAPSYS', 'SI_INFORMTN_SCHEMA',\n 'OUTLN', 'ORDSYS', 'ORDDATA', 'OJVMSYS',\n 'ORACLE_OCM', 'MDSYS', 'ORDPLUGINS',\n 'GSMADMIN_INTERNAL', 'MDDATA', 'FLOWS_FILES',\n 'DIP', 'CTXSYS', 'AUDSYS',\n 'APPQOSSYS', 'APEX_PUBLIC_USER', 'ANONYMOUS',\n 'SPATIAL_CSW_ADMIN_USR', 'SYSKM',\n 'SYSMAN_TYPES', 'MGMT_VIEW',\n 'EUS_ENGINE_USER', 'EXFSYS', 'SYSMAN_APM'\n )\n )\n AND privilege NOT IN ('UNLIMITED TABLESPACE'\n , 'REFERENCES', 'INDEX', 'SYSDBA', 'SYSOPER'\n )\n ORDER BY 1, 2;\n If any administrative privileges have been assigned directly to a database\n account, this is a finding.\n (The list of special accounts that are excluded from this requirement may not\n be complete. It is expected that the DBA will edit the list to suit local\n circumstances, adding other special accounts as necessary, and removing any\n that are not supposed to be in use in the Oracle deployment that is under\n review.)", + "fix": "Create roles for administrative function assignments. Assign the\n necessary privileges for the administrative functions to a role. Do not assign\n administrative privileges directly to users, except for those that Oracle does\n not permit to be assigned via roles." }, - "code": "control 'V-61757' do\n title \"The DBMS must terminate the network connection associated with a\n communications session at the end of the session or 15 minutes of inactivity.\"\n desc \"Non-local maintenance and diagnostic activities are those activities\n conducted by individuals communicating through a network, either an external\n network (e.g., the Internet) or an internal network.\n\n The act of managing systems and applications includes the ability to access\n sensitive application information, such as system configuration details,\n diagnostic information, user information, and potentially sensitive application\n data.\n\n When applications provide a remote management capability inherent to the\n application, the application needs to ensure all sessions and network\n connections are terminated when non-local maintenance is completed.\n\n When network connections are left open after the database session has\n closed, the network session is open to session hijacking.\n\n The Oracle Listener inherently meets most of this SRG requirement. When a\n user logs off, or times out, or encounters an unrecoverable network fault, the\n Oracle Listener terminates all sessions and network connections. The remaining\n aspect of the requirement, the timeout because of inactivity, is configurable.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000190-DB-000137'\n tag \"gid\": 'V-61757'\n tag \"rid\": 'SV-76247r2_rule'\n tag \"stig_id\": 'O121-C2-016500'\n tag \"fix_id\": 'F-67673r2_fix'\n tag \"cci\": ['CCI-001133']\n tag \"nist\": ['SC-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 settings, OS settings, and vendor documentation to\n verify network connections are terminated when a database communications\n session is ended or after 15 minutes of inactivity.\n\n If the network connection is not terminated, this is a finding.\n\n The defined duration for these timeouts 15 minutes, except to fulfill\n documented and validated mission requirements.\"\n tag \"fix\": \"Configure DBMS and/or OS settings to disconnect network sessions\n when database communication sessions have ended or after the DoD-defined period\n of inactivity.\n\n To configure this in Oracle, modify each relevant profile. The resource name\n is IDLE_TIME, which is expressed in minutes. Using PPPPPP as an example of a\n profile, set the timeout to 15 minutes with:\n ALTER PROFILE PPPPPP LIMIT IDLE_TIME 15;\"\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 = 'IDLE_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 idle_time = sql.query(format(query, profile: profile)).column('limit')\n\n describe \"The oracle database idele time for profile: #{profile}\" do\n subject { idle_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", + "code": "control 'V-61591' do\n title \"Administrative privileges must be assigned to database accounts via\n database roles.\"\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 Privileges granted outside the context of the application user job function\n are more likely to go unmanaged or without oversight for authorization.\n Maintenance of privileges using roles defined for discrete job functions offers\n improved oversight of application user privilege assignments and helps to\n protect against unauthorized privilege assignment.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000062-DB-000034'\n tag \"gid\": 'V-61591'\n tag \"rid\": 'SV-76081r3_rule'\n tag \"stig_id\": 'O121-C2-004000'\n tag \"fix_id\": 'F-67507r1_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 accounts for direct assignment of administrative\n privileges. Connected as SYSDBA, run the query:\n SELECT grantee, privilege\n FROM dba_sys_privs\n WHERE grantee IN\n (\n SELECT username\n FROM dba_users\n WHERE username NOT IN\n (\n 'XDB', 'SYSTEM', 'SYS', 'LBACSYS',\n 'DVSYS', 'DVF', 'SYSMAN_RO',\n 'SYSMAN_BIPLATFORM', 'SYSMAN_MDS',\n 'SYSMAN_OPSS', 'SYSMAN_STB', 'DBSNMP',\n 'SYSMAN', 'APEX_040200', 'WMSYS',\n 'SYSDG', 'SYSBACKUP', 'SPATIAL_WFS_ADMIN_USR',\n 'SPATIAL_CSW_ADMIN_US', 'GSMCATUSER',\n 'OLAPSYS', 'SI_INFORMTN_SCHEMA',\n 'OUTLN', 'ORDSYS', 'ORDDATA', 'OJVMSYS',\n 'ORACLE_OCM', 'MDSYS', 'ORDPLUGINS',\n 'GSMADMIN_INTERNAL', 'MDDATA', 'FLOWS_FILES',\n 'DIP', 'CTXSYS', 'AUDSYS',\n 'APPQOSSYS', 'APEX_PUBLIC_USER', 'ANONYMOUS',\n 'SPATIAL_CSW_ADMIN_USR', 'SYSKM',\n 'SYSMAN_TYPES', 'MGMT_VIEW',\n 'EUS_ENGINE_USER', 'EXFSYS', 'SYSMAN_APM'\n )\n )\n AND privilege NOT IN ('UNLIMITED TABLESPACE'\n , 'REFERENCES', 'INDEX', 'SYSDBA', 'SYSOPER'\n )\n ORDER BY 1, 2;\n If any administrative privileges have been assigned directly to a database\n account, this is a finding.\n (The list of special accounts that are excluded from this requirement may not\n be complete. It is expected that the DBA will edit the list to suit local\n circumstances, adding other special accounts as necessary, and removing any\n that are not supposed to be in use in the Oracle deployment that is under\n review.)\"\n tag \"fix\": \"Create roles for administrative function assignments. Assign the\n necessary privileges for the administrative functions to a role. Do not assign\n administrative privileges directly to users, except for those that Oracle does\n not permit to be assigned via roles.\"\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_accounts_with_administrative_privs = sql.query(\"SELECT grantee\n FROM dba_sys_privs\n WHERE grantee IN\n (\n SELECT username\n FROM dba_users\n WHERE username NOT IN\n (\n 'XDB', 'SYSTEM', 'SYS', 'LBACSYS',\n 'DVSYS', 'DVF', 'SYSMAN_RO',\n 'SYSMAN_BIPLATFORM', 'SYSMAN_MDS',\n 'SYSMAN_OPSS', 'SYSMAN_STB', 'DBSNMP',\n 'SYSMAN', 'APEX_040200', 'WMSYS',\n 'SYSDG', 'SYSBACKUP', 'SPATIAL_WFS_ADMIN_USR',\n 'SPATIAL_CSW_ADMIN_US', 'GSMCATUSER',\n 'OLAPSYS', 'SI_INFORMTN_SCHEMA',\n 'OUTLN', 'ORDSYS', 'ORDDATA', 'OJVMSYS',\n 'ORACLE_OCM', 'MDSYS', 'ORDPLUGINS',\n 'GSMADMIN_INTERNAL', 'MDDATA', 'FLOWS_FILES',\n 'DIP', 'CTXSYS', 'AUDSYS',\n 'APPQOSSYS', 'APEX_PUBLIC_USER', 'ANONYMOUS',\n 'SPATIAL_CSW_ADMIN_USR', 'SYSKM',\n 'SYSMAN_TYPES', 'MGMT_VIEW',\n 'EUS_ENGINE_USER', 'EXFSYS', 'SYSMAN_APM', 'RDSADMIN'\n )\n )\n AND privilege NOT IN ('UNLIMITED TABLESPACE'\n , 'REFERENCES', 'INDEX', 'SYSDBA', 'SYSOPER'\n );\").column('grantee').uniq\n\n describe 'Database accounts with administrative privileges' do\n subject { database_accounts_with_administrative_privs }\n it { should be_empty }\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61757.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61591.rb", "line": 1 }, - "id": "V-61757" + "id": "V-61591" }, { - "title": "The DBMS data files, transaction logs and audit files must be stored\n in dedicated directories or disk partitions separate from software or other\n application files.", - "desc": "Protection of DBMS data, transaction and audit data files stored by\n the host operating system is dependent on OS controls. When different\n applications share the same database process, resource contention and differing\n security controls may be required to isolate and protect one application's data\n and audit logs from another. DBMS software libraries and configuration files\n also require differing access control lists.", + "title": "Use of the DBMS software installation account must be restricted.", + "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 The DBMS software installation account may require privileges not required\n for database administration or other functions. Use of accounts configured with\n excess privileges may result in the loss or compromise of data or system\n settings due to elevated privileges that bypass controls designed to protect\n them.\n\n This requirement is particularly important because Oracle equates the\n installation account with the SYS account - the super-DBA. Once logged on to\n the operating system, this account can connect to the database AS SYSDBA\n without further authentication. It is very powerful and, by virtue of not\n being linked to any one person, cannot be audited to the level of the\n individual.", "descriptions": { - "default": "Protection of DBMS data, transaction and audit data files stored by\n the host operating system is dependent on OS controls. When different\n applications share the same database process, resource contention and differing\n security controls may be required to isolate and protect one application's data\n and audit logs from another. DBMS software libraries and configuration files\n also require differing access control lists." + "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 The DBMS software installation account may require privileges not required\n for database administration or other functions. Use of accounts configured with\n excess privileges may result in the loss or compromise of data or system\n settings due to elevated privileges that bypass controls designed to protect\n them.\n\n This requirement is particularly important because Oracle equates the\n installation account with the SYS account - the super-DBA. Once logged on to\n the operating system, this account can connect to the database AS SYSDBA\n without further authentication. It is very powerful and, by virtue of not\n being linked to any one person, cannot be audited to the level of the\n individual." }, - "impact": 0.5, + "impact": 0.7, "refs": [], "tags": { - "gtitle": "SRG-APP-000516-DB-999900", - "gid": "V-61963", - "rid": "SV-76453r1_rule", - "stig_id": "O121-BP-025100", - "fix_id": "F-67883r1_fix", + "gtitle": "SRG-APP-000063-DB-000022", + "gid": "V-61865", + "rid": "SV-76355r2_rule", + "stig_id": "O121-OS-004600", + "fix_id": "F-67781r4_fix", "cci": [ "CCI-000366" ], @@ -226,35 +223,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Review the disk/directory specification where database data,\n transaction log and audit files are stored.\n\n If DBMS data, transaction or audit data files are stored in the same directory,\n this is a finding.\n\n If separation of data, transaction and audit data is not supported by the DBMS,\n this check is not a finding.\n\n If stored separately and access permissions for each directory is the same,\n this is a finding.", - "fix": "Product-specific fix pending development. Use Generic Fix listed\n below:\n\n Specify dedicated host system disk directories to store database data,\n transaction and audit files.\n\n Configure DBMS default file storage locations to use dedicated disk directories\n where supported by the DBMS." + "check": "Review system documentation to identify the installation\n account.\n\n Verify whether the account is used for anything involving interactive activity\n beyond DBMS software installation, upgrade, and maintenance actions.\n\n If the account is used for anything involving interactive activity beyond DBMS\n software installation, upgrade, and maintenance actions, this is a finding.", + "fix": "Restrict interactive use of the DBMS software installation\n account to DBMS software installation, upgrade, and maintenance actions only.\n\n If possible, disable installation accounts when authorized actions are not\n being performed. Otherwise, disable the use of the account(s) for interactive\n activity." }, - "code": "control 'V-61963' do\n title \"The DBMS data files, transaction logs and audit files must be stored\n in dedicated directories or disk partitions separate from software or other\n application files.\"\n desc \"Protection of DBMS data, transaction and audit data files stored by\n the host operating system is dependent on OS controls. When different\n applications share the same database process, resource contention and differing\n security controls may be required to isolate and protect one application's data\n and audit logs from another. DBMS software libraries and configuration files\n also require differing access control lists.\"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000516-DB-999900'\n tag \"gid\": 'V-61963'\n tag \"rid\": 'SV-76453r1_rule'\n tag \"stig_id\": 'O121-BP-025100'\n tag \"fix_id\": 'F-67883r1_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 disk/directory specification where database data,\n transaction log and audit files are stored.\n\n If DBMS data, transaction or audit data files are stored in the same directory,\n this is a finding.\n\n If separation of data, transaction and audit data is not supported by the DBMS,\n this check is not a finding.\n\n If stored separately and access permissions for each directory is the same,\n this is a finding.\"\n tag \"fix\": \"Product-specific fix pending development. Use Generic Fix listed\n below:\n\n Specify dedicated host system disk directories to store database data,\n transaction and audit files.\n\n Configure DBMS default file storage locations to use dedicated disk directories\n where supported by the DBMS.\"\n describe 'A manual review is required to ensure the DBMS data files, transaction logs and audit files are stored\n in dedicated directories or disk partitions separate from software or other\n application files' do\n skip 'A manual review is required to ensure the DBMS data files, transaction logs and audit files are stored\n in dedicated directories or disk partitions separate from software or other\n application files'\n end\nend\n", + "code": "control 'V-61865' do\n title 'Use of the DBMS software installation account must be restricted.'\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 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 The DBMS software installation account may require privileges not required\n for database administration or other functions. Use of accounts configured with\n excess privileges may result in the loss or compromise of data or system\n settings due to elevated privileges that bypass controls designed to protect\n them.\n\n This requirement is particularly important because Oracle equates the\n installation account with the SYS account - the super-DBA. Once logged on to\n the operating system, this account can connect to the database AS SYSDBA\n without further authentication. It is very powerful and, by virtue of not\n being linked to any one person, cannot be audited to the level of the\n individual.\n \"\n impact 0.7\n tag \"gtitle\": 'SRG-APP-000063-DB-000022'\n tag \"gid\": 'V-61865'\n tag \"rid\": 'SV-76355r2_rule'\n tag \"stig_id\": 'O121-OS-004600'\n tag \"fix_id\": 'F-67781r4_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 system documentation to identify the installation\n account.\n\n Verify whether the account is used for anything involving interactive activity\n beyond DBMS software installation, upgrade, and maintenance actions.\n\n If the account is used for anything involving interactive activity beyond DBMS\n software installation, upgrade, and maintenance actions, this is a finding.\"\n tag \"fix\": \"Restrict interactive use of the DBMS software installation\n account to DBMS software installation, upgrade, and maintenance actions only.\n\n If possible, disable installation accounts when authorized actions are not\n being performed. Otherwise, disable the use of the account(s) for interactive\n activity.\"\n describe 'A manual review is required to ensure the use of the DBMS software installation account is restricted' do\n skip 'A manual review is required to ensure the use of the DBMS software installation account is restricted'\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61963.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61865.rb", "line": 1 }, - "id": "V-61963" + "id": "V-61865" }, { - "title": "The DBMS must provide audit record generation capability for\n organization-defined auditable events within the database.", - "desc": "Audit records can be generated from various components within the\n information system. (e.g., network interface, hard disk, modem, etc.). From an\n application perspective, certain specific application functionalities may be\n audited as well.\n\n The list of audited events is the set of events for which audits are to be\n generated. This set of events is typically a subset of the list of all events\n for which the system is capable of generating audit records (i.e., auditable\n events, timestamps, source and destination addresses, user/process identifiers,\n event descriptions, success/fail indications, file names involved, and access\n control or flow control rules invoked).\n\n Organizations define which application components shall provide auditable\n events.\n\n The DBMS must provide auditing for the list of events defined by the\n organization or risk negatively impacting forensic investigations into\n malicious behavior in the information system. Audit records can be generated\n from various components within the information system, such as network\n interfaces, hard disks, modems, etc. From an application perspective, certain\n specific application functionalities may be audited, as well.\n\n The list of audited events is the set of events for which audits are to be\n generated. This set of events is typically a subset of the list of all events\n for which the system is capable of generating audit records (i.e., auditable\n events, timestamps, source and destination addresses, user/process identifiers,\n event descriptions, success/fail indications, file names involved, and access\n control or flow control rules invoked).\n\n Organizations may define the organizational personnel accountable for\n determining which application components shall provide auditable events.\n\n Auditing provides accountability for changes made to the DBMS configuration\n or its objects and data. It provides a means to discover suspicious activity\n and unauthorized changes. Without auditing, a compromise may go undetected and\n without a means to determine accountability.\n\n The Department of Defense has established the following as the minimum set\n of auditable events. Most can be audited via Oracle settings; some - marked\n here with an asterisk - cannot, and may require OS settings.\n - Successful and unsuccessful attempts to access, modify, or delete\n privileges, security objects, security levels, or categories of information\n (e.g. classification levels).\n - Successful and unsuccessful logon attempts, privileged activities or\n other system level access\n - Starting and ending time for user access to the system, concurrent logons\n from different workstations.\n - Successful and unsuccessful accesses to objects.\n - All program initiations.\n - *All direct access to the information system.\n - All account creations, modifications, disabling, and terminations.\n - *All kernel module loads, unloads, and restarts.", + "title": "The Oracle REMOTE_LOGIN_PASSWORDFILE parameter must be set to\n EXCLUSIVE or NONE.", + "desc": "The REMOTE_LOGIN_PASSWORDFILE setting of \"NONE\" disallows remote\n administration of the database. The REMOTE_LOGIN_PASSWORDFILE setting of\n \"EXCLUSIVE\" allows for auditing of individual DBA logons to the SYS account.\n If not set to \"EXCLUSIVE\", remote connections to the database as \"internal\"\n or \"as SYSDBA\" are not logged to an individual account.", "descriptions": { - "default": "Audit records can be generated from various components within the\n information system. (e.g., network interface, hard disk, modem, etc.). From an\n application perspective, certain specific application functionalities may be\n audited as well.\n\n The list of audited events is the set of events for which audits are to be\n generated. This set of events is typically a subset of the list of all events\n for which the system is capable of generating audit records (i.e., auditable\n events, timestamps, source and destination addresses, user/process identifiers,\n event descriptions, success/fail indications, file names involved, and access\n control or flow control rules invoked).\n\n Organizations define which application components shall provide auditable\n events.\n\n The DBMS must provide auditing for the list of events defined by the\n organization or risk negatively impacting forensic investigations into\n malicious behavior in the information system. Audit records can be generated\n from various components within the information system, such as network\n interfaces, hard disks, modems, etc. From an application perspective, certain\n specific application functionalities may be audited, as well.\n\n The list of audited events is the set of events for which audits are to be\n generated. This set of events is typically a subset of the list of all events\n for which the system is capable of generating audit records (i.e., auditable\n events, timestamps, source and destination addresses, user/process identifiers,\n event descriptions, success/fail indications, file names involved, and access\n control or flow control rules invoked).\n\n Organizations may define the organizational personnel accountable for\n determining which application components shall provide auditable events.\n\n Auditing provides accountability for changes made to the DBMS configuration\n or its objects and data. It provides a means to discover suspicious activity\n and unauthorized changes. Without auditing, a compromise may go undetected and\n without a means to determine accountability.\n\n The Department of Defense has established the following as the minimum set\n of auditable events. Most can be audited via Oracle settings; some - marked\n here with an asterisk - cannot, and may require OS settings.\n - Successful and unsuccessful attempts to access, modify, or delete\n privileges, security objects, security levels, or categories of information\n (e.g. classification levels).\n - Successful and unsuccessful logon attempts, privileged activities or\n other system level access\n - Starting and ending time for user access to the system, concurrent logons\n from different workstations.\n - Successful and unsuccessful accesses to objects.\n - All program initiations.\n - *All direct access to the information system.\n - All account creations, modifications, disabling, and terminations.\n - *All kernel module loads, unloads, and restarts." + "default": "The REMOTE_LOGIN_PASSWORDFILE setting of \"NONE\" disallows remote\n administration of the database. The REMOTE_LOGIN_PASSWORDFILE setting of\n \"EXCLUSIVE\" allows for auditing of individual DBA logons to the SYS account.\n If not set to \"EXCLUSIVE\", remote connections to the database as \"internal\"\n or \"as SYSDBA\" are not logged to an individual account." }, "impact": 0.5, "refs": [], "tags": { - "gtitle": "SRG-APP-000089-DB-000064", - "gid": "V-61621", - "rid": "SV-76111r1_rule", - "stig_id": "O121-C2-006800", - "fix_id": "F-67537r1_fix", + "gtitle": "SRG-APP-000516-DB-999900", + "gid": "V-61431", + "rid": "SV-75921r2_rule", + "stig_id": "O121-BP-022200", + "fix_id": "F-67347r2_fix", "cci": [ - "CCI-000169" + "CCI-000366" ], "nist": [ - "AU-12 a", + "CM-6 b", "Rev_4" ], "false_negatives": null, @@ -267,35 +264,39 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "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 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 To confirm that Oracle audit is capturing information on the required events,\n review the contents of the SYS.AUD$ table or the audit file, whichever is in\n use. If auditable events are not listed, 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 SELECT * FROM V$OPTION WHERE PARAMETER = 'Unified Auditing';\n If Oracle returns the value 'TRUE', this is not a finding.\n\n To confirm that Oracle audit is capturing information on the required events,\n review the contents of the SYS.UNIFIED_AUDIT_TRAIL view. If auditable events\n are not listed, this is a finding.", - "fix": "Configure the DBMS's auditing to audit organization-defined\n auditable events. If preferred, use a third-party tool. The tool must provide\n the minimum capability to audit the required 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 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 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 locations below.\n\n If Unified Auditing is used:\n Use this process 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.\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 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 locations above." + "check": "From SQL*Plus:\n\n select value from v$parameter where upper(name) = 'REMOTE_LOGIN_PASSWORDFILE';\n\n If the value returned does not equal 'EXCLUSIVE' or 'NONE', this is a finding.", + "fix": "Disable use of the REMOTE_LOGIN_PASSWORDFILE where remote\n administration is not authorized by specifying a value of NONE.\n\n If authorized, restrict use of a password file to exclusive use by each\n database by specifying a value of EXCLUSIVE.\n\n From SQL*Plus:\n\n alter system set REMOTE_LOGIN_PASSWORDFILE = 'EXCLUSIVE' scope = spfile;\n\n OR\n\n alter system set REMOTE_LOGIN_PASSWORDFILE = 'NONE' scope = spfile;\n\n The above SQL*Plus command will set the parameter to take effect at next system\n startup." }, - "code": "control 'V-61621' do\n title \"The DBMS must provide audit record generation capability for\n organization-defined auditable events within the database.\"\n desc \"Audit records can be generated from various components within the\n information system. (e.g., network interface, hard disk, modem, etc.). From an\n application perspective, certain specific application functionalities may be\n audited as well.\n\n The list of audited events is the set of events for which audits are to be\n generated. This set of events is typically a subset of the list of all events\n for which the system is capable of generating audit records (i.e., auditable\n events, timestamps, source and destination addresses, user/process identifiers,\n event descriptions, success/fail indications, file names involved, and access\n control or flow control rules invoked).\n\n Organizations define which application components shall provide auditable\n events.\n\n The DBMS must provide auditing for the list of events defined by the\n organization or risk negatively impacting forensic investigations into\n malicious behavior in the information system. Audit records can be generated\n from various components within the information system, such as network\n interfaces, hard disks, modems, etc. From an application perspective, certain\n specific application functionalities may be audited, as well.\n\n The list of audited events is the set of events for which audits are to be\n generated. This set of events is typically a subset of the list of all events\n for which the system is capable of generating audit records (i.e., auditable\n events, timestamps, source and destination addresses, user/process identifiers,\n event descriptions, success/fail indications, file names involved, and access\n control or flow control rules invoked).\n\n Organizations may define the organizational personnel accountable for\n determining which application components shall provide auditable events.\n\n Auditing provides accountability for changes made to the DBMS configuration\n or its objects and data. It provides a means to discover suspicious activity\n and unauthorized changes. Without auditing, a compromise may go undetected and\n without a means to determine accountability.\n\n The Department of Defense has established the following as the minimum set\n of auditable events. Most can be audited via Oracle settings; some - marked\n here with an asterisk - cannot, and may require OS settings.\n - Successful and unsuccessful attempts to access, modify, or delete\n privileges, security objects, security levels, or categories of information\n (e.g. classification levels).\n - Successful and unsuccessful logon attempts, privileged activities or\n other system level access\n - Starting and ending time for user access to the system, concurrent logons\n from different workstations.\n - Successful and unsuccessful accesses to objects.\n - All program initiations.\n - *All direct access to the information system.\n - All account creations, modifications, disabling, and terminations.\n - *All kernel module loads, unloads, and restarts.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000089-DB-000064'\n tag \"gid\": 'V-61621'\n tag \"rid\": 'SV-76111r1_rule'\n tag \"stig_id\": 'O121-C2-006800'\n tag \"fix_id\": 'F-67537r1_fix'\n tag \"cci\": ['CCI-000169']\n tag \"nist\": ['AU-12 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, 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 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 To confirm that Oracle audit is capturing information on the required events,\n review the contents of the SYS.AUD$ table or the audit file, whichever is in\n use. If auditable events are not listed, 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 SELECT * FROM V$OPTION WHERE PARAMETER = 'Unified Auditing';\n If Oracle returns the value 'TRUE', this is not a finding.\n\n To confirm that Oracle audit is capturing information on the required events,\n review the contents of the SYS.UNIFIED_AUDIT_TRAIL view. If auditable events\n are not listed, this is a finding.\"\n tag \"fix\": \"Configure the DBMS's auditing to audit organization-defined\n auditable events. If preferred, use a third-party tool. The tool must provide\n the minimum capability to audit the required 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 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 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 locations below.\n\n If Unified Auditing is used:\n Use this process 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.\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 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 locations above.\"\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\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 end\nend\n", + "code": "control 'V-61431' do\n title \"The Oracle REMOTE_LOGIN_PASSWORDFILE parameter must be set to\n EXCLUSIVE or NONE.\"\n desc \"The REMOTE_LOGIN_PASSWORDFILE setting of \\\"NONE\\\" disallows remote\n administration of the database. The REMOTE_LOGIN_PASSWORDFILE setting of\n \\\"EXCLUSIVE\\\" allows for auditing of individual DBA logons to the SYS account.\n If not set to \\\"EXCLUSIVE\\\", remote connections to the database as \\\"internal\\\"\n or \\\"as SYSDBA\\\" are not logged to an individual account.\"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000516-DB-999900'\n tag \"gid\": 'V-61431'\n tag \"rid\": 'SV-75921r2_rule'\n tag \"stig_id\": 'O121-BP-022200'\n tag \"fix_id\": 'F-67347r2_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 upper(name) = 'REMOTE_LOGIN_PASSWORDFILE';\n\n If the value returned does not equal 'EXCLUSIVE' or 'NONE', this is a finding.\"\n tag \"fix\": \"Disable use of the REMOTE_LOGIN_PASSWORDFILE where remote\n administration is not authorized by specifying a value of NONE.\n\n If authorized, restrict use of a password file to exclusive use by each\n database by specifying a value of EXCLUSIVE.\n\n From SQL*Plus:\n\n alter system set REMOTE_LOGIN_PASSWORDFILE = 'EXCLUSIVE' scope = spfile;\n\n OR\n\n alter system set REMOTE_LOGIN_PASSWORDFILE = 'NONE' 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 upper(name) = 'REMOTE_LOGIN_PASSWORDFILE';\").column('value')\n\n describe.one do\n describe 'The oracle database REMOTE_LOGIN_PASSWORDFILE parameter' do\n subject { parameter }\n it { should cmp 'EXCLUSIVE' }\n end\n\n describe 'The oracle database REMOTE_LOGIN_PASSWORDFILE parameter' do\n subject { parameter }\n it { should cmp 'NONE' }\n end\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61621.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61431.rb", "line": 1 }, - "id": "V-61621" + "id": "V-61431" }, { - "title": "The system must protect audit tools from unauthorized access.", - "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. It is, therefore, imperative that access to audit tools be\n controlled and protected from unauthorized access.\n\n Applications providing tools to interface with audit data will leverage\n user permissions and roles identifying the user accessing the tools and the\n corresponding rights the user enjoys in order make access decisions regarding\n the access to audit tools.\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 restrict the ability of users to launch Denial of\n Service (DoS) attacks against other information systems or networks.", + "desc": "When it comes to DoS attacks, most of the attention is paid to\n ensuring that systems and applications are not victims of these attacks.\n\n While it is true that those accountable for systems want to ensure they are\n not affected by a DoS attack, they also need to ensure their systems and\n applications are not used to launch such an attack against others. To that\n extent, a variety of technologies exist to limit, or in some cases, eliminate\n the effects of DoS attacks.\n\n For example, boundary protection devices can filter certain types of\n packets to protect devices from being directly affected by DoS attacks.\n Limiting system resources that are allocated to any user to a bare minimum may\n also reduce the ability of users to launch some DoS attacks.\n\n Applications and application developers must take the steps needed to\n ensure users cannot use these applications to launch DoS attacks against other\n systems and networks. An example would be designing applications to include\n mechanisms that throttle network traffic so users are not able to generate\n unlimited network traffic via the application.\n\n The methods employed to counter this risk will be dependent upon the\n potential application layer methods that can be used to exploit it.\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": "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. It is, therefore, imperative that access to audit tools be\n controlled and protected from unauthorized access.\n\n Applications providing tools to interface with audit data will leverage\n user permissions and roles identifying the user accessing the tools and the\n corresponding rights the user enjoys in order make access decisions regarding\n the access to audit tools.\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": "When it comes to DoS attacks, most of the attention is paid to\n ensuring that systems and applications are not victims of these attacks.\n\n While it is true that those accountable for systems want to ensure they are\n not affected by a DoS attack, they also need to ensure their systems and\n applications are not used to launch such an attack against others. To that\n extent, a variety of technologies exist to limit, or in some cases, eliminate\n the effects of DoS attacks.\n\n For example, boundary protection devices can filter certain types of\n packets to protect devices from being directly affected by DoS attacks.\n Limiting system resources that are allocated to any user to a bare minimum may\n also reduce the ability of users to launch some DoS attacks.\n\n Applications and application developers must take the steps needed to\n ensure users cannot use these applications to launch DoS attacks against other\n systems and networks. An example would be designing applications to include\n mechanisms that throttle network traffic so users are not able to generate\n unlimited network traffic via the application.\n\n The methods employed to counter this risk will be dependent upon the\n potential application layer methods that can be used to exploit it.\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, - "refs": [], + "refs": [ + { + "ref": [] + } + ], "tags": { - "gtitle": "SRG-APP-000121-DB-000202", - "gid": "V-61659", - "rid": "SV-76149r1_rule", - "stig_id": "O121-C2-009600", - "fix_id": "F-67573r1_fix", + "gtitle": "SRG-APP-000246-DB-000133", + "gid": "V-61815", + "rid": "SV-76305r4_rule", + "stig_id": "O121-C3-019200", + "fix_id": "F-67731r10_fix", "cci": [ - "CCI-001493" + "CCI-001094" ], "nist": [ - "AU-9", + "SC-5 (1)", "Rev_4" ], "false_negatives": null, @@ -308,35 +309,35 @@ "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 to prevent unauthorized access\n are not applied to 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 accessible by authorized personnel\n only." + "check": "Review DBMS settings and custom database code to determine\n whether the DBMS or database application code could be used to launch DoS\n attacks.\n\n If the DBMS or custom database code would facilitate DoS-style attacks against\n other information systems, this is a finding.\n\n The Listener is the key for a denial of service attack. Check to insure the\n appropriate steps to secure the Oracle Listener are in place at the site.\n (Refer to the Fix for more detail on implementing these protections.)", + "fix": "Configure DBMS settings to restrict functionality that could be\n used to initiate DoS attacks.\n\n Securing the Network Connection:\n Protecting the network and its traffic from inappropriate access or\n modification is the essence of network security. You should consider all paths\n the data travels, and assess the threats on each path and node. Then, take\n steps to lessen or eliminate those threats and the consequences of a security\n breach. In addition, monitor and audit to detect either increased threat levels\n or penetration attempts.\n\n The following practices improve network security:\n\n 1. Disable the Default Listener.\n All listeners have a unique name instead of the name LISTENER and have startup\n protection.\n\n LISTENER=(DESCRIPTION =(ADDRESS = (PROTOCOL = TCP)(HOST=)(PORT = 0)))\n\n This configuration prevents the default listener from starting.\n\n 2. Prevent online administration by requiring the administrator to have the\n write privilege on the listener.ora file on the server.\n a. Add or alter this line in the listener.ora file:\n\n ADMIN_RESTRICTIONS_LISTENER=ON\n\n b. Use RELOAD to reload the configuration.\n\n 3. Set Protection against crafted network packets on database level.\n\n SEC_PROTOCOL_ERROR_TRACE_ACTION specifies the action that the database should\n take when bad packets are received from a possibly malicious client.\n\n SEC_PROTOCOL_ERROR_TRACE_ACTION = { NONE | TRACE | LOG | ALERT } (TRACE is the\n default)\n\n NONE: The database server ignores the bad packets and does not generate any\n trace files or log messages. (Not recommended)\n\n TRACE: A detailed trace file is generated when bad packets are received, which\n can be used to debug any problems in client/server communication.\n\n LOG: A minimal log message is printed in the alert logfile and in the server\n trace file. A minimal amount of disk space is used.\n\n ALERT: An alert message is sent to a DBA or monitoring console.\n\n SEC_PROTOCOL_ERROR_FURTHER_ACTION specifies the further execution of a server\n process when receiving bad packets from a possibly malicious client.\n\n SEC_PROTOCOL_ERROR_FURTHER_ACTION = { CONTINUE | (DELAY,integer) |\n (DROP,integer) } (DROP,3 is the default)\n\n CONTINUE: The server process continues execution. The database server may be\n subject to a Denial of Service (DoS) if bad packets continue to be sent by a\n malicious client. (Not recommended)\n\n (DELAY, integer) :The client experiences a delay of integer seconds before the\n server process accepts the next request from the same client connection.\n Malicious clients are prevented from excessive consumption of server resources\n while legitimate clients experience degradation in performance but can continue\n to function.\n\n (DROP, integer) : The server forcefully terminates the client connection after\n integer bad packets. The server protects itself at the expense of the client\n (for example, a client transaction may be lost). The client may reconnect and\n attempt the same operation.\n\n SEC_MAX_FAILED_LOGIN_ATTEMPTS specifies the number of authentication attempts\n that can be made by a client on a connection to the server process. After the\n specified number of failure attempts, the connection will be automatically\n dropped by the server process.\n\n SEC_MAX_FAILED_LOGIN_ATTEMPTS = n (3 is the default) Values range from 1 to\n unlimited. (A value of 1 to 3 is recommended)\n\n For more information about the parameters in listener.ora, see\n https://docs.oracle.com/database/121/NETRF/listener.htm#NETRF008\n\n 4. When a host computer has multiple IP addresses associated with multiple\n network interface controller (NIC) cards, configure the listener to the\n specific IP address.\n\n You can restrict the listener to listen on a specific IP address. Oracle\n recommends that you specify the specific IP addresses on these types of\n computers, rather than allowing the listener to listen on all IP addresses.\n Restricting the listener to specific IP addresses helps to prevent an intruder\n from stealing a TCP end point from under the listener process.\n\n 5. Restrict the privileges of the listener, so that it cannot read or write\n files in the database or the Oracle server address space.\n\n The default configuration for external procedures does not require a network\n listener to work with Oracle Database and the extproc agent. The extproc agent\n is spawned directly by Oracle Database and eliminates the risks that the\n extproc agent might be spawned by Oracle Listener unexpectedly. This default\n configuration is recommended for maximum security. For more information about\n securing external procedures see\n https://docs.oracle.com/database/121/DBSEG/app_devs.htm#DBSEG656\n However, the extproc agent can be configured to be spawned by a listener. In\n that case (not recommended) the listener should have restricted privileges.\n\n 6. Use a firewall, IAW DoD network policy and guidance.\n\n Appropriately placed and configured firewalls can prevent outside access to\n your databases.\n\n 7. Prevent unauthorized administration of the Oracle listener.\n\n Local administration of the listener is secure by default through the local\n operating system. Therefore configuring a password is neither required nor\n recommended for secure local administration. However, a password can be\n configured for the listener to provide security for administrative operations,\n such as starting or stopping the listener, viewing a list of supported\n services, or saving changes to the Listener Control configuration.\n\n By default, Oracle Net Listener permits only local administration for security\n reasons. As a policy, the listener can be administered only by the user who\n started it. This is enforced through local operating system authentication. For\n example, if user1 starts the listener, then only user1 can administer it. Any\n other user trying to administer the listener gets an error. The super user is\n the only exception.\n\n Oracle recommends that you perform listener administration in the default mode\n (secure by means of local operating system authentication), and access the\n system remotely using a remote logon. Oracle Enterprise Manager Cloud Control\n can also be used for remote administration.\n\n 8. Encrypt network traffic. (Mandatory for sensitive data and optional for\n non-sensitive, as covered in other STIG requirements.)\n\n Where applicable, use Oracle network data encryption to encrypt network traffic\n among clients, databases, and application servers.\n\n 9. Set Connect Rate to organization defined limit. (Also required by\n O121-C2-019100/SRG-APP-000245-DB-000132)\n\n The connection rate limiter feature in Oracle Net Listener enables a database\n administrator to limit the number of new connections handled by the listener.\n When this feature is enabled, Oracle Net Listener imposes a user-specified\n maximum limit on the number of new connections handled by the listener every\n second.\n\n CONNECTION_RATE_LISTENER=10\n LISTENER=\n (ADDRESS_LIST=\n (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1521)(RATE_LIMIT=yes))\n (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1522)(RATE_LIMIT=yes))\n (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1526))\n )\n\n 10. Setup Valid Node Checking.\n (See also O121-BP-025600.)\n\n Valid node checking is a security feature that protects DBMS instances from\n malevolent or errant Oracle Net connections over TCP/IP, without the need for a\n firewall or IP address filtering at the operating system-level. The feature is\n controlled by the three parameters; tcp.validnode_checking, tcp.invited_nodes,\n and tcp.excluded_nodes.\n\n Modify the sqlnet.ora file manually\n TCP.VALIDNODE_CHECKING=yes\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 If this parameter is set to yes, then incoming connections are allowed only if\n they originate from a node that conforms to the list specified by\n TCP.INVITED_NODES or TCP.EXCLUDED_NODES parameters.\n\n The TCP.INVITED_NODES and TCP.EXCLUDED_NODES parameters are valid only when the\n TCP.VALIDNODE_CHECKING parameter is set to yes (no is the default).\n\n The TCP.INVITED_NODES and TCP.EXCLUDED_NODES parameters are valid only when the\n TCP.VALIDNODE_CHECKING parameter is set to yes.\n\n Modify the listener.ora file manually\n\n TCP.EXCLUDED_NODES Syntax:\n TCP.EXCLUDED_NODES=(hostname | ip_address, hostname | ip_address, ...)\n\n Example:\n TCP.EXCLUDED_NODES=(finance.us.example.com, mktg.us.example.com, 192.0.2.25,\n 172.30.*, 2001:DB8:200C:417A/32)\n\n TCP.INVITED_NODES Syntax:\n TCP.INVITED_NODES=(hostname | ip_address, hostname | ip_address, ...)\n\n Example:\n TCP.INVITED_NODES=(sales.us.example.com, hr.us.example.com, 192.0.*,\n 2001:DB8:200C:433B/32)\n\n Usage Notes:\n\n Use TCP.INVITED_NODES to specify which clients are allowed access to the\n database. This list takes precedence over the TCP.EXCLUDED_NODES parameter if\n both lists are present. These parameters can use wildcards for IPv4 addresses\n and CIDR notation for IPv4 and IPv6 addresses.\n\n 11. Apply Listener Security Patches.\n (See also O121-C1-011100/SRG-APP-000133-DB-000205.)\n\n Critical Patch Updates are cumulative. Therefore, the latest patch will contain\n all previous security patches for the Listener.\n\n 12. Ensure that listener logging is turned on.\n\n Listener logging is on by default. If logging is not on, configure logging for\n all listeners in order to capture Listener commands and brute force password\n attacks.\n\n 13. Monitor the listener logfile.\n\n The logfile may contain TNS-01169, TNS-01189, TNS-01190, or TNS-12508 errors,\n which may signify attacks or inappropriate activity. Monitor the logfile and\n generate an alert whenever these errors are encountered." }, - "code": "control 'V-61659' do\n title 'The system must protect audit tools from unauthorized access.'\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. It is, therefore, imperative that access to audit tools be\n controlled and protected from unauthorized access.\n\n Applications providing tools to interface with audit data will leverage\n user permissions and roles identifying the user accessing the tools and the\n corresponding rights the user enjoys in order make access decisions regarding\n the access to audit tools.\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-000121-DB-000202'\n tag \"gid\": 'V-61659'\n tag \"rid\": 'SV-76149r1_rule'\n tag \"stig_id\": 'O121-C2-009600'\n tag \"fix_id\": 'F-67573r1_fix'\n tag \"cci\": ['CCI-001493']\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 to prevent unauthorized access\n are not applied to 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 accessible 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-61815' 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-61659.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61815.rb", "line": 1 }, - "id": "V-61659" + "id": "V-61815" }, { - "title": "Use of external executables must be authorized.", - "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 plugins 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 DBMS's may spawn additional external processes to execute procedures that\n are defined in the DBMS, but stored in external host files (external\n procedures). The spawned process used to execute the external procedure may\n operate within a different OS security context than the DBMS and provide\n unauthorized access to the host system.", + "title": "The DBMS must support the organizational requirements to specifically\n prohibit or restrict the use of unauthorized functions, ports, protocols,\n and/or services.", + "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 Additionally, it is sometimes convenient to provide multiple services from\n a single component of an information system (e.g., email and web services), but\n doing so increases risk by constraining the ability to restrict the use of\n functions, ports, protocols, and/or services.\n\n To support the requirements and principles of least functionality, the\n application must support the organizational requirements providing only\n essential capabilities and limiting the use of ports, protocols, and/or\n services to only those required, authorized, and approved to conduct official\n business or to address authorized quality of life issues.\n\n Database Management Systems using ports, protocols, and services deemed\n unsafe are open to attack through those ports, protocols, and services. This\n can allow unauthorized access to the database and through the database to other\n components of the information system.", "descriptions": { - "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 plugins 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 DBMS's may spawn additional external processes to execute procedures that\n are defined in the DBMS, but stored in external host files (external\n procedures). The spawned process used to execute the external procedure may\n operate within a different OS security context than the DBMS and provide\n unauthorized access to the host system." + "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 Additionally, it is sometimes convenient to provide multiple services from\n a single component of an information system (e.g., email and web services), but\n doing so increases risk by constraining the ability to restrict the use of\n functions, ports, protocols, and/or services.\n\n To support the requirements and principles of least functionality, the\n application must support the organizational requirements providing only\n essential capabilities and limiting the use of ports, protocols, and/or\n services to only those required, authorized, and approved to conduct official\n business or to address authorized quality of life issues.\n\n Database Management Systems using ports, protocols, and services deemed\n unsafe are open to attack through those ports, protocols, and services. This\n can allow unauthorized access to the database and through the database to other\n components of the information system." }, - "impact": 0, + "impact": 0.5, "refs": [], "tags": { - "gtitle": "SRG-APP-000141-DB-000093", - "gid": "V-61683", - "rid": "SV-76173r1_rule", - "stig_id": "O121-C2-011800", - "fix_id": "F-67597r1_fix", + "gtitle": "SRG-APP-000142-DB-000094", + "gid": "V-61687", + "rid": "SV-76177r1_rule", + "stig_id": "O121-C2-011900", + "fix_id": "F-67601r1_fix", "cci": [ - "CCI-000381" + "CCI-000382" ], "nist": [ - "CM-7 a", + "CM-7 b", "Rev_4" ], "false_negatives": null, @@ -349,35 +350,39 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Review the database for definitions of application executable\n objects stored external to the database.\n\n Determine if there are methods to disable use or access, or to remove\n definitions for external executable objects.\n\n Verify any application executable objects listed are authorized by the ISSO.\n\n If any are not, this is a finding.\n\n - - - - -\n To check for external procedures, execute the following query which will\n provide the libraries containing external procedures, the owners of those\n libraries, users that have been granted access to those libraries, and the\n privileges they have been granted. If there are owners other than the owners\n that Oracle provides, then there may be executable objects stored either in the\n database or external to the database that are called by objects in the\n database. Check to see that those owners are authorized to access those\n libraries. If there are users that have been granted access to libraries\n provided by Oracle, check to see that they are authorized to access those\n libraries.\n\n (connect as sysdba)\n set linesize 130\n column library_name format a25\n column name format a15\n column owner format a15\n column grantee format a15\n column privilege format a15\n select library_name,owner, '' grantee, '' privilege\n from dba_libraries where file_spec is not null\n minus\n (\n select library_name,o.name owner, '' grantee, '' privilege\n from dba_libraries l,\n sys.user$ o,\n sys.user$ ge,\n sys.obj$ obj,\n sys.objauth$ oa\n where l.owner=o.name\n and obj.owner#=o.user#\n and obj.name=l.library_name\n and oa.obj#=obj.obj#\n and ge.user#=oa.grantee#\n and l.file_spec is not null\n )\n union all\n select library_name,o.name owner, --obj.obj#,oa.privilege#,\n ge.name grantee,\n tpm.name privilege\n from dba_libraries l,\n sys.user$ o,\n sys.user$ ge,\n sys.obj$ obj,\n sys.objauth$ oa,\n sys.table_privilege_map tpm\n where l.owner=o.name\n and obj.owner#=o.user#\n and obj.name=l.library_name\n and oa.obj#=obj.obj#\n and ge.user#=oa.grantee#\n and tpm.privilege=oa.privilege#\n and l.file_spec is not null;\n /", - "fix": "Disable use of or remove any external application executable\n object definitions that are not authorized.\n\n Revoke privileges granted to users that are not authorized access to external\n applications." + "check": "Review the DBMS settings for functions, ports, protocols, and\n services that are not approved.\n\n If any are found, this is a finding.\n\n (For definitive information on Ports, Protocols and Services Management (PPSM),\n refer to\n http://www.disa.mil/Services/Network-Services/Enterprise-Connections/PPSM)\n\n - - - - -\n In the Oracle database, the communications with the database and incoming\n requests are performed by the Oracle Listener. The Oracle Listener listens on\n a specific port or ports for connections to a specific database. The Oracle\n Listener has configuration files located in the $ORACLE_HOME/network/admin\n directory. To check the ports and protocols in use, go to that directory and\n review the SQLNET.ora, LISTENER.ora, and the TNSNAMES.ora. If protocols or\n ports are in use that are not authorized, this is a finding.", + "fix": "Disable functions, ports, protocols, and services that are not\n approved.\n\n - - - - -\n Change the SQLNET.ora, LISTENER.ora, and TNSNAMES.ora files to reflect the\n proper use of ports, protocols, and services that are approved at the site.\n\n If changes to the Listener are made, the files associated with the Listener\n must be reloaded. Do that by issuing the following commands at the Unix/Linux\n or Windows prompt.\n First - issue the command to see what the current status is\n $ lsnrctl stat\n Then load the new file that was corrected to reflect site-specific requirements.\n $ lsnrctl reload\n Then check the status again to see that the changes have taken place.\n $ lsnrctl stat" }, - "code": "control 'V-61683' do\n title 'Use of external executables must be authorized.'\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 plugins 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 DBMS's may spawn additional external processes to execute procedures that\n are defined in the DBMS, but stored in external host files (external\n procedures). The spawned process used to execute the external procedure may\n operate within a different OS security context than the DBMS and provide\n unauthorized access to the host system.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000141-DB-000093'\n tag \"gid\": 'V-61683'\n tag \"rid\": 'SV-76173r1_rule'\n tag \"stig_id\": 'O121-C2-011800'\n tag \"fix_id\": 'F-67597r1_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\": \"Review the database for definitions of application executable\n objects stored external to the database.\n\n Determine if there are methods to disable use or access, or to remove\n definitions for external executable objects.\n\n Verify any application executable objects listed are authorized by the ISSO.\n\n If any are not, this is a finding.\n\n - - - - -\n To check for external procedures, execute the following query which will\n provide the libraries containing external procedures, the owners of those\n libraries, users that have been granted access to those libraries, and the\n privileges they have been granted. If there are owners other than the owners\n that Oracle provides, then there may be executable objects stored either in the\n database or external to the database that are called by objects in the\n database. Check to see that those owners are authorized to access those\n libraries. If there are users that have been granted access to libraries\n provided by Oracle, check to see that they are authorized to access those\n libraries.\n\n (connect as sysdba)\n set linesize 130\n column library_name format a25\n column name format a15\n column owner format a15\n column grantee format a15\n column privilege format a15\n select library_name,owner, '' grantee, '' privilege\n from dba_libraries where file_spec is not null\n minus\n (\n select library_name,o.name owner, '' grantee, '' privilege\n from dba_libraries l,\n sys.user$ o,\n sys.user$ ge,\n sys.obj$ obj,\n sys.objauth$ oa\n where l.owner=o.name\n and obj.owner#=o.user#\n and obj.name=l.library_name\n and oa.obj#=obj.obj#\n and ge.user#=oa.grantee#\n and l.file_spec is not null\n )\n union all\n select library_name,o.name owner, --obj.obj#,oa.privilege#,\n ge.name grantee,\n tpm.name privilege\n from dba_libraries l,\n sys.user$ o,\n sys.user$ ge,\n sys.obj$ obj,\n sys.objauth$ oa,\n sys.table_privilege_map tpm\n where l.owner=o.name\n and obj.owner#=o.user#\n and obj.name=l.library_name\n and oa.obj#=obj.obj#\n and ge.user#=oa.grantee#\n and tpm.privilege=oa.privilege#\n and l.file_spec is not null;\n /\"\n tag \"fix\": \"Disable use of or remove any external application executable\n object definitions that are not authorized.\n\n Revoke privileges granted to users that are not authorized access to external\n applications.\"\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 library_name,owner, '' grantee, '' privilege\n from dba_libraries where file_spec is not null\n minus\n (\n select library_name,o.name owner, '' grantee, '' privilege\n from dba_libraries l,\n sys.user$ o,\n sys.user$ ge,\n sys.obj$ obj,\n sys.objauth$ oa\n where l.owner=o.name\n and obj.owner#=o.user#\n and obj.name=l.library_name\n and oa.obj#=obj.obj#\n and ge.user#=oa.grantee#\n and l.file_spec is not null\n )\n union all\n select library_name,o.name owner, --obj.obj#,oa.privilege#,\n ge.name grantee,\n tpm.name privilege\n from dba_libraries l,\n sys.user$ o,\n sys.user$ ge,\n sys.obj$ obj,\n sys.objauth$ oa,\n sys.table_privilege_map tpm\n where l.owner=o.name\n and obj.owner#=o.user#\n and obj.name=l.library_name\n and oa.obj#=obj.obj#\n and ge.user#=oa.grantee#\n and tpm.privilege=oa.privilege#\n and l.file_spec is not null;\").column('owner').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-61687' do\n title \"The DBMS must support the organizational requirements to specifically\n prohibit or restrict the use of unauthorized functions, ports, protocols,\n and/or services.\"\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 Additionally, it is sometimes convenient to provide multiple services from\n a single component of an information system (e.g., email and web services), but\n doing so increases risk by constraining the ability to restrict the use of\n functions, ports, protocols, and/or services.\n\n To support the requirements and principles of least functionality, the\n application must support the organizational requirements providing only\n essential capabilities and limiting the use of ports, protocols, and/or\n services to only those required, authorized, and approved to conduct official\n business or to address authorized quality of life issues.\n\n Database Management Systems using ports, protocols, and services deemed\n unsafe are open to attack through those ports, protocols, and services. This\n can allow unauthorized access to the database and through the database to other\n components of the information system.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000142-DB-000094'\n tag \"gid\": 'V-61687'\n tag \"rid\": 'SV-76177r1_rule'\n tag \"stig_id\": 'O121-C2-011900'\n tag \"fix_id\": 'F-67601r1_fix'\n tag \"cci\": ['CCI-000382']\n tag \"nist\": ['CM-7 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 DBMS settings for functions, ports, protocols, and\n services that are not approved.\n\n If any are found, this is a finding.\n\n (For definitive information on Ports, Protocols and Services Management (PPSM),\n refer to\n http://www.disa.mil/Services/Network-Services/Enterprise-Connections/PPSM)\n\n - - - - -\n In the Oracle database, the communications with the database and incoming\n requests are performed by the Oracle Listener. The Oracle Listener listens on\n a specific port or ports for connections to a specific database. The Oracle\n Listener has configuration files located in the $ORACLE_HOME/network/admin\n directory. To check the ports and protocols in use, go to that directory and\n review the SQLNET.ora, LISTENER.ora, and the TNSNAMES.ora. If protocols or\n ports are in use that are not authorized, this is a finding.\"\n tag \"fix\": \"Disable functions, ports, protocols, and services that are not\n approved.\n\n - - - - -\n Change the SQLNET.ora, LISTENER.ora, and TNSNAMES.ora files to reflect the\n proper use of ports, protocols, and services that are approved at the site.\n\n If changes to the Listener are made, the files associated with the Listener\n must be reloaded. Do that by issuing the following commands at the Unix/Linux\n or Windows prompt.\n First - issue the command to see what the current status is\n $ lsnrctl stat\n Then load the new file that was corrected to reflect site-specific requirements.\n $ lsnrctl reload\n Then check the status again to see that the changes have taken place.\n $ lsnrctl stat\"\n describe 'A manual review is required to ensure the DBMS supports the organizational requirements to specifically\n prohibit or restrict the use of unauthorized functions, ports, protocols, and/or services' do\n skip 'A manual review is required to ensure the DBMS supports the organizational requirements to specifically\n prohibit or restrict the use of unauthorized functions, ports, protocols, and/or services'\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61683.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61687.rb", "line": 1 }, - "id": "V-61683" + "id": "V-61687" }, { - "title": "The system must protect audit information from unauthorized deletion.", - "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 deletion. This\n requirement can be achieved through multiple methods which will depend upon\n system architecture and design.\n\n Some commonly employed methods include: ensuring log files enjoy the\n proper file system permissions utilizing file system protections; restricting\n access; and backing up log data to ensure log data is retained.\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 the user enjoys in order make access decisions regarding\n the deletion 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 Deletion 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 use multifactor authentication for local 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 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": "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 deletion. This\n requirement can be achieved through multiple methods which will depend upon\n system architecture and design.\n\n Some commonly employed methods include: ensuring log files enjoy the\n proper file system permissions utilizing file system protections; restricting\n access; and backing up log data to ensure log data is retained.\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 the user enjoys in order make access decisions regarding\n the deletion 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 Deletion of database audit data could mask the theft of, or the\n unauthorized modification of, sensitive data stored in the database." + "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 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-000120-DB-000061", - "gid": "V-61657", - "rid": "SV-76147r1_rule", - "stig_id": "O121-C2-009500", - "fix_id": "F-67571r2_fix", + "gtitle": "SRG-APP-000152-DB-000107", + "gid": "V-61709", + "rid": "SV-76199r2_rule", + "stig_id": "O121-C2-013200", + "fix_id": "F-67625r1_fix", "cci": [ - "CCI-000164" + "CCI-000768" ], "nist": [ - "AU-9", + "IA-2 (4)", "Rev_4" ], "false_negatives": null, @@ -390,35 +395,35 @@ "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 deletion.\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\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 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\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 deletion, whether stored in the database itself or at\n 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": "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 locally are required to use multifactor\n 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 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 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-61657' do\n title 'The system must protect audit information from unauthorized deletion.'\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 deletion. This\n requirement can be achieved through multiple methods which will depend upon\n system architecture and design.\n\n Some commonly employed methods include: ensuring log files enjoy the\n proper file system permissions utilizing file system protections; restricting\n access; and backing up log data to ensure log data is retained.\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 the user enjoys in order make access decisions regarding\n the deletion 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 Deletion 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-000120-DB-000061'\n tag \"gid\": 'V-61657'\n tag \"rid\": 'SV-76147r1_rule'\n tag \"stig_id\": 'O121-C2-009500'\n tag \"fix_id\": 'F-67571r2_fix'\n tag \"cci\": ['CCI-000164']\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 deletion.\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\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 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\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 deletion, whether stored in the database itself or at\n 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-61709' 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-61657.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61709.rb", "line": 1 }, - "id": "V-61657" + "id": "V-61709" }, { - "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": "Fixed user and public database links must be authorized for use.", + "desc": "Database links define connections that may be used by the local\n database to access remote Oracle databases. These links provide a means for a\n compromise to the local database to spread to remote databases in the\n distributed database environment. Limiting or eliminating use of database links\n where they are not required to support the operational system can help isolate\n compromises to the local or a limited number of databases.", "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": "Database links define connections that may be used by the local\n database to access remote Oracle databases. These links provide a means for a\n compromise to the local database to spread to remote databases in the\n distributed database environment. Limiting or eliminating use of database links\n where they are not required to support the operational system can help isolate\n compromises to the local or a limited number of databases." }, - "impact": 0.5, + "impact": 0, "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-000516-DB-999900", + "gid": "V-61415", + "rid": "SV-75905r2_rule", + "stig_id": "O121-BP-021400", + "fix_id": "F-67331r1_fix", "cci": [ - "CCI-000016" + "CCI-000366" ], "nist": [ - "AC-2 (2)", + "CM-6 b", "Rev_4" ], "false_negatives": null, @@ -431,39 +436,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": "From SQL*Plus:\n\n select owner||': '||db_link from dba_db_links;\n\n If no records are returned from the first SQL statement, this check is not a\n finding.\n\n Confirm the public and fixed user database links listed are documented in the\n System Security Plan, are authorized by the ISSO, and are used for replication\n or operational system requirements.\n\n If any are not, this is a finding.\n ", + "fix": "Document all authorized connections from the database to remote\n databases in the System Security Plan.\n\n Remove all unauthorized remote database connection definitions from the\n database.\n\n From SQL*Plus:\n\n drop database link [link name];\n OR\n drop public database link [link name];\n\n Review remote database connection definitions periodically and confirm their\n use is still required and authorized." }, - "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-61415' do\n title 'Fixed user and public database links must be authorized for use.'\n desc \"Database links define connections that may be used by the local\n database to access remote Oracle databases. These links provide a means for a\n compromise to the local database to spread to remote databases in the\n distributed database environment. Limiting or eliminating use of database links\n where they are not required to support the operational system can help isolate\n compromises to the local or a limited number of databases.\"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000516-DB-999900'\n tag \"gid\": 'V-61415'\n tag \"rid\": 'SV-75905r2_rule'\n tag \"stig_id\": 'O121-BP-021400'\n tag \"fix_id\": 'F-67331r1_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 owner||': '||db_link from dba_db_links;\n\n If no records are returned from the first SQL statement, this check is not a\n finding.\n\n Confirm the public and fixed user database links listed are documented in the\n System Security Plan, are authorized by the ISSO, and are used for replication\n or operational system requirements.\n\n If any are not, this is a finding.\n \"\n tag \"fix\": \"Document all authorized connections from the database to remote\n databases in the System Security Plan.\n\n Remove all unauthorized remote database connection definitions from the\n database.\n\n From SQL*Plus:\n\n drop database link [link name];\n OR\n drop public database link [link name];\n\n Review remote database connection definitions periodically and confirm their\n use is still required and authorized.\"\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", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61561.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61415.rb", "line": 1 }, - "id": "V-61561" + "id": "V-61415" }, { - "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.", + "title": "The system must provide a real-time alert when organization-defined\n audit failure events occur.", + "desc": "It is critical for the appropriate personnel to be aware if a system\n is at risk of failing to process audit logs as required. Audit processing\n failures include: software/hardware errors, failures in the audit capturing\n mechanisms, and audit storage capacity being reached or exceeded.\n\n If audit log capacity were to be exceeded, then events subsequently\n occurring would not be recorded. Organizations shall define a maximum allowable\n percentage of storage capacity serving as an alarming threshold (e.g.,\n application has exceeded 80% of log storage capacity allocated) at which time\n the application or the logging mechanism the application utilizes will provide\n a warning to the appropriate personnel.\n\n A failure of database auditing will result in either the database\n continuing to function without auditing or in a complete halt to database\n operations. When audit processing fails, appropriate personnel must be alerted\n immediately to avoid further downtime or unaudited transactions. This can be\n an alert provided by the database, a log repository, or the OS when a\n designated log directory is nearing capacity.\n\n If Oracle Enterprise Manager is in use, the capability to issue such an\n alert is built in and configurable via the console so an alert can be sent to a\n designated administrator.", "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." + "default": "It is critical for the appropriate personnel to be aware if a system\n is at risk of failing to process audit logs as required. Audit processing\n failures include: software/hardware errors, failures in the audit capturing\n mechanisms, and audit storage capacity being reached or exceeded.\n\n If audit log capacity were to be exceeded, then events subsequently\n occurring would not be recorded. Organizations shall define a maximum allowable\n percentage of storage capacity serving as an alarming threshold (e.g.,\n application has exceeded 80% of log storage capacity allocated) at which time\n the application or the logging mechanism the application utilizes will provide\n a warning to the appropriate personnel.\n\n A failure of database auditing will result in either the database\n continuing to function without auditing or in a complete halt to database\n operations. When audit processing fails, appropriate personnel must be alerted\n immediately to avoid further downtime or unaudited transactions. This can be\n an alert provided by the database, a log repository, or the OS when a\n designated log directory is nearing capacity.\n\n If Oracle Enterprise Manager is in use, the capability to issue such an\n alert is built in and configurable via the console so an alert can be sent to a\n designated administrator." }, "impact": 0.5, - "refs": [ - { - "ref": [] - } - ], + "refs": [], "tags": { - "gtitle": "SRG-APP-000164-DB-000082", - "gid": "V-61719", - "rid": "SV-76209r1_rule", - "stig_id": "O121-C2-013900", - "fix_id": "F-67635r1_fix", + "gtitle": "SRG-APP-000104-DB-000051", + "gid": "V-61645", + "rid": "SV-76135r2_rule", + "stig_id": "O121-C2-008300", + "fix_id": "F-67559r3_fix", "cci": [ - "CCI-000205" + "CCI-001858" ], "nist": [ - "IA-5 (1) (a)", + "AU-5 (2)", "Rev_4" ], "false_negatives": null, @@ -476,35 +477,36 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "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.)" + "check": "Review Oracle Corp., OS, or third-party logging software\n settings to determine whether a real-time alert will be sent to the appropriate\n personnel when auditing fails for any reason.\n\n If real-time alerts are not sent upon auditing failure, this is a finding.", + "fix": "Configure logging software to send a real-time alert to\n appropriate personnel when auditing fails for any reason.\n\n (Oracle recommends the use of Oracle Enterprise Manager.)" }, - "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", + "code": "control 'V-61645' do\n title \"The system must provide a real-time alert when organization-defined\n audit failure events occur.\"\n desc \"It is critical for the appropriate personnel to be aware if a system\n is at risk of failing to process audit logs as required. Audit processing\n failures include: software/hardware errors, failures in the audit capturing\n mechanisms, and audit storage capacity being reached or exceeded.\n\n If audit log capacity were to be exceeded, then events subsequently\n occurring would not be recorded. Organizations shall define a maximum allowable\n percentage of storage capacity serving as an alarming threshold (e.g.,\n application has exceeded 80% of log storage capacity allocated) at which time\n the application or the logging mechanism the application utilizes will provide\n a warning to the appropriate personnel.\n\n A failure of database auditing will result in either the database\n continuing to function without auditing or in a complete halt to database\n operations. When audit processing fails, appropriate personnel must be alerted\n immediately to avoid further downtime or unaudited transactions. This can be\n an alert provided by the database, a log repository, or the OS when a\n designated log directory is nearing capacity.\n\n If Oracle Enterprise Manager is in use, the capability to issue such an\n alert is built in and configurable via the console so an alert can be sent to a\n designated administrator.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000104-DB-000051'\n tag \"gid\": 'V-61645'\n tag \"rid\": 'SV-76135r2_rule'\n tag \"stig_id\": 'O121-C2-008300'\n tag \"fix_id\": 'F-67559r3_fix'\n tag \"cci\": ['CCI-001858']\n tag \"nist\": ['AU-5 (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 Oracle Corp., OS, or third-party logging software\n settings to determine whether a real-time alert will be sent to the appropriate\n personnel when auditing fails for any reason.\n\n If real-time alerts are not sent upon auditing failure, this is a finding.\"\n tag \"fix\": \"Configure logging software to send a real-time alert to\n appropriate personnel when auditing fails for any reason.\n\n (Oracle recommends the use of Oracle Enterprise Manager.)\"\n describe 'A manual review is required to ensure the system provides a real-time alert when organization-defined\n audit failure events occur' do\n skip 'A manual review is required to ensure the system provides a real-time alert when organization-defined\n audit failure events occur'\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61719.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61645.rb", "line": 1 }, - "id": "V-61719" + "id": "V-61645" }, { - "title": "The DBMS must prevent the presentation of information system\n management-related functionality at an interface utilized by general (i.e.,\n non-privileged) users.", - "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. This may include isolating the administrative\n interface on a different 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.", + "title": "The DBMS must protect the audit records generated, as a result of\n remote access to privileged accounts, and the execution of privileged\n functions.", + "desc": "Protection of audit records and audit data is of critical importance.\n Care must be taken to ensure privileged users cannot circumvent audit\n protections put in place.\n\n Auditing might not be reliable when performed by an information system\n which the user being audited has privileged access to.\n\n The privileged user could inhibit auditing or directly modify audit\n records. To prevent this from occurring, privileged access shall be further\n defined between audit-related privileges and other privileges, thus limiting\n the users with audit-related privileges.\n\n Reducing the risk of audit compromises by privileged users can also be\n achieved, for example, by performing audit activity on a separate information\n system where the user in question has limited access or by using storage media\n that cannot be modified (e.g., write-once recording devices).\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": "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. This may include isolating the administrative\n interface on a different 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." + "default": "Protection of audit records and audit data is of critical importance.\n Care must be taken to ensure privileged users cannot circumvent audit\n protections put in place.\n\n Auditing might not be reliable when performed by an information system\n which the user being audited has privileged access to.\n\n The privileged user could inhibit auditing or directly modify audit\n records. To prevent this from occurring, privileged access shall be further\n defined between audit-related privileges and other privileges, thus limiting\n the users with audit-related privileges.\n\n Reducing the risk of audit compromises by privileged users can also be\n achieved, for example, by performing audit activity on a separate information\n system where the user in question has limited access or by using storage media\n that cannot be modified (e.g., write-once recording devices).\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.5, + "impact": 0, "refs": [], "tags": { - "gtitle": "SRG-APP-000212-DB-000123", - "gid": "V-61885", - "rid": "SV-76375r1_rule", - "stig_id": "O121-P2-017400", - "fix_id": "F-67801r1_fix", + "gtitle": "SRG-APP-000127-DB-000172", + "gid": "V-61669", + "rid": "SV-76159r1_rule", + "stig_id": "O121-C2-010200", + "fix_id": "F-67583r1_fix", "cci": [ - "CCI-001083" + "CCI-000366", + "CCI-001351" ], "nist": [ - "SC-2 (1)", + "AU-9 (4)", "Rev_4" ], "false_negatives": null, @@ -517,30 +519,30 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "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." + "check": "If Standard Auditing is used:\n For table-based auditing (DB or DB,EXTENDED), review the DBMS permissions on\n the views and base tables holding the audit data.\n\n For file-based auditing (OS, XML, or XML,EXTENDED), review the operating\n system/file system permissions on the audit file(s).\n\n If permissions exist that enable unauthorized users to view audit data, this is\n a finding.\n\n If permissions exist that enable any user (other than an account created\n specifically to manage log space and off-load audit records to a log management\n system) to modify or delete audit records, or create spurious audit records,\n this is a finding.\n\n If Unified Auditing is used:\n AUDIT_ADMIN role. This role enables the creation of unified and fine-grained\n audit policies, use the AUDIT and NOAUDIT SQL statements, view audit data, and\n manage the audit trail administration. Grant this role only to trusted users.\n\n\n\n\n AUDIT_VIEWER role. This role enables users to view and analyze audit data. The\n kind of user who needs this role is typically an external auditor.\n\n Check to ensure the authorized users have the correct roles. If permissions\n exist that enable unauthorized users to view audit data, this is a finding.\n\n If permissions exist that enable any user (other than an account created\n specifically to manage log space and off-load audit records to a log management\n system) to modify or delete audit records, or create spurious audit records,\n this is a finding.", + "fix": "If Standard Auditing is used:\n Add controls and modify permissions to protect database audit log records from\n modification, deletion, spurious creation, or unauthorized viewing.\n\n If Unified Auditing is used:\n Grant the correct Audit roles to authorized users." }, - "code": "control 'V-61885' do\n title \"The DBMS must prevent the presentation of information system\n management-related functionality at an interface utilized by general (i.e.,\n non-privileged) users.\"\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. This may include isolating the administrative\n interface on a different 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-000212-DB-000123'\n tag \"gid\": 'V-61885'\n tag \"rid\": 'SV-76375r1_rule'\n tag \"stig_id\": 'O121-P2-017400'\n tag \"fix_id\": 'F-67801r1_fix'\n tag \"cci\": ['CCI-001083']\n tag \"nist\": ['SC-2 (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\": \"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 prevents the presentation of information system\n management-related functionality at an interface utilized by general (i.e.,\n non-privileged) users.' do\n skip 'A manual review is required to ensure the DBMS prevents the presentation of information system\n management-related functionality at an interface utilized by general (i.e.,\n non-privileged) users.'\n end\nend\n", + "code": "control 'V-61669' do\n title \"The DBMS must protect the audit records generated, as a result of\n remote access to privileged accounts, and the execution of privileged\n functions.\"\n desc \"Protection of audit records and audit data is of critical importance.\n Care must be taken to ensure privileged users cannot circumvent audit\n protections put in place.\n\n Auditing might not be reliable when performed by an information system\n which the user being audited has privileged access to.\n\n The privileged user could inhibit auditing or directly modify audit\n records. To prevent this from occurring, privileged access shall be further\n defined between audit-related privileges and other privileges, thus limiting\n the users with audit-related privileges.\n\n Reducing the risk of audit compromises by privileged users can also be\n achieved, for example, by performing audit activity on a separate information\n system where the user in question has limited access or by using storage media\n that cannot be modified (e.g., write-once recording devices).\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-000127-DB-000172'\n tag \"gid\": 'V-61669'\n tag \"rid\": 'SV-76159r1_rule'\n tag \"stig_id\": 'O121-C2-010200'\n tag \"fix_id\": 'F-67583r1_fix'\n tag \"cci\": ['CCI-000366', 'CCI-001351']\n tag \"nist\": ['CM-6 b', 'Rev_4']\n tag \"nist\": ['AU-9 (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\": \"If Standard Auditing is used:\n For table-based auditing (DB or DB,EXTENDED), review the DBMS permissions on\n the views and base tables holding the audit data.\n\n For file-based auditing (OS, XML, or XML,EXTENDED), review the operating\n system/file system permissions on the audit file(s).\n\n If permissions exist that enable unauthorized users to view audit data, this is\n a finding.\n\n If permissions exist that enable any user (other than an account created\n specifically to manage log space and off-load audit records to a log management\n system) to modify or delete audit records, or create spurious audit records,\n this is a finding.\n\n If Unified Auditing is used:\n AUDIT_ADMIN role. This role enables the creation of unified and fine-grained\n audit policies, use the AUDIT and NOAUDIT SQL statements, view audit data, and\n manage the audit trail administration. Grant this role only to trusted users.\n\n\n\n\n AUDIT_VIEWER role. This role enables users to view and analyze audit data. The\n kind of user who needs this role is typically an external auditor.\n\n Check to ensure the authorized users have the correct roles. If permissions\n exist that enable unauthorized users to view audit data, this is a finding.\n\n If permissions exist that enable any user (other than an account created\n specifically to manage log space and off-load audit records to a log management\n system) to modify or delete audit records, or create spurious audit records,\n this is a finding.\"\n tag \"fix\": \"If Standard Auditing is used:\n Add controls and modify permissions to protect database audit log records from\n modification, deletion, spurious creation, or unauthorized viewing.\n\n If Unified Auditing is used:\n Grant the correct Audit roles to authorized users.\"\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-61885.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61669.rb", "line": 1 }, - "id": "V-61885" + "id": "V-61669" }, { - "title": "The DBA role must not be assigned excessive or unauthorized\n 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 Audit of privileged activity may require physical separation employing\n information systems on which the user does not have privileged access.\n\n To limit exposure and provide forensic history of activity when operating\n from within a privileged account or role, the application must support\n organizational requirements that users of information system accounts, or\n roles, with access to organization-defined lists of security functions or\n security-relevant information, use non-privileged accounts, or roles, when\n accessing other (non-security) system functions.\n\n If feasible, applications must provide access logging that ensures users\n who are granted a privileged role (or roles) have their privileged activity\n logged.\n\n DBAs, if assigned excessive privileges, could perform actions that endanger\n the information system or hide evidence of malicious activity.", + "title": "Processes (services, applications, etc.) that connect to the DBMS\n independently of individual users, must use valid, current DoD-issued PKI\n certificates for authentication to the DBMS.", + "desc": "Just as individual users must be authenticated, and just as they must\n use PKI-based authentication, so must any processes that connect to the DBMS.\n\n The DoD standard for authentication of a process or device communicating\n with another process or device is the presentation of a valid, current,\n DoD-issued Public Key Infrastructure (PKI) certificate that has previously been\n verified as Trusted by an administrator of the other process or device.\n\n This applies both to processes that run on the same server as the DBMS and\n to processes running on other computers.\n\n The Oracle-supplied accounts, SYS, SYSBACKUP, SYSDG, and SYSKM, are\n exceptions. These cannot currently use certificate-based authentication. For\n this reason among others, use of these accounts should be restricted to where\n it is truly needed.", "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 Audit of privileged activity may require physical separation employing\n information systems on which the user does not have privileged access.\n\n To limit exposure and provide forensic history of activity when operating\n from within a privileged account or role, the application must support\n organizational requirements that users of information system accounts, or\n roles, with access to organization-defined lists of security functions or\n security-relevant information, use non-privileged accounts, or roles, when\n accessing other (non-security) system functions.\n\n If feasible, applications must provide access logging that ensures users\n who are granted a privileged role (or roles) have their privileged activity\n logged.\n\n DBAs, if assigned excessive privileges, could perform actions that endanger\n the information system or hide evidence of malicious activity." + "default": "Just as individual users must be authenticated, and just as they must\n use PKI-based authentication, so must any processes that connect to the DBMS.\n\n The DoD standard for authentication of a process or device communicating\n with another process or device is the presentation of a valid, current,\n DoD-issued Public Key Infrastructure (PKI) certificate that has previously been\n verified as Trusted by an administrator of the other process or device.\n\n This applies both to processes that run on the same server as the DBMS and\n to processes running on other computers.\n\n The Oracle-supplied accounts, SYS, SYSBACKUP, SYSDG, and SYSKM, are\n exceptions. These cannot currently use certificate-based authentication. For\n this reason among others, use of these accounts should be restricted to where\n it is truly needed." }, - "impact": 0, + "impact": 0.5, "refs": [], "tags": { - "gtitle": "SRG-APP-000063-DB-000019", - "gid": "V-61599", - "rid": "SV-76089r2_rule", - "stig_id": "O121-C2-004300", - "fix_id": "F-67515r1_fix", + "gtitle": "SRG-APP-000177-DB-000069", + "gid": "V-61745", + "rid": "SV-76235r2_rule", + "stig_id": "O121-C2-015501", + "fix_id": "F-67661r1_fix", "cci": [ "CCI-000366" ], @@ -558,39 +560,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Review access permissions for objects owned by application\n owners or other non-administrative users.\n\n If DBA or administrative accounts have unauthorized application roles or\n permissions beyond those needed for administration, this is a finding.\n\n To obtain a list of privileges assigned to the DBMS user accounts, run the\n query:\n SELECT * from dba_sys_privs where grantee='DBA' order by privilege;\n\n To check to see what roles are assigned to a user, run the query:\n SELECT * from dba_role_privs where grantee = '';\n\n To check to see what privileges are assigned to a role, run the query:\n SELECT * from role_sys_privs;\n\n To show privileges by object, run the query:\n SELECT table_name, grantee,\n MAX(DECODE(privilege, 'SELECT', 'SELECT')) AS select_priv,\n MAX(DECODE(privilege, 'DELETE', 'DELETE')) AS delete_priv,\n MAX(DECODE(privilege, 'UPDATE', 'UPDATE')) AS update_priv,\n MAX(DECODE(privilege, 'INSERT', 'INSERT')) AS insert_priv\n FROM dba_tab_privs\n WHERE grantee IN (SELECT role FROM dba_roles)\n GROUP BY table_name, grantee\n ORDER BY table_name, grantee;\n\n This query will list the system privileges assigned to a specific user:\n SELECT LPAD(' ', 2*level) || granted_role \"USER PRIVS\"\n FROM\n (\n SELECT NULL grantee, username granted_role\n FROM dba_users\n WHERE username LIKE UPPER('%&uname%')\n UNION\n SELECT grantee, granted_role\n FROM dba_role_privs\n UNION\n SELECT grantee, privilege\n FROM dba_sys_privs\n )\n START WITH grantee IS NULL\n CONNECT BY grantee = prior granted_role;\n\n To list all administrative privileges granted to users via roles, run the query:\n SELECT\n username,\n rp.granted_role,\n privilege\n FROM\n dba_users u,\n dba_role_privs rp,\n dba_sys_privs sp\n WHERE username = rp.grantee\n AND rp.granted_role = sp.grantee\n AND privilege NOT IN\n (\n 'CREATE SEQUENCE', 'CREATE TRIGGER',\n 'SET CONTAINER', 'CREATE CLUSTER',\n 'CREATE PROCEDURE', 'CREATE TYPE',\n 'CREATE SESSION', 'CREATE OPERATOR',\n 'CREATE TABLE', 'CREATE INDEXTYPE'\n )\n AND username NOT IN\n (\n 'XDB', 'SYSTEM', 'SYS', 'LBACSYS',\n 'DVSYS', 'DVF', 'SYSMAN_RO', 'SYSMAN_BIPLATFORM',\n 'SYSMAN_MDS', 'SYSMAN_OPSS', 'SYSMAN_STB', 'DBSNMP',\n 'SYSMAN', 'APEX_040200', 'WMSYS', 'SYSDG',\n 'SYSBACKUP', 'SPATIAL_WFS_ADMIN_USR',\n 'SPATIAL_CSW_ADMIN_US','GSMCATUSER',\n 'OLAPSYS', 'SI_INFORMTN_SCHEMA', 'OUTLN', 'ORDSYS',\n 'ORDDATA', 'OJVMSYS', 'ORACLE_OCM', 'MDSYS',\n 'ORDPLUGINS', 'GSMADMIN_INTERNAL', 'MDDATA',\n 'FLOWS_FILES', 'DIP', 'CTXSYS', 'AUDSYS', 'APPQOSSYS',\n 'APEX_PUBLIC_USER', 'ANONYMOUS',\n 'SPATIAL_CSW_ADMIN_USR', 'SYSKM',\n 'SYSMAN_TYPES', 'MGMT_VIEW', 'EUS_ENGINE_USER',\n 'EXFSYS', 'SYSMAN_APM','IX','OWBSYS'\n )\n ORDER by 1, 2, 3;\n\n (The list of special accounts that are excluded from this requirement may not\n be complete. It is expected that the DBA will edit the list to suit local\n circumstances, adding other special accounts as necessary, and removing any\n that are not supposed to be in use in the Oracle deployment that is under\n review. Similarly, the list of privileges excluded from the list may be\n modified according to circumstances.)\n\n Data Dictionary Objects Related To System Privileges:\n all_sys_privs\n session_privs\n user_sys_privs\n dba_sys_privs\n system_privilege_map", - "fix": "Remove permissions from DBAs and other administrative users\n beyond those required for administrative functions." + "check": "Review configuration to confirm that accounts used by processes\n to connect to the DBMS are authenticated using valid, current DoD-issued PKI\n certificates.\n\n If any such account (other than SYS, SYSBACKUP, SYSDG, and SYSKM) is not\n certificate-based, this is a finding.", + "fix": "For each such account, use DoD certificate-based authentication." }, - "code": "control 'V-61599' do\n title \"The DBA role must not be assigned excessive or unauthorized\n privileges.\"\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 Audit of privileged activity may require physical separation employing\n information systems on which the user does not have privileged access.\n\n To limit exposure and provide forensic history of activity when operating\n from within a privileged account or role, the application must support\n organizational requirements that users of information system accounts, or\n roles, with access to organization-defined lists of security functions or\n security-relevant information, use non-privileged accounts, or roles, when\n accessing other (non-security) system functions.\n\n If feasible, applications must provide access logging that ensures users\n who are granted a privileged role (or roles) have their privileged activity\n logged.\n\n DBAs, if assigned excessive privileges, could perform actions that endanger\n the information system or hide evidence of malicious activity.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000063-DB-000019'\n tag \"gid\": 'V-61599'\n tag \"rid\": 'SV-76089r2_rule'\n tag \"stig_id\": 'O121-C2-004300'\n tag \"fix_id\": 'F-67515r1_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 access permissions for objects owned by application\n owners or other non-administrative users.\n\n If DBA or administrative accounts have unauthorized application roles or\n permissions beyond those needed for administration, this is a finding.\n\n To obtain a list of privileges assigned to the DBMS user accounts, run the\n query:\n SELECT * from dba_sys_privs where grantee='DBA' order by privilege;\n\n To check to see what roles are assigned to a user, run the query:\n SELECT * from dba_role_privs where grantee = '';\n\n To check to see what privileges are assigned to a role, run the query:\n SELECT * from role_sys_privs;\n\n To show privileges by object, run the query:\n SELECT table_name, grantee,\n MAX(DECODE(privilege, 'SELECT', 'SELECT')) AS select_priv,\n MAX(DECODE(privilege, 'DELETE', 'DELETE')) AS delete_priv,\n MAX(DECODE(privilege, 'UPDATE', 'UPDATE')) AS update_priv,\n MAX(DECODE(privilege, 'INSERT', 'INSERT')) AS insert_priv\n FROM dba_tab_privs\n WHERE grantee IN (SELECT role FROM dba_roles)\n GROUP BY table_name, grantee\n ORDER BY table_name, grantee;\n\n This query will list the system privileges assigned to a specific user:\n SELECT LPAD(' ', 2*level) || granted_role \\\"USER PRIVS\\\"\n FROM\n (\n SELECT NULL grantee, username granted_role\n FROM dba_users\n WHERE username LIKE UPPER('%&uname%')\n UNION\n SELECT grantee, granted_role\n FROM dba_role_privs\n UNION\n SELECT grantee, privilege\n FROM dba_sys_privs\n )\n START WITH grantee IS NULL\n CONNECT BY grantee = prior granted_role;\n\n To list all administrative privileges granted to users via roles, run the query:\n SELECT\n username,\n rp.granted_role,\n privilege\n FROM\n dba_users u,\n dba_role_privs rp,\n dba_sys_privs sp\n WHERE username = rp.grantee\n AND rp.granted_role = sp.grantee\n AND privilege NOT IN\n (\n 'CREATE SEQUENCE', 'CREATE TRIGGER',\n 'SET CONTAINER', 'CREATE CLUSTER',\n 'CREATE PROCEDURE', 'CREATE TYPE',\n 'CREATE SESSION', 'CREATE OPERATOR',\n 'CREATE TABLE', 'CREATE INDEXTYPE'\n )\n AND username NOT IN\n (\n 'XDB', 'SYSTEM', 'SYS', 'LBACSYS',\n 'DVSYS', 'DVF', 'SYSMAN_RO', 'SYSMAN_BIPLATFORM',\n 'SYSMAN_MDS', 'SYSMAN_OPSS', 'SYSMAN_STB', 'DBSNMP',\n 'SYSMAN', 'APEX_040200', 'WMSYS', 'SYSDG',\n 'SYSBACKUP', 'SPATIAL_WFS_ADMIN_USR',\n 'SPATIAL_CSW_ADMIN_US','GSMCATUSER',\n 'OLAPSYS', 'SI_INFORMTN_SCHEMA', 'OUTLN', 'ORDSYS',\n 'ORDDATA', 'OJVMSYS', 'ORACLE_OCM', 'MDSYS',\n 'ORDPLUGINS', 'GSMADMIN_INTERNAL', 'MDDATA',\n 'FLOWS_FILES', 'DIP', 'CTXSYS', 'AUDSYS', 'APPQOSSYS',\n 'APEX_PUBLIC_USER', 'ANONYMOUS',\n 'SPATIAL_CSW_ADMIN_USR', 'SYSKM',\n 'SYSMAN_TYPES', 'MGMT_VIEW', 'EUS_ENGINE_USER',\n 'EXFSYS', 'SYSMAN_APM','IX','OWBSYS'\n )\n ORDER by 1, 2, 3;\n\n (The list of special accounts that are excluded from this requirement may not\n be complete. It is expected that the DBA will edit the list to suit local\n circumstances, adding other special accounts as necessary, and removing any\n that are not supposed to be in use in the Oracle deployment that is under\n review. Similarly, the list of privileges excluded from the list may be\n modified according to circumstances.)\n\n Data Dictionary Objects Related To System Privileges:\n all_sys_privs\n session_privs\n user_sys_privs\n dba_sys_privs\n system_privilege_map\"\n tag \"fix\": \"Remove permissions from DBAs and other administrative users\n beyond those required for administrative functions.\"\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_admin_privs = sql.query(\"SELECT\n username,\n rp.granted_role,\n privilege\n FROM\n dba_users u,\n dba_role_privs rp,\n dba_sys_privs sp\n WHERE username = rp.grantee\n AND rp.granted_role = sp.grantee\n AND privilege NOT IN\n (\n 'CREATE SEQUENCE', 'CREATE TRIGGER',\n 'SET CONTAINER', 'CREATE CLUSTER',\n 'CREATE PROCEDURE', 'CREATE TYPE',\n 'CREATE SESSION', 'CREATE OPERATOR',\n 'CREATE TABLE', 'CREATE INDEXTYPE'\n )\n AND username NOT IN\n (\n 'XDB', 'SYSTEM', 'SYS', 'LBACSYS',\n 'DVSYS', 'DVF', 'SYSMAN_RO', 'SYSMAN_BIPLATFORM',\n 'SYSMAN_MDS', 'SYSMAN_OPSS', 'SYSMAN_STB', 'DBSNMP',\n 'SYSMAN', 'APEX_040200', 'WMSYS', 'SYSDG',\n 'SYSBACKUP', 'SPATIAL_WFS_ADMIN_USR',\n 'SPATIAL_CSW_ADMIN_US','GSMCATUSER',\n 'OLAPSYS', 'SI_INFORMTN_SCHEMA', 'OUTLN', 'ORDSYS',\n 'ORDDATA', 'OJVMSYS', 'ORACLE_OCM', 'MDSYS',\n 'ORDPLUGINS', 'GSMADMIN_INTERNAL', 'MDDATA',\n 'FLOWS_FILES', 'DIP', 'CTXSYS', 'AUDSYS', 'APPQOSSYS',\n 'APEX_PUBLIC_USER', 'ANONYMOUS',\n 'SPATIAL_CSW_ADMIN_USR', 'SYSKM',\n 'SYSMAN_TYPES', 'MGMT_VIEW', 'EUS_ENGINE_USER',\n 'EXFSYS', 'SYSMAN_APM','IX','OWBSYS'\n )\n ORDER by 1, 2, 3;\").column('username').uniq\n if users_with_admin_privs.empty?\n impact 0.0\n describe 'There are no oracle database users with administative privileges, control N/A' do\n skip 'There are no oracle database users with administative privileges, control N/A'\n end\n else\n users_with_admin_privs.each do |user|\n describe \"oracle database users: #{user} with administative privileges\" do\n subject { user }\n it { should be_in input('allowed_users_with_admin_privs')}\n end\n end\n end\nend\n", + "code": "control 'V-61745' do\n title \"Processes (services, applications, etc.) that connect to the DBMS\n independently of individual users, must use valid, current DoD-issued PKI\n certificates for authentication to the DBMS.\"\n desc \"Just as individual users must be authenticated, and just as they must\n use PKI-based authentication, so must any processes that connect to the DBMS.\n\n The DoD standard for authentication of a process or device communicating\n with another process or device is the presentation of a valid, current,\n DoD-issued Public Key Infrastructure (PKI) certificate that has previously been\n verified as Trusted by an administrator of the other process or device.\n\n This applies both to processes that run on the same server as the DBMS and\n to processes running on other computers.\n\n The Oracle-supplied accounts, SYS, SYSBACKUP, SYSDG, and SYSKM, are\n exceptions. These cannot currently use certificate-based authentication. For\n this reason among others, use of these accounts should be restricted to where\n it is truly needed.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000177-DB-000069'\n tag \"gid\": 'V-61745'\n tag \"rid\": 'SV-76235r2_rule'\n tag \"stig_id\": 'O121-C2-015501'\n tag \"fix_id\": 'F-67661r1_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 configuration to confirm that accounts used by processes\n to connect to the DBMS are authenticated using valid, current DoD-issued PKI\n certificates.\n\n If any such account (other than SYS, SYSBACKUP, SYSDG, and SYSKM) is not\n certificate-based, this is a finding.\"\n tag \"fix\": 'For each such account, use DoD certificate-based authentication.'\n describe 'A manual review is required to ensure processes (services, applications, etc.) that connect to the DBMS\n independently of individual users, must use valid, current DoD-issued PKI\n certificates for authentication to the DBMS' do\n skip 'A manual review is required to ensure processes (services, applications, etc.) that connect to the DBMS\n independently of individual users, must use valid, current DoD-issued PKI\n certificates for authentication to the DBMS'\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61599.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61745.rb", "line": 1 }, - "id": "V-61599" + "id": "V-61745" }, { - "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.", + "title": "The DBMS must restrict error messages so only authorized personnel may\n view them.", + "desc": "If the application provides too much information in error logs and\n administrative messages to the screen, this could lead to compromise. The\n structure and content of error messages need to be carefully considered by the\n organization and development team. The extent to which the information system\n is able to identify and handle error conditions is guided by organizational\n policy and operational requirements.\n\n Some default DBMS error messages can contain information that could aid an\n attacker in, among others things, identifying the database type, host address,\n or state of the database. Custom errors may contain sensitive customer\n information. It is important that error messages are displayed only to those\n who are authorized to view them.\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": "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." + "default": "If the application provides too much information in error logs and\n administrative messages to the screen, this could lead to compromise. The\n structure and content of error messages need to be carefully considered by the\n organization and development team. The extent to which the information system\n is able to identify and handle error conditions is guided by organizational\n policy and operational requirements.\n\n Some default DBMS error messages can contain information that could aid an\n attacker in, among others things, identifying the database type, host address,\n or state of the database. Custom errors may contain sensitive customer\n information. It is important that error messages are displayed only to those\n who are authorized to view them.\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, - "refs": [ - { - "ref": [] - } - ], + "impact": 0.5, + "refs": [], "tags": { - "gtitle": "SRG-APP-000196-DB-000140", - "gid": "V-61759", - "rid": "SV-76249r3_rule", - "stig_id": "O121-C2-016600", - "fix_id": "F-67675r2_fix", + "gtitle": "SRG-APP-000267-DB-000163", + "gid": "V-61793", + "rid": "SV-76283r2_rule", + "stig_id": "O121-C2-020000", + "fix_id": "F-67709r2_fix", "cci": [ - "CCI-002450" + "CCI-001314" ], "nist": [ - "SC-13", + "SI-11 b", "Rev_4" ], "false_negatives": null, @@ -603,35 +601,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "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)." + "check": "Check DBMS settings and custom database code to determine if\n error messages are ever displayed to unauthorized individuals:\n\n i) Review all end-user-facing applications that use the database, to determine\n whether they display any DBMS-generated error messages to general users. If\n they do, this is a finding.\n\n ii) Review whether the database is accessible to users who are not authorized\n system administrators or database administrators, via the following types of\n software:\n iia) Oracle SQL*Plus\n iib) Reporting and analysis tools\n iic) Database management and/or development tools, such as, but not limited to,\n Toad.\n iid) Application development tools, such as, but not limited to, Oracle\n JDeveloper, Microsoft Visual Studio, PowerBuilder, or Eclipse.\n\n If the answer to the preceding question (iia through iid) is Yes, inquire\n whether, for each role or individual with respect to each tool, this access is\n required to enable the user(s) to perform authorized job duties. If No, this\n is a finding. If Yes, continue:\n\n For each tool in use, determine whether it is capable of suppressing\n DBMS-generated error messages, and if it is, whether it is configured to do so.\n\n Determine whether the role or individual, with respect to each tool, needs to\n see detailed DBMS-generated error messages.\n\n If No, and if the tool is not configured to suppress such messages, this is a\n finding.\n\n If Yes, determine whether the role/user's need to see such messages is\n documented in the System Security Plan. If so, this is not a finding. If not,\n this is a finding.", + "fix": "i) For each end-user-facing application that displays\n DBMS-generated error messages, configure or recode it to suppress these\n messages.\n\n If the application is coded in Oracle PL/SQL, the EXCEPTION block can be used\n to suppress or divert error messages. Most other programming languages provide\n comparable facilities, such as TRY ... CATCH.\n\n ii) For each unauthorized user of each tool, remove the ability to access it.\n For each tool where access to DBMS error messages is not required and can be\n configured, suppress the messages. For each role/user that needs access to the\n error messages, or needs a tool where the messages cannot be suppressed,\n document the need in the system security plan." }, - "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", + "code": "control 'V-61793' do\n title \"The DBMS must restrict error messages so only authorized personnel may\n view them.\"\n desc \"If the application provides too much information in error logs and\n administrative messages to the screen, this could lead to compromise. The\n structure and content of error messages need to be carefully considered by the\n organization and development team. The extent to which the information system\n is able to identify and handle error conditions is guided by organizational\n policy and operational requirements.\n\n Some default DBMS error messages can contain information that could aid an\n attacker in, among others things, identifying the database type, host address,\n or state of the database. Custom errors may contain sensitive customer\n information. It is important that error messages are displayed only to those\n who are authorized to view them.\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-000267-DB-000163'\n tag \"gid\": 'V-61793'\n tag \"rid\": 'SV-76283r2_rule'\n tag \"stig_id\": 'O121-C2-020000'\n tag \"fix_id\": 'F-67709r2_fix'\n tag \"cci\": ['CCI-001314']\n tag \"nist\": ['SI-11 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\": \"Check DBMS settings and custom database code to determine if\n error messages are ever displayed to unauthorized individuals:\n\n i) Review all end-user-facing applications that use the database, to determine\n whether they display any DBMS-generated error messages to general users. If\n they do, this is a finding.\n\n ii) Review whether the database is accessible to users who are not authorized\n system administrators or database administrators, via the following types of\n software:\n iia) Oracle SQL*Plus\n iib) Reporting and analysis tools\n iic) Database management and/or development tools, such as, but not limited to,\n Toad.\n iid) Application development tools, such as, but not limited to, Oracle\n JDeveloper, Microsoft Visual Studio, PowerBuilder, or Eclipse.\n\n If the answer to the preceding question (iia through iid) is Yes, inquire\n whether, for each role or individual with respect to each tool, this access is\n required to enable the user(s) to perform authorized job duties. If No, this\n is a finding. If Yes, continue:\n\n For each tool in use, determine whether it is capable of suppressing\n DBMS-generated error messages, and if it is, whether it is configured to do so.\n\n Determine whether the role or individual, with respect to each tool, needs to\n see detailed DBMS-generated error messages.\n\n If No, and if the tool is not configured to suppress such messages, this is a\n finding.\n\n If Yes, determine whether the role/user's need to see such messages is\n documented in the System Security Plan. If so, this is not a finding. If not,\n this is a finding.\"\n tag \"fix\": \"i) For each end-user-facing application that displays\n DBMS-generated error messages, configure or recode it to suppress these\n messages.\n\n If the application is coded in Oracle PL/SQL, the EXCEPTION block can be used\n to suppress or divert error messages. Most other programming languages provide\n comparable facilities, such as TRY ... CATCH.\n\n ii) For each unauthorized user of each tool, remove the ability to access it.\n For each tool where access to DBMS error messages is not required and can be\n configured, suppress the messages. For each role/user that needs access to the\n error messages, or needs a tool where the messages cannot be suppressed,\n document the need in the system security plan.\"\n describe 'A manual review is required to ensure the DBMS restricts error messages so only authorized personnel may\n view them' do\n skip 'A manual review is required to ensure the DBMS restricts error messages so only authorized personnel may\n view them'\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61759.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61793.rb", "line": 1 }, - "id": "V-61759" + "id": "V-61793" }, { - "title": "The DBMS must employ strong identification and authentication\n techniques when establishing nonlocal maintenance and diagnostic sessions.", - "desc": "Non-local maintenance and diagnostic activities are those activities\n conducted by individuals communicating through a network, either an external\n network (e.g., the Internet) or an internal network.\n\n The act of managing systems and applications includes the ability to access\n sensitive application information, such as system configuration details,\n diagnostic information, user information, and potentially sensitive application\n data.\n\n When applications provide a remote management capability inherent to the\n application, the application needs to ensure the identification and\n authentication techniques used to remotely access the system are strong enough\n to protect the system. If the communication channel is not adequately\n protected, authentication information, application data, and configuration\n information could be compromised.", + "title": "Changes to DBMS security labels must be audited.", + "desc": "Some DBMS systems provide the feature to assign security labels to\n data elements. If labeling is required, implementation options include the\n Oracle Label Security package, or a third-party product, or custom-developed\n functionality. The confidentiality and integrity of the data depends upon the\n security label assignment where this feature is in use. Changes to security\n label assignment may indicate suspicious activity.", "descriptions": { - "default": "Non-local maintenance and diagnostic activities are those activities\n conducted by individuals communicating through a network, either an external\n network (e.g., the Internet) or an internal network.\n\n The act of managing systems and applications includes the ability to access\n sensitive application information, such as system configuration details,\n diagnostic information, user information, and potentially sensitive application\n data.\n\n When applications provide a remote management capability inherent to the\n application, the application needs to ensure the identification and\n authentication techniques used to remotely access the system are strong enough\n to protect the system. If the communication channel is not adequately\n protected, authentication information, application data, and configuration\n information could be compromised." + "default": "Some DBMS systems provide the feature to assign security labels to\n data elements. If labeling is required, implementation options include the\n Oracle Label Security package, or a third-party product, or custom-developed\n functionality. The confidentiality and integrity of the data depends upon the\n security label assignment where this feature is in use. Changes to security\n label assignment may indicate suspicious activity." }, "impact": 0.5, "refs": [], "tags": { - "gtitle": "SRG-APP-000185-DB-000116", - "gid": "V-61751", - "rid": "SV-76241r1_rule", - "stig_id": "O121-C2-016100", - "fix_id": "F-67667r1_fix", + "gtitle": "SRG-APP-000516-DB-999900", + "gid": "V-61527", + "rid": "SV-76017r4_rule", + "stig_id": "O121-BP-026200", + "fix_id": "F-67443r2_fix", "cci": [ - "CCI-000877" + "CCI-000366" ], "nist": [ - "MA-4 c)", + "CM-6 b", "Rev_4" ], "false_negatives": null, @@ -644,35 +642,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Review DBMS settings to determine whether strong identification\n and authentication techniques are required for nonlocal maintenance and\n diagnostic sessions.\n\n If strong identification and authentication techniques are not required, this\n is a finding.", - "fix": "Configure DBMS settings to use strong identification and\n authentication techniques for nonlocal maintenance and diagnostic sessions." + "check": "If no data is identified as being sensitive or classified by\n the Information Owner, in the System Security Plan or in the AIS Functional\n Architecture documentation, this is not a finding.\n\n If security labeling is not required, this is not a finding.\n\n If Standard Auditing is used, run the SQL query:\n\n select * from dba_sa_audit_options;\n\n If no records are returned or if output from the SQL statement above does not\n show classification labels being audited as required in the System Security\n Plan, this is a finding.\n\n If Unified Auditing is used:\n To see if Oracle is configured to capture audit data including changes to\n security label assignment, enter the following SQL*Plus command:\n SELECT 'Changes to security label assignment 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 = 'ALL'\n AND audit_option_type = 'OLS ACTION'\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\n To confirm that Oracle audit is capturing sufficient information to establish\n that changes to classification labels are being audited, perform a successful\n auditable action and an auditable action that results in an SQL error, and then\n view the results in the SYS.UNIFIED_AUDIT_TRAIL view.\n\n If no ACTION#, or the wrong value, is returned for the auditable actions, this\n is a finding.", + "fix": "Define the policy for auditing changes to security labels defined\n for the data.\n\n Document the audit requirements in the System Security Plan and configure\n database auditing in accordance with the policy.\n\n If using Standard Auditing:\n If there is no Unified Auditing policy deployed to audit changes to security\n labels, the create one using the following syntax:\n SA_AUDIT_ADMIN.AUDIT (\n policy_name IN VARCHAR2,\n users IN VARCHAR2 DEFAULT NULL,\n audit_option IN VARCHAR2 DEFAULT NULL,\n audit_type IN VARCHAR2 DEFAULT NULL,\n success IN VARCHAR2 DEFAULT NULL);\n\n For additional information on creating audit policies, refer to the Oracle\n Database Security Guide\n http://docs.oracle.com/database/121/OLSAG/packages.htm#i1011868\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.\n Reference V-61625 for information on how to configure a policy to audit changes\n to security label assignments.\n\n For additional information on creating audit policies, refer to the Oracle\n Database Security Guide\n http://docs.oracle.com/database/121/DBSEG/audit_config.htm#CHDGBAAC" }, - "code": "control 'V-61751' do\n title \"The DBMS must employ strong identification and authentication\n techniques when establishing nonlocal maintenance and diagnostic sessions.\"\n desc \"Non-local maintenance and diagnostic activities are those activities\n conducted by individuals communicating through a network, either an external\n network (e.g., the Internet) or an internal network.\n\n The act of managing systems and applications includes the ability to access\n sensitive application information, such as system configuration details,\n diagnostic information, user information, and potentially sensitive application\n data.\n\n When applications provide a remote management capability inherent to the\n application, the application needs to ensure the identification and\n authentication techniques used to remotely access the system are strong enough\n to protect the system. If the communication channel is not adequately\n protected, authentication information, application data, and configuration\n information could be compromised.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000185-DB-000116'\n tag \"gid\": 'V-61751'\n tag \"rid\": 'SV-76241r1_rule'\n tag \"stig_id\": 'O121-C2-016100'\n tag \"fix_id\": 'F-67667r1_fix'\n tag \"cci\": ['CCI-000877']\n tag \"nist\": ['MA-4 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 DBMS settings to determine whether strong identification\n and authentication techniques are required for nonlocal maintenance and\n diagnostic sessions.\n\n If strong identification and authentication techniques are not required, this\n is a finding.\"\n tag \"fix\": \"Configure DBMS settings to use strong identification and\n authentication techniques for nonlocal maintenance and diagnostic sessions.\"\n describe 'A manual review is required to ensure the DBMS employs strong identification and authentication\n techniques when establishing nonlocal maintenance and diagnostic sessions' do\n skip 'A manual review is required to ensure the DBMS employs strong identification and authentication\n techniques when establishing nonlocal maintenance and diagnostic sessions'\n end\nend\n", + "code": "control 'V-61527' do\n title 'Changes to DBMS security labels must be audited.'\n desc \"Some DBMS systems provide the feature to assign security labels to\n data elements. If labeling is required, implementation options include the\n Oracle Label Security package, or a third-party product, or custom-developed\n functionality. The confidentiality and integrity of the data depends upon the\n security label assignment where this feature is in use. Changes to security\n label assignment may indicate suspicious activity.\"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000516-DB-999900'\n tag \"gid\": 'V-61527'\n tag \"rid\": 'SV-76017r4_rule'\n tag \"stig_id\": 'O121-BP-026200'\n tag \"fix_id\": 'F-67443r2_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 no data is identified as being sensitive or classified by\n the Information Owner, in the System Security Plan or in the AIS Functional\n Architecture documentation, this is not a finding.\n\n If security labeling is not required, this is not a finding.\n\n If Standard Auditing is used, run the SQL query:\n\n select * from dba_sa_audit_options;\n\n If no records are returned or if output from the SQL statement above does not\n show classification labels being audited as required in the System Security\n Plan, this is a finding.\n\n If Unified Auditing is used:\n To see if Oracle is configured to capture audit data including changes to\n security label assignment, enter the following SQL*Plus command:\n SELECT 'Changes to security label assignment 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 = 'ALL'\n AND audit_option_type = 'OLS ACTION'\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\n To confirm that Oracle audit is capturing sufficient information to establish\n that changes to classification labels are being audited, perform a successful\n auditable action and an auditable action that results in an SQL error, and then\n view the results in the SYS.UNIFIED_AUDIT_TRAIL view.\n\n If no ACTION#, or the wrong value, is returned for the auditable actions, this\n is a finding.\"\n tag \"fix\": \"Define the policy for auditing changes to security labels defined\n for the data.\n\n Document the audit requirements in the System Security Plan and configure\n database auditing in accordance with the policy.\n\n If using Standard Auditing:\n If there is no Unified Auditing policy deployed to audit changes to security\n labels, the create one using the following syntax:\n SA_AUDIT_ADMIN.AUDIT (\n policy_name IN VARCHAR2,\n users IN VARCHAR2 DEFAULT NULL,\n audit_option IN VARCHAR2 DEFAULT NULL,\n audit_type IN VARCHAR2 DEFAULT NULL,\n success IN VARCHAR2 DEFAULT NULL);\n\n For additional information on creating audit policies, refer to the Oracle\n Database Security Guide\n http://docs.oracle.com/database/121/OLSAG/packages.htm#i1011868\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.\n Reference V-61625 for information on how to configure a policy to audit changes\n to security label assignments.\n\n For additional information on creating audit policies, refer to the Oracle\n Database Security Guide\n http://docs.oracle.com/database/121/DBSEG/audit_config.htm#CHDGBAAC\"\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 'Changes to security label assignment 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 = 'ALL'\n AND audit_option_type = 'OLS ACTION'\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('Changes to security label assignment 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\n\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61751.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61527.rb", "line": 1 }, - "id": "V-61751" + "id": "V-61527" }, { - "title": "Fixed user and public database links must be authorized for use.", - "desc": "Database links define connections that may be used by the local\n database to access remote Oracle databases. These links provide a means for a\n compromise to the local database to spread to remote databases in the\n distributed database environment. Limiting or eliminating use of database links\n where they are not required to support the operational system can help isolate\n compromises to the local or a limited number of databases.", + "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.", "descriptions": { - "default": "Database links define connections that may be used by the local\n database to access remote Oracle databases. These links provide a means for a\n compromise to the local database to spread to remote databases in the\n distributed database environment. Limiting or eliminating use of database links\n where they are not required to support the operational system can help isolate\n compromises to the local or a limited number of databases." + "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." }, - "impact": 0, + "impact": 0.5, "refs": [], "tags": { - "gtitle": "SRG-APP-000516-DB-999900", - "gid": "V-61415", - "rid": "SV-75905r2_rule", - "stig_id": "O121-BP-021400", - "fix_id": "F-67331r1_fix", + "gtitle": "SRG-APP-000180-DB-000115", + "gid": "V-61881", + "rid": "SV-76371r1_rule", + "stig_id": "O121-P2-015800", + "fix_id": "F-67797r1_fix", "cci": [ - "CCI-000366" + "CCI-000804" ], "nist": [ - "CM-6 b", + "IA-8", "Rev_4" ], "false_negatives": null, @@ -685,35 +683,39 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "From SQL*Plus:\n\n select owner||': '||db_link from dba_db_links;\n\n If no records are returned from the first SQL statement, this check is not a\n finding.\n\n Confirm the public and fixed user database links listed are documented in the\n System Security Plan, are authorized by the ISSO, and are used for replication\n or operational system requirements.\n\n If any are not, this is a finding.\n ", - "fix": "Document all authorized connections from the database to remote\n databases in the System Security Plan.\n\n Remove all unauthorized remote database connection definitions from the\n database.\n\n From SQL*Plus:\n\n drop database link [link name];\n OR\n drop public database link [link name];\n\n Review remote database connection definitions periodically and confirm their\n use is still required and authorized." + "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." }, - "code": "control 'V-61415' do\n title 'Fixed user and public database links must be authorized for use.'\n desc \"Database links define connections that may be used by the local\n database to access remote Oracle databases. These links provide a means for a\n compromise to the local database to spread to remote databases in the\n distributed database environment. Limiting or eliminating use of database links\n where they are not required to support the operational system can help isolate\n compromises to the local or a limited number of databases.\"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000516-DB-999900'\n tag \"gid\": 'V-61415'\n tag \"rid\": 'SV-75905r2_rule'\n tag \"stig_id\": 'O121-BP-021400'\n tag \"fix_id\": 'F-67331r1_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 owner||': '||db_link from dba_db_links;\n\n If no records are returned from the first SQL statement, this check is not a\n finding.\n\n Confirm the public and fixed user database links listed are documented in the\n System Security Plan, are authorized by the ISSO, and are used for replication\n or operational system requirements.\n\n If any are not, this is a finding.\n \"\n tag \"fix\": \"Document all authorized connections from the database to remote\n databases in the System Security Plan.\n\n Remove all unauthorized remote database connection definitions from the\n database.\n\n From SQL*Plus:\n\n drop database link [link name];\n OR\n drop public database link [link name];\n\n Review remote database connection definitions periodically and confirm their\n use is still required and authorized.\"\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-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", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61415.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61881.rb", "line": 1 }, - "id": "V-61415" + "id": "V-61881" }, { - "title": "The DBMS must notify appropriate individuals when accounts are\n modified.", - "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 modify an existing account for later use.\n\n Notification of account creation is one method and best practice for\n mitigating this risk. A comprehensive account management process will ensure an\n audit trail which documents the creation of application user accounts and\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 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 accounts are\n directly managed by Oracle.\n\n Notwithstanding how accounts are normally managed, the DBMS must support\n the requirement to notify appropriate individuals upon account modification\n within Oracle. Indeed, in a configuration where accounts are managed\n externally, the manipulation of an account within Oracle may indicate hostile\n activity.", + "title": "The Oracle Listener must be configured to require administration\n authentication.", + "desc": "Oracle listener authentication helps prevent unauthorized\n administration of the Oracle listener. Unauthorized administration of the\n listener could lead to DoS exploits; loss of connection audit data,\n unauthorized reconfiguration or other unauthorized access. This is a Category I\n finding because privileged access to the listener is not restricted to\n authorized users. Unauthorized access can result in stopping of the listener\n (DoS) and overwriting of listener audit logs.", "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 modify an existing account for later use.\n\n Notification of account creation is one method and best practice for\n mitigating this risk. A comprehensive account management process will ensure an\n audit trail which documents the creation of application user accounts and\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 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 accounts are\n directly managed by Oracle.\n\n Notwithstanding how accounts are normally managed, the DBMS must support\n the requirement to notify appropriate individuals upon account modification\n within Oracle. Indeed, in a configuration where accounts are managed\n externally, the manipulation of an account within Oracle may indicate hostile\n activity." + "default": "Oracle listener authentication helps prevent unauthorized\n administration of the Oracle listener. Unauthorized administration of the\n listener could lead to DoS exploits; loss of connection audit data,\n unauthorized reconfiguration or other unauthorized access. This is a Category I\n finding because privileged access to the listener is not restricted to\n authorized users. Unauthorized access can result in stopping of the listener\n (DoS) and overwriting of listener audit logs." }, - "impact": 0.5, - "refs": [], + "impact": 0, + "refs": [ + { + "ref": [] + } + ], "tags": { - "gtitle": "SRG-APP-000292-DB-000138", - "gid": "V-61799", - "rid": "SV-76289r2_rule", - "stig_id": "O121-C2-020500", - "fix_id": "F-67715r1_fix", + "gtitle": "SRG-APP-000516-DB-999900", + "gid": "V-61441", + "rid": "SV-75931r2_rule", + "stig_id": "O121-BP-022700", + "fix_id": "F-67357r1_fix", "cci": [ - "CCI-001684" + "CCI-000366" ], "nist": [ - "AC-2 (4)", + "CM-6 b", "Rev_4" ], "false_negatives": null, @@ -726,35 +728,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Check DBMS settings to determine whether it will notify\n appropriate individuals when accounts are modified.\n\n If the DBMS does not notify appropriate individuals when accounts are modified,\n this is a finding.", - "fix": "Working with the DBA and site management, determine the\n appropriate individuals (by job role) to be notified.\n\n If Oracle Audit Vault is available, configure it to notify the appropriate\n individuals when accounts are modified.\n\n If Oracle Audit Vault is not available, configure the Oracle DBMS's auditing\n feature to record account-modification activity.\n\n If Standard Auditing is used:\n Create and deploy a mechanism, such as a frequently-run job, to monitor the\n SYS.AUD$ table for these records and notify the appropriate individuals.\n\n If unified Auditing is used:\n Create and deploy a mechanism, such as a frequently-run job, to monitor the\n SYS.UNIFIED_AUDIT_TRAIL view for these records and notify the appropriate\n individuals." + "check": "If a listener is not running on the local database host server,\n this check is not a finding.\n\n Note: This check needs to be done only once per host system and once per\n listener. Multiple listeners may be defined on a single host system. They must\n all be reviewed, but only once per database home review.\n\n For subsequent database home reviews on the same host system, this check is not\n a finding.\n\n Determine all Listeners running on the host.\n\n For Windows hosts, view all Windows services with TNSListener embedded in the\n service name\n - The service name format is:\n Oracle[ORACLE_HOME_NAME]TNSListener\n\n For UNIX hosts, the Oracle Listener process will indicate the TNSLSNR\n executable.\n\n At a command prompt, issue the command:\n ps -ef | grep tnslsnr | grep -v grep\n\n The alias for the listener follows tnslsnr in the command output.\n\n Must be logged on the host system using the account that owns the tnslsnr\n executable (UNIX). If the account is denied local logon, have the system SA\n assist in this task by adding 'su' to the listener account from the root\n account. On Windows platforms, log on using an account with administrator\n privileges to complete the check.\n\n From a system command prompt, execute the listener control utility:\n\n lsnrctl status [LISTENER NAME]\n\n Review the results for the value of Security.\n\n If \"Security = OFF\" is displayed, this is a finding.\n\n If \"Security = ON: Local OS Authentication\" is displayed, this is not a\n finding.\n\n If \"Security = ON: Password or Local OS Authentication\", this is a finding\n (do not set a password on Oracle versions 10.1 and higher. Instead, use Local\n OS Authentication).\n\n Repeat the execution of the lsnrctl utility for all active listeners.", + "fix": "By default, Oracle Net Listener permits only local administration\n for security reasons. As a policy, the listener can be administered only by the\n user who started it. This is enforced through local operating system\n authentication. For example, if user1 starts the listener, then only user1 can\n administer it. Any other user trying to administer the listener gets an error.\n The super user is the only exception.\n\n Remote administration of the listener must not be permitted. If listener\n administration from a remote system is required, granting secure remote access\n to the Oracle DBMS server and performing local administration is preferred.\n Authorize and document this requirement in the System Security Plan.\n\n Note: In Oracle Database 12c Release 1 (12.1), the listener password feature is\n no longer supported. This does not cause a loss of security because\n authentication is enforced through local operating system authentication. Refer\n to Oracle Database Net Services Reference for additional information." }, - "code": "control 'V-61799' do\n title \"The DBMS must notify appropriate individuals when accounts are\n modified.\"\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 modify an existing account for later use.\n\n Notification of account creation is one method and best practice for\n mitigating this risk. A comprehensive account management process will ensure an\n audit trail which documents the creation of application user accounts and\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 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 accounts are\n directly managed by Oracle.\n\n Notwithstanding how accounts are normally managed, the DBMS must support\n the requirement to notify appropriate individuals upon account modification\n within Oracle. Indeed, in a configuration where accounts are managed\n externally, the manipulation of an account within Oracle may indicate hostile\n activity.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000292-DB-000138'\n tag \"gid\": 'V-61799'\n tag \"rid\": 'SV-76289r2_rule'\n tag \"stig_id\": 'O121-C2-020500'\n tag \"fix_id\": 'F-67715r1_fix'\n tag \"cci\": ['CCI-001684']\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 DBMS settings to determine whether it will notify\n appropriate individuals when accounts are modified.\n\n If the DBMS does not notify appropriate individuals when accounts are modified,\n this is a finding.\"\n tag \"fix\": \"Working with the DBA and site management, determine the\n appropriate individuals (by job role) to be notified.\n\n If Oracle Audit Vault is available, configure it to notify the appropriate\n individuals when accounts are modified.\n\n If Oracle Audit Vault is not available, configure the Oracle DBMS's auditing\n feature to record account-modification activity.\n\n If Standard Auditing is used:\n Create and deploy a mechanism, such as a frequently-run job, to monitor the\n SYS.AUD$ table for these records and notify the appropriate individuals.\n\n If unified Auditing is used:\n Create and deploy a mechanism, such as a frequently-run job, to monitor the\n SYS.UNIFIED_AUDIT_TRAIL view for these records and notify the appropriate\n individuals.\"\n describe 'A manual review is required to ensure the DBMS notifies the appropriate individuals when accounts are\n modified' do\n skip 'A manual review is required to ensure the DBMS notifies the appropriate individuals when accounts are\n modified'\n end\nend\n", + "code": " control 'V-61441' 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-61799.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61441.rb", "line": 1 }, - "id": "V-61799" + "id": "V-61441" }, { - "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 system must protect audit tools from unauthorized deletion.", + "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 It is, therefore, imperative that access to audit tools be controlled and\n protected from unauthorized access.\n\n Applications providing tools to interface with audit data will leverage\n user permissions and roles identifying the user accessing the tools and the\n corresponding rights the user enjoys in order make access decisions regarding\n the access to audit tools.\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": "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": "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 It is, therefore, imperative that access to audit tools be controlled and\n protected from unauthorized access.\n\n Applications providing tools to interface with audit data will leverage\n user permissions and roles identifying the user accessing the tools and the\n corresponding rights the user enjoys in order make access decisions regarding\n the access to audit tools.\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.5, + "impact": 0, "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-000123-DB-000204", + "gid": "V-61663", + "rid": "SV-76153r1_rule", + "stig_id": "O121-C2-009800", + "fix_id": "F-67577r1_fix", "cci": [ - "CCI-001403" + "CCI-001495" ], "nist": [ - "AC-2 (4)", + "AU-9", "Rev_4" ], "false_negatives": null, @@ -767,35 +769,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 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 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 deletion 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. Only authorized personnel must be able to delete\n these tools." }, - "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-61663' do\n title 'The system must protect audit tools from unauthorized deletion.'\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 It is, therefore, imperative that access to audit tools be controlled and\n protected from unauthorized access.\n\n Applications providing tools to interface with audit data will leverage\n user permissions and roles identifying the user accessing the tools and the\n corresponding rights the user enjoys in order make access decisions regarding\n the access to audit tools.\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-000123-DB-000204'\n tag \"gid\": 'V-61663'\n tag \"rid\": 'SV-76153r1_rule'\n tag \"stig_id\": 'O121-C2-009800'\n tag \"fix_id\": 'F-67577r1_fix'\n tag \"cci\": ['CCI-001495']\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 deletion 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. Only authorized personnel must be able to delete\n these tools.\"\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-61569.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61663.rb", "line": 1 }, - "id": "V-61569" + "id": "V-61663" }, { - "title": "The DBMS must generate audit records for the DoD-selected list of\n auditable events, to the extent such information is available.", - "desc": "Audit records can be generated from various components within the\n information system, such as network interfaces, hard disks, modems, etc. From\n an application perspective, certain specific application functionalities may be\n audited, as well.\n\n The list of audited events is the set of events for which audits are to be\n generated. This set of events is typically a subset of the list of all events\n for which the system is capable of generating audit records (i.e., auditable\n events, timestamps, source and destination addresses, user/process identifiers,\n event descriptions, success/fail indications, file names involved, and access\n control or flow control rules invoked).\n\n Organizations may define the organizational personnel accountable for\n determining which application components shall provide auditable events.\n\n Auditing provides accountability for changes made to the DBMS configuration\n or its objects and data. It provides a means to discover suspicious activity\n and unauthorized changes. Without auditing, a compromise may go undetected and\n without a means to determine accountability.\n\n The Department of Defense has established the following as the minimum set\n of auditable events. Most can be audited via Oracle settings; some - marked\n here with an asterisk - cannot, and may require OS settings.\n - Successful and unsuccessful attempts to access, modify, or delete\n privileges, security objects, security levels, or categories of information\n (e.g. classification levels).\n - Successful and unsuccessful logon attempts, privileged activities or\n other system level access\n - Starting and ending time for user access to the system, concurrent logons\n from different workstations.\n - Successful and unsuccessful accesses to objects.\n - All program initiations.\n - *All direct access to the information system.\n - All account creations, modifications, disabling, and terminations.\n - *All kernel module loads, unloads, and restarts.", + "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.", "descriptions": { - "default": "Audit records can be generated from various components within the\n information system, such as network interfaces, hard disks, modems, etc. From\n an application perspective, certain specific application functionalities may be\n audited, as well.\n\n The list of audited events is the set of events for which audits are to be\n generated. This set of events is typically a subset of the list of all events\n for which the system is capable of generating audit records (i.e., auditable\n events, timestamps, source and destination addresses, user/process identifiers,\n event descriptions, success/fail indications, file names involved, and access\n control or flow control rules invoked).\n\n Organizations may define the organizational personnel accountable for\n determining which application components shall provide auditable events.\n\n Auditing provides accountability for changes made to the DBMS configuration\n or its objects and data. It provides a means to discover suspicious activity\n and unauthorized changes. Without auditing, a compromise may go undetected and\n without a means to determine accountability.\n\n The Department of Defense has established the following as the minimum set\n of auditable events. Most can be audited via Oracle settings; some - marked\n here with an asterisk - cannot, and may require OS settings.\n - Successful and unsuccessful attempts to access, modify, or delete\n privileges, security objects, security levels, or categories of information\n (e.g. classification levels).\n - Successful and unsuccessful logon attempts, privileged activities or\n other system level access\n - Starting and ending time for user access to the system, concurrent logons\n from different workstations.\n - Successful and unsuccessful accesses to objects.\n - All program initiations.\n - *All direct access to the information system.\n - All account creations, modifications, disabling, and terminations.\n - *All kernel module loads, unloads, and restarts." + "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." }, "impact": 0.5, "refs": [], "tags": { - "gtitle": "SRG-APP-000091-DB-000066", - "gid": "V-61625", - "rid": "SV-76115r3_rule", - "stig_id": "O121-C2-007000", - "fix_id": "F-67541r1_fix", + "gtitle": "SRG-APP-000024-DB-000003", + "gid": "V-61561", + "rid": "SV-76051r3_rule", + "stig_id": "O121-C2-002000", + "fix_id": "F-67477r1_fix", "cci": [ - "CCI-000172" + "CCI-000016" ], "nist": [ - "AU-12 c", + "AC-2 (2)", "Rev_4" ], "false_negatives": null, @@ -808,35 +810,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Check DBMS settings to determine if auditing is being performed\n on the events on the DoD-selected list of auditable events that lie within the\n scope of Oracle audit capabilities:\n - Successful and unsuccessful attempts to access, modify, or delete privileges,\n security objects, security levels, or categories of information (e.g.,\n classification levels).\n - Successful and unsuccessful logon attempts, privileged activities or other\n system-level access\n - Starting and ending time for user access to the system, concurrent logons\n from different workstations.\n - Successful and unsuccessful accesses to objects.\n - All program initiations.\n - All account creations, modifications, disabling, and terminations.\n\n If auditing is not being performed for any of these events, this is a finding.\n\n Notes on Oracle audit capabilities follow.\n\n Unified Audit supports named audit policies, which are defined using the CREATE\n AUDIT POLICY statement. A policy specifies the actions that should be audited\n and the objects to which it should apply. If no specific objects are included\n in the policy definition, it applies to all objects.\n\n A named policy is enabled using the AUDIT POLICY statement. It can be enabled\n for all users, for specific users only, or for all except a specified list of\n users. The policy can audit successful actions, unsuccessful actions, or both.\n\n Verifying existing audit policy: existing Unified Audit policies are listed in\n the view AUDIT_UNIFIED_POLICIES. The AUDIT_OPTION column contains one of the\n actions specified in a CREATE AUDIT POLICY statement. The AUDIT_OPTION_TYPE\n column contains 'STANDARD ACTION' for a policy that applies to all objects or\n 'OBJECT ACTION' for a policy that audits actions on a specific object.\n\n select POLICY_NAME from SYS.AUDIT_UNIFIED_POLICIES where AUDIT_OPTION='GRANT'\n and AUDIT_OPTION_TYPE='STANDARD ACTION';\n\n To find policies that audit privilege grants on specific objects:\n\n select POLICY_NAME,OBJECT_SCHEMA,OBJECT_NAME from SYS.AUDIT_UNIFIED_POLICIES\n where AUDIT_OPTION='GRANT' and AUDIT_OPTION_TYPE='OBJECT ACTION';\n\n The view AUDIT_UNIFIED_ENABLED_POLICIES shows which Unified Audit policies are\n enabled. The ENABLED_OPT and USER_NAME columns show the users for whom the\n policy is enabled or 'ALL USERS'. The SUCCESS and FAILURE columns indicate if\n the policy is enabled for successful or unsuccessful actions, respectively.\n\n select POLICY_NAME,ENABLED_OPT,USER_NAME,SUCCESS,FAILURE from\n SYS.AUDIT_UNIFIED_ENABLED_POLICIES where POLICY_NAME='POLICY1';", - "fix": "Configure the DBMS's auditing settings to include auditing of\n events on the DoD-selected list of auditable events.\n\n 1) Successful and unsuccessful attempts to access, modify, or delete\n privileges, security objects, security levels, or categories of information\n (e.g., classification levels)\n\n To audit granting and revocation of any privilege:\n create audit policy policy1 actions grant;\n create audit policy policy2 actions revoke;\n\n To audit grants of object privileges on a specific object:\n create audit policy policy3 actions grant on .;\n\n If Oracle Label Security is enabled, this will audit all OLS administrative\n actions:\n create audit policy policy4 actions component = OLS all;\n\n 2) Successful and unsuccessful logon attempts, privileged activities or other\n system-level access\n\n To audit all user logon attempts:\n create audit policy policy5 actions logon;\n\n To audit only logon attempts using administrative privileges (e.g. AS SYSDBA):\n audit policy policy5 by SYS, SYSOPER, SYSBACKUP, SYSDG, SYSKM;\n\n 3) Starting and ending time for user access to the system, concurrent logons\n from different workstations\n\n This policy will audit all logon and logoff events. An individual session is\n identified in the UNIFIED_AUDIT_TRAIL by the tuple (DBID, INSTANCE_ID,\n SESSIONID) and the start and end time will be indicated by the EVENT_TIMESTAMP\n of the logon and logoff events:\n create audit policy policy6 actions logon, logoff;\n\n 4) Successful and unsuccessful accesses to objects\n\n To audit all accesses to a specific table:\n create audit policy policy7 actions select, insert, delete, alter on\n .;\n\n Different actions are defined for other object types. To audit all supported\n actions on a specific object:\n create audit policy policy8 actions all on .;\n\n 5) All program initiations\n\n To audit execution of any PL/SQL program unit:\n create audit policy policy9 actions EXECUTE;\n\n To audit execution of a specific function, procedure, or package:\n create audit policy policy10 actions EXECUTE on .;\n\n 6) All direct access to the information system\n\n [Not applicable to Database audit. Monitor using OS auditing.]\n\n 7) All account creations, modifications, disabling, and terminations\n\n To audit all user administration actions:\n create audit policy policy11 actions create user, alter user, drop user, change\n password;\n\n 8) All kernel module loads, unloads, and restarts\n\n [Not applicable to Database audit. Monitor using OS auditing.]\n\n 9) All database parameter changes\n\n To audit any database parameter changes, dynamic or static:\n create audit policy policy12 actions alter database, alter system, create\n spfile;\n\n Applying the Policy\n\n The following command will enable the policy in all database sessions and audit\n both successful and unsuccessful actions:\n audit policy policy1;\n\n To audit only unsuccessful actions, add the WHENEVER NOT SUCCESSFUL modifier:\n audit policy policy1 whenever not successful;\n\n Either command above can be limited to only database sessions started by a\n specific user as follows:\n audit policy policy1 by ;\n audit policy policy1 by whenever not successful;" + "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." }, - "code": "control 'V-61625' do\n title \"The DBMS must generate audit records for the DoD-selected list of\n auditable events, to the extent such information is available.\"\n desc \"Audit records can be generated from various components within the\n information system, such as network interfaces, hard disks, modems, etc. From\n an application perspective, certain specific application functionalities may be\n audited, as well.\n\n The list of audited events is the set of events for which audits are to be\n generated. This set of events is typically a subset of the list of all events\n for which the system is capable of generating audit records (i.e., auditable\n events, timestamps, source and destination addresses, user/process identifiers,\n event descriptions, success/fail indications, file names involved, and access\n control or flow control rules invoked).\n\n Organizations may define the organizational personnel accountable for\n determining which application components shall provide auditable events.\n\n Auditing provides accountability for changes made to the DBMS configuration\n or its objects and data. It provides a means to discover suspicious activity\n and unauthorized changes. Without auditing, a compromise may go undetected and\n without a means to determine accountability.\n\n The Department of Defense has established the following as the minimum set\n of auditable events. Most can be audited via Oracle settings; some - marked\n here with an asterisk - cannot, and may require OS settings.\n - Successful and unsuccessful attempts to access, modify, or delete\n privileges, security objects, security levels, or categories of information\n (e.g. classification levels).\n - Successful and unsuccessful logon attempts, privileged activities or\n other system level access\n - Starting and ending time for user access to the system, concurrent logons\n from different workstations.\n - Successful and unsuccessful accesses to objects.\n - All program initiations.\n - *All direct access to the information system.\n - All account creations, modifications, disabling, and terminations.\n - *All kernel module loads, unloads, and restarts.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000091-DB-000066'\n tag \"gid\": 'V-61625'\n tag \"rid\": 'SV-76115r3_rule'\n tag \"stig_id\": 'O121-C2-007000'\n tag \"fix_id\": 'F-67541r1_fix'\n tag \"cci\": ['CCI-000172']\n tag \"nist\": ['AU-12 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\": \"Check DBMS settings to determine if auditing is being performed\n on the events on the DoD-selected list of auditable events that lie within the\n scope of Oracle audit capabilities:\n - Successful and unsuccessful attempts to access, modify, or delete privileges,\n security objects, security levels, or categories of information (e.g.,\n classification levels).\n - Successful and unsuccessful logon attempts, privileged activities or other\n system-level access\n - Starting and ending time for user access to the system, concurrent logons\n from different workstations.\n - Successful and unsuccessful accesses to objects.\n - All program initiations.\n - All account creations, modifications, disabling, and terminations.\n\n If auditing is not being performed for any of these events, this is a finding.\n\n Notes on Oracle audit capabilities follow.\n\n Unified Audit supports named audit policies, which are defined using the CREATE\n AUDIT POLICY statement. A policy specifies the actions that should be audited\n and the objects to which it should apply. If no specific objects are included\n in the policy definition, it applies to all objects.\n\n A named policy is enabled using the AUDIT POLICY statement. It can be enabled\n for all users, for specific users only, or for all except a specified list of\n users. The policy can audit successful actions, unsuccessful actions, or both.\n\n Verifying existing audit policy: existing Unified Audit policies are listed in\n the view AUDIT_UNIFIED_POLICIES. The AUDIT_OPTION column contains one of the\n actions specified in a CREATE AUDIT POLICY statement. The AUDIT_OPTION_TYPE\n column contains 'STANDARD ACTION' for a policy that applies to all objects or\n 'OBJECT ACTION' for a policy that audits actions on a specific object.\n\n select POLICY_NAME from SYS.AUDIT_UNIFIED_POLICIES where AUDIT_OPTION='GRANT'\n and AUDIT_OPTION_TYPE='STANDARD ACTION';\n\n To find policies that audit privilege grants on specific objects:\n\n select POLICY_NAME,OBJECT_SCHEMA,OBJECT_NAME from SYS.AUDIT_UNIFIED_POLICIES\n where AUDIT_OPTION='GRANT' and AUDIT_OPTION_TYPE='OBJECT ACTION';\n\n The view AUDIT_UNIFIED_ENABLED_POLICIES shows which Unified Audit policies are\n enabled. The ENABLED_OPT and USER_NAME columns show the users for whom the\n policy is enabled or 'ALL USERS'. The SUCCESS and FAILURE columns indicate if\n the policy is enabled for successful or unsuccessful actions, respectively.\n\n select POLICY_NAME,ENABLED_OPT,USER_NAME,SUCCESS,FAILURE from\n SYS.AUDIT_UNIFIED_ENABLED_POLICIES where POLICY_NAME='POLICY1';\"\n tag \"fix\": \"Configure the DBMS's auditing settings to include auditing of\n events on the DoD-selected list of auditable events.\n\n 1) Successful and unsuccessful attempts to access, modify, or delete\n privileges, security objects, security levels, or categories of information\n (e.g., classification levels)\n\n To audit granting and revocation of any privilege:\n create audit policy policy1 actions grant;\n create audit policy policy2 actions revoke;\n\n To audit grants of object privileges on a specific object:\n create audit policy policy3 actions grant on .;\n\n If Oracle Label Security is enabled, this will audit all OLS administrative\n actions:\n create audit policy policy4 actions component = OLS all;\n\n 2) Successful and unsuccessful logon attempts, privileged activities or other\n system-level access\n\n To audit all user logon attempts:\n create audit policy policy5 actions logon;\n\n To audit only logon attempts using administrative privileges (e.g. AS SYSDBA):\n audit policy policy5 by SYS, SYSOPER, SYSBACKUP, SYSDG, SYSKM;\n\n 3) Starting and ending time for user access to the system, concurrent logons\n from different workstations\n\n This policy will audit all logon and logoff events. An individual session is\n identified in the UNIFIED_AUDIT_TRAIL by the tuple (DBID, INSTANCE_ID,\n SESSIONID) and the start and end time will be indicated by the EVENT_TIMESTAMP\n of the logon and logoff events:\n create audit policy policy6 actions logon, logoff;\n\n 4) Successful and unsuccessful accesses to objects\n\n To audit all accesses to a specific table:\n create audit policy policy7 actions select, insert, delete, alter on\n .;\n\n Different actions are defined for other object types. To audit all supported\n actions on a specific object:\n create audit policy policy8 actions all on .;\n\n 5) All program initiations\n\n To audit execution of any PL/SQL program unit:\n create audit policy policy9 actions EXECUTE;\n\n To audit execution of a specific function, procedure, or package:\n create audit policy policy10 actions EXECUTE on .;\n\n 6) All direct access to the information system\n\n [Not applicable to Database audit. Monitor using OS auditing.]\n\n 7) All account creations, modifications, disabling, and terminations\n\n To audit all user administration actions:\n create audit policy policy11 actions create user, alter user, drop user, change\n password;\n\n 8) All kernel module loads, unloads, and restarts\n\n [Not applicable to Database audit. Monitor using OS auditing.]\n\n 9) All database parameter changes\n\n To audit any database parameter changes, dynamic or static:\n create audit policy policy12 actions alter database, alter system, create\n spfile;\n\n Applying the Policy\n\n The following command will enable the policy in all database sessions and audit\n both successful and unsuccessful actions:\n audit policy policy1;\n\n To audit only unsuccessful actions, add the WHENEVER NOT SUCCESSFUL modifier:\n audit policy policy1 whenever not successful;\n\n Either command above can be limited to only database sessions started by a\n specific user as follows:\n audit policy policy1 by ;\n audit policy policy1 by whenever not successful;\"\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_policies_auditing_grant_privileges = sql.query(\"select DISTINCT POLICY_NAME from AUDIT_UNIFIED_POLICIES\n where AUDIT_OPTION='GRANT' and AUDIT_OPTION_TYPE='OBJECT ACTION';\").column('policy_name')\n unified_audit_policies_enabled = sql.query('select POLICY_NAME from AUDIT_UNIFIED_ENABLED_POLICIES;').column('policy_name')\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 audit policies that audit privilege grants on specific objects' do\n subject { audit_policies_auditing_grant_privileges }\n it { should_not be_empty }\n end\n\n describe 'The list of unified audit policies enabled' do\n subject { unified_audit_policies_enabled }\n it { should_not be_empty }\n end\n\n end\nend\n", + "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", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61625.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61561.rb", "line": 1 }, - "id": "V-61625" + "id": "V-61561" }, { - "title": "Database job/batch queues must be reviewed regularly to detect\n unauthorized database job submissions.", - "desc": "Unauthorized users may bypass security mechanisms by submitting jobs\n to job queues managed by the database to be run under a more privileged\n security context of the database or host system. These queues must be monitored\n regularly to detect any such unauthorized job submissions.", + "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": "Unauthorized users may bypass security mechanisms by submitting jobs\n to job queues managed by the database to be run under a more privileged\n security context of the database or host system. These queues must be monitored\n regularly to detect any such unauthorized job submissions." + "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-61449", - "rid": "SV-75939r3_rule", - "stig_id": "O121-BP-023100", - "fix_id": "F-67365r2_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, @@ -849,35 +851,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "The DBMS_JOB PL/SQL package has been replaced by DBMS_SCHEDULER\n in Oracle versions 10.1 and higher, though it continues to be supported for\n backward compatibility.\n\n Run this query:\n select value from v$parameter where name = 'job_queue_processes';\n\n Run this query:\n select value from all_scheduler_global_attribute\n where ATTRIBUTE_NAME = 'MAX_JOB_SLAVE_PROCESSES';\n\n To understand the relationship between these settings, review:\n https://docs.oracle.com/database/121/ADMIN/appendix_a.htm#ADMIN11002\n\n Review documented and implemented procedures for monitoring the Oracle DBMS\n job/batch queues for unauthorized submissions. If procedures for job queue\n review are not defined, documented or evidence of implementation does not\n exist, this is a finding.\n\n Job queue information is available from the DBA_JOBS view. The following\n command lists jobs submitted to the queue. DBMS_JOB does not generate a\n 'history' of previous job executions.\n\n Run this query:\n select job, next_date, next_sec, failures, broken from dba_jobs;\n\n Scheduler queue information is available from the DBA_SCHEDULER_JOBS view. The\n following command lists jobs submitted to the queue.\n\n Run this query:\n select owner, job_name, state, job_class, job_type, job_action\n from dba_scheduler_jobs;", - "fix": "Develop, document and implement procedures to monitor the\n database job queues for unauthorized job submissions.\n\n Develop, document and implement a formal migration plan to convert jobs using\n DBMS_JOB to use DBMS_SCHEDULER instead for Oracle versions 10.1 and higher.\n (This does not apply to DBMS_JOB jobs generated by Oracle itself, such as those\n for refreshing materialized views.)\n\n Set the value of the job_queue_processes parameter to a low value to restrict\n concurrent DBMS_JOB executions.\n\n Use auditing to capture use of the DBMS_JOB package in the audit trail. Review\n the audit trail for unauthorized use of the DBMS_JOB package." + "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