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 ad095bed..e447ef3b 100644 --- a/src/assets/data/baselineProfiles/aws-rds-oracle-database-12c-stig-baseline.json +++ b/src/assets/data/baselineProfiles/aws-rds-oracle-database-12c-stig-baseline.json @@ -20,24 +20,24 @@ "supports": [], "controls": [ { - "title": "The DBMS must only generate error messages that provide information\n necessary for corrective actions without revealing organization-defined\n sensitive or potentially harmful information in error logs and administrative\n messages that could be exploited.", - "desc": "Any application providing too much information in error logs and in\n administrative messages to the screen risks compromising the data and security\n of the application and system. The structure and content of error messages\n needs to be carefully considered by the organization and development team.\n\n The extent to which the application is able to identify and handle error\n conditions is guided by organizational policy and operational requirements.\n Sensitive information includes account numbers, social security numbers, and\n credit card numbers.\n\n Databases can inadvertently provide a wealth of information to an attacker\n through improperly handled error messages. In addition to sensitive business or\n personal information, database errors can provide host names, IP addresses,\n user names, and other system information not required for troubleshooting but\n very useful to someone targeting the system.\n\n This calls for inspection of application source code, which will require\n collaboration with the application developers. It is recognized that in many\n cases, the database administrator (DBA) is organizationally separate from the\n application developers and may have limited, if any, access to source code.\n Nevertheless, protections of this type are so important to the secure operation\n of databases that they must not be ignored. At a minimum, the DBA must attempt\n to obtain assurances from the development organization that this issue has been\n addressed and must document what has been discovered.", + "title": "The Oracle WITH GRANT OPTION privilege must not be granted to non-DBA\n or non-Application administrator user accounts.", + "desc": "An account permission to grant privileges within the database is an\n administrative function. Minimizing the number and privileges of administrative\n accounts reduces the chances of privileged account exploitation. Application\n user accounts must never require WITH GRANT OPTION privileges since, by\n definition, they require only privileges to execute procedures or view / edit\n data.", "descriptions": { - "default": "Any application providing too much information in error logs and in\n administrative messages to the screen risks compromising the data and security\n of the application and system. The structure and content of error messages\n needs to be carefully considered by the organization and development team.\n\n The extent to which the application is able to identify and handle error\n conditions is guided by organizational policy and operational requirements.\n Sensitive information includes account numbers, social security numbers, and\n credit card numbers.\n\n Databases can inadvertently provide a wealth of information to an attacker\n through improperly handled error messages. In addition to sensitive business or\n personal information, database errors can provide host names, IP addresses,\n user names, and other system information not required for troubleshooting but\n very useful to someone targeting the system.\n\n This calls for inspection of application source code, which will require\n collaboration with the application developers. It is recognized that in many\n cases, the database administrator (DBA) is organizationally separate from the\n application developers and may have limited, if any, access to source code.\n Nevertheless, protections of this type are so important to the secure operation\n of databases that they must not be ignored. At a minimum, the DBA must attempt\n to obtain assurances from the development organization that this issue has been\n addressed and must document what has been discovered." + "default": "An account permission to grant privileges within the database is an\n administrative function. Minimizing the number and privileges of administrative\n accounts reduces the chances of privileged account exploitation. Application\n user accounts must never require WITH GRANT OPTION privileges since, by\n definition, they require only privileges to execute procedures or view / edit\n data." }, "impact": 0.5, "refs": [], "tags": { - "gtitle": "SRG-APP-000266-DB-000162", - "gid": "V-61791", - "rid": "SV-76281r2_rule", - "stig_id": "O121-C2-019900", - "fix_id": "F-67707r1_fix", + "gtitle": "SRG-APP-000516-DB-999900", + "gid": "V-61421", + "rid": "SV-75911r2_rule", + "stig_id": "O121-BP-021700", + "fix_id": "F-67337r1_fix", "cci": [ - "CCI-001312" + "CCI-000366" ], "nist": [ - "SI-11 a", + "CM-6 b", "Rev_4" ], "false_negatives": null, @@ -50,35 +50,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Check DBMS settings and custom database and application code to\n verify error messages do not contain information beyond what is needed for\n troubleshooting the issue.\n\n If database errors contain PII data, sensitive business data, or information\n useful for identifying the host system, this is a finding.\n\n Notes on Oracle's approach to this issue: Out of the box, Oracle covers this.\n For example, if a user does not have access to a table, the error is just that\n the table or view does not exist. The Oracle database is not going to display a\n Social Security Number in an error code unless an application is programmed to\n do so. Oracle applications will not expose the actual transactional data to a\n screen. The only way Oracle will capture this information is to enable\n specific logging levels. Custom code would require a review to ensure\n compliance.", - "fix": "Configure DBMS and custom database and application code not to\n divulge sensitive information or information useful for system identification\n in error information." + "check": "Execute the query:\n\n select grantee||': '||owner||'.'||table_name\n from dba_tab_privs\n where grantable = 'YES'\n and grantee not in (select distinct owner from dba_objects)\n and grantee not in (select grantee from dba_role_privs where granted_role =\n 'DBA')\n order by grantee;\n\n If any accounts are listed, this is a finding.", + "fix": "Revoke privileges granted the WITH GRANT OPTION from non-DBA and\n accounts that do not own application objects.\n\n Re-grant privileges without specifying WITH GRANT OPTION." }, - "code": "control 'V-61791' do\n title \"The DBMS must only generate error messages that provide information\n necessary for corrective actions without revealing organization-defined\n sensitive or potentially harmful information in error logs and administrative\n messages that could be exploited.\"\n desc \"Any application providing too much information in error logs and in\n administrative messages to the screen risks compromising the data and security\n of the application and system. The structure and content of error messages\n needs to be carefully considered by the organization and development team.\n\n The extent to which the application is able to identify and handle error\n conditions is guided by organizational policy and operational requirements.\n Sensitive information includes account numbers, social security numbers, and\n credit card numbers.\n\n Databases can inadvertently provide a wealth of information to an attacker\n through improperly handled error messages. In addition to sensitive business or\n personal information, database errors can provide host names, IP addresses,\n user names, and other system information not required for troubleshooting but\n very useful to someone targeting the system.\n\n This calls for inspection of application source code, which will require\n collaboration with the application developers. It is recognized that in many\n cases, the database administrator (DBA) is organizationally separate from the\n application developers and may have limited, if any, access to source code.\n Nevertheless, protections of this type are so important to the secure operation\n of databases that they must not be ignored. At a minimum, the DBA must attempt\n to obtain assurances from the development organization that this issue has been\n addressed and must document what has been discovered.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000266-DB-000162'\n tag \"gid\": 'V-61791'\n tag \"rid\": 'SV-76281r2_rule'\n tag \"stig_id\": 'O121-C2-019900'\n tag \"fix_id\": 'F-67707r1_fix'\n tag \"cci\": ['CCI-001312']\n tag \"nist\": ['SI-11 a', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Check DBMS settings and custom database and application code to\n verify error messages do not contain information beyond what is needed for\n troubleshooting the issue.\n\n If database errors contain PII data, sensitive business data, or information\n useful for identifying the host system, this is a finding.\n\n Notes on Oracle's approach to this issue: Out of the box, Oracle covers this.\n For example, if a user does not have access to a table, the error is just that\n the table or view does not exist. The Oracle database is not going to display a\n Social Security Number in an error code unless an application is programmed to\n do so. Oracle applications will not expose the actual transactional data to a\n screen. The only way Oracle will capture this information is to enable\n specific logging levels. Custom code would require a review to ensure\n compliance.\"\n tag \"fix\": \"Configure DBMS and custom database and application code not to\n divulge sensitive information or information useful for system identification\n in error information.\"\n describe 'A manual review is required to ensure the DBMS only generates error messages that provide information\n necessary for corrective actions without revealing organization-defined\n sensitive or potentially harmful information in error logs and administrative\n messages that could be exploited.' do\n skip 'A manual review is required to ensure the DBMS only generates error messages that provide information\n necessary for corrective actions without revealing organization-defined\n sensitive or potentially harmful information in error logs and administrative\n messages that could be exploited.'\n end\nend\n", + "code": "control 'V-61421' do\n title \"The Oracle WITH GRANT OPTION privilege must not be granted to non-DBA\n or non-Application administrator user accounts.\"\n desc \"An account permission to grant privileges within the database is an\n administrative function. Minimizing the number and privileges of administrative\n accounts reduces the chances of privileged account exploitation. Application\n user accounts must never require WITH GRANT OPTION privileges since, by\n definition, they require only privileges to execute procedures or view / edit\n data.\"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000516-DB-999900'\n tag \"gid\": 'V-61421'\n tag \"rid\": 'SV-75911r2_rule'\n tag \"stig_id\": 'O121-BP-021700'\n tag \"fix_id\": 'F-67337r1_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\": \"Execute the query:\n\n select grantee||': '||owner||'.'||table_name\n from dba_tab_privs\n where grantable = 'YES'\n and grantee not in (select distinct owner from dba_objects)\n and grantee not in (select grantee from dba_role_privs where granted_role =\n 'DBA')\n order by grantee;\n\n If any accounts are listed, this is a finding.\"\n tag \"fix\": \"Revoke privileges granted the WITH GRANT OPTION from non-DBA and\n accounts that do not own application objects.\n\n Re-grant privileges without specifying WITH GRANT OPTION.\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n describe sql.query(\"select grantee||': '||owner||'.'||table_name\n from dba_tab_privs\n where grantable = 'YES'\n and grantee not in (select distinct owner from dba_objects)\n and grantee not in (select grantee from dba_role_privs where granted_role =\n 'DBA')\n order by grantee;\").row(0).column(\"grantee||': '||owner||'.'||table_name\") do\n its('value') { should be_empty }\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61791.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61421.rb", "line": 1 }, - "id": "V-61791" + "id": "V-61421" }, { - "title": "The DBMS must include organization-defined additional, more detailed\n information in the audit records for audit events identified by type, location,\n or subject.", - "desc": "Information system auditing capability is critical for accurate\n forensic analysis. Audit record content that may be necessary to satisfy the\n requirement of this control includes: timestamps, source and destination\n addresses, user/process identifiers, event descriptions, success/fail\n indications, file names involved, and access control or flow control rules\n invoked.\n\n In addition, the application must have the capability to include\n organization-defined additional, more detailed information in the audit records\n for audit events. These events may be identified by type, location, or subject.\n\n An example of detailed information the organization may require in audit\n records is full-text recording of privileged commands or the individual\n identities of shared account users.\n\n Some organizations may determine that more detailed information is required\n for specific database event types. If this information is not available, it\n could negatively impact forensic investigations into user actions or other\n malicious events.", + "title": "The system must provide the capability to automatically process audit\n records for events of interest based upon selectable event criteria.", + "desc": "Before a security review, information systems and/or applications with\n an audit reduction capability may remove many audit records known to have\n little security significance.\n\n This is generally accomplished by removing records generated by specified\n classes of events, such as records generated by nightly backups.\n\n An audit reduction capability provides support for near real-time audit\n review and analysis based on policy requirements regarding what must be audited\n on the system and after-the-fact investigations of security incidents. It is\n important to recognize audit reduction does not alter original audit records.\n\n Audit reduction and reporting tools do not alter original audit records.\n\n To leverage the complete capability of audit reduction, the application\n must possess the ability to specify and automatically process certain event\n criteria that are selectable in nature. In other words, a system administrator\n (SA) may be performing a manual review of audit data to identify a particular\n problem. The SA has determined that backup activity and network connections\n from a particular host comprise the bulk of the events. However, these events\n are not related to the activity being investigated. The application must be\n able to automatically process these audit records for audit reduction purposes\n rather than making the administrator manually process them.\n\n The lack of audit reduction and reporting in a database can require the\n DBA, or others responsible for reviewing audit logs, to sort through large\n amounts of data in order to find relevant records. This can cause important\n audit records to be missed.\n\n Oracle offers the choice of storing audit data internally in database\n tables, or in external files. The WHERE clause in the SELECT statement\n provides the necessary functionality for a table-based audit. For an audit\n based on external files (or for a table-based audit trail archived to external\n files) Oracle Database does not provide tools for retrieving and managing the\n data once written. Therefore, an external tool is needed.", "descriptions": { - "default": "Information system auditing capability is critical for accurate\n forensic analysis. Audit record content that may be necessary to satisfy the\n requirement of this control includes: timestamps, source and destination\n addresses, user/process identifiers, event descriptions, success/fail\n indications, file names involved, and access control or flow control rules\n invoked.\n\n In addition, the application must have the capability to include\n organization-defined additional, more detailed information in the audit records\n for audit events. These events may be identified by type, location, or subject.\n\n An example of detailed information the organization may require in audit\n records is full-text recording of privileged commands or the individual\n identities of shared account users.\n\n Some organizations may determine that more detailed information is required\n for specific database event types. If this information is not available, it\n could negatively impact forensic investigations into user actions or other\n malicious events." + "default": "Before a security review, information systems and/or applications with\n an audit reduction capability may remove many audit records known to have\n little security significance.\n\n This is generally accomplished by removing records generated by specified\n classes of events, such as records generated by nightly backups.\n\n An audit reduction capability provides support for near real-time audit\n review and analysis based on policy requirements regarding what must be audited\n on the system and after-the-fact investigations of security incidents. It is\n important to recognize audit reduction does not alter original audit records.\n\n Audit reduction and reporting tools do not alter original audit records.\n\n To leverage the complete capability of audit reduction, the application\n must possess the ability to specify and automatically process certain event\n criteria that are selectable in nature. In other words, a system administrator\n (SA) may be performing a manual review of audit data to identify a particular\n problem. The SA has determined that backup activity and network connections\n from a particular host comprise the bulk of the events. However, these events\n are not related to the activity being investigated. The application must be\n able to automatically process these audit records for audit reduction purposes\n rather than making the administrator manually process them.\n\n The lack of audit reduction and reporting in a database can require the\n DBA, or others responsible for reviewing audit logs, to sort through large\n amounts of data in order to find relevant records. This can cause important\n audit records to be missed.\n\n Oracle offers the choice of storing audit data internally in database\n tables, or in external files. The WHERE clause in the SELECT statement\n provides the necessary functionality for a table-based audit. For an audit\n based on external files (or for a table-based audit trail archived to external\n files) Oracle Database does not provide tools for retrieving and managing the\n data once written. Therefore, an external tool is needed." }, "impact": 0.5, "refs": [], "tags": { - "gtitle": "SRG-APP-000101-DB-000044", - "gid": "V-61641", - "rid": "SV-76131r1_rule", - "stig_id": "O121-C2-008000", - "fix_id": "F-67553r2_fix", + "gtitle": "SRG-APP-000115-DB-000055", + "gid": "V-61649", + "rid": "SV-76139r2_rule", + "stig_id": "O121-C2-008900", + "fix_id": "F-67563r2_fix", "cci": [ - "CCI-000135" + "CCI-000158" ], "nist": [ - "AU-3 (1)", + "AU-7 (1)", "Rev_4" ], "false_negatives": null, @@ -91,35 +91,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\n SHOW PARAMETER AUDIT_TRAIL\n\n or the following SQL query:\n\n SELECT * FROM SYS.V$PARAMETER WHERE NAME = 'audit_trail';\n\n If Oracle returns the value \"NONE\", this is a finding.\n\n Compare the organization-defined auditable events with the Oracle documentation\n to determine whether standard auditing covers all the requirements.\n\n If it does, this is not a finding.\n\n Compare those organization-defined auditable events that are not covered by the\n standard auditing, with the existing Fine-Grained Auditing (FGA) specifications\n returned by the following query:\n\n SELECT * FROM SYS.DBA_FGA_AUDIT_TRAIL;\n\n If any such auditable event is not covered by the existing FGA specifications,\n this is a finding.\n\n If Unified Auditing is used:\n To see if Oracle is configured to capture audit data, enter the following\n SQL*Plus command:\n\n SELECT * FROM V$OPTION WHERE PARAMETER = 'Unified Auditing';\n\n If Oracle returns the value \"TRUE\", this is not a finding.\n\n Compare the organization-defined auditable events with the Oracle documentation\n to determine whether standard auditing covers all the requirements.\n\n If it does, this is not a finding.\n\n Compare those organization-defined auditable events that are not covered by the\n standard auditing, with the existing Fine-Grained Auditing (FGA) specifications\n returned by the following query:\n\n SELECT * FROM SYS.UNIFIED_AUDIT_TRAIL WHERE AUDIT_TYPE = 'FineGrainedAudit';\n\n If any such auditable event is not covered by the existing FGA specifications,\n this is a finding.", - "fix": "Either configure the DBMS's auditing to audit\n organization-defined auditable events, or, if preferred, use a third-party or\n custom tool. The tool must provide the minimum capability to audit the required\n events.\n\n If using a third-party product, proceed in accordance with the product\n documentation. If using Oracle's capabilities, proceed as follows.\n\n If Standard Auditing is used:\n Use this process to ensure auditable events are captured:\n\n ALTER SYSTEM SET AUDIT_TRAIL= SCOPE=SPFILE;\n\n Audit trail type can be \"OS\", \"DB\", \"DB,EXTENDED\", \"XML\" or\n \"XML,EXTENDED\".\n\n After executing this statement, it may be necessary to shut down and restart\n the Oracle database.\n\n If the organization-defined additional audit requirements are not covered by\n the default audit options, deploy and configure Fine-Grained Auditing. For\n details, refer to Oracle documentation at the location below.\n\n If the site-specific audit requirements are not covered by the default audit\n options, deploy and configure Fine-Grained Auditing. For details, refer to\n Oracle documentation, at the location below.\n\n If Unified Auditing is used:\n Use this process to ensure auditable events are captured:\n\n SELECT * FROM V$OPTION WHERE PARAMETER = 'Unified Auditing';\n\n If Oracle returns the value \"TRUE\", this is not a finding.\n\n Otherwise,\n Link the oracle binary with uniaud_on, and then restart the database. Oracle\n Database Upgrade Guide describes how to enable unified auditing.\n\n If the organization-defined additional audit requirements are not covered by\n the default audit options, deploy and configure Fine-Grained Auditing. For\n details, refer to Oracle documentation at the location below.\n\n If the site-specific audit requirements are not covered by the default audit\n options, deploy and configure Fine-Grained Auditing. For details, refer to\n Oracle documentation, at the location below.\n\n For more information on the configuration of auditing, refer to the following\n documents:\n \"Auditing Database Activity\" in the Oracle Database 2 Day + Security Guide:\n http://docs.oracle.com/database/121/TDPSG/tdpsg_auditing.htm#TDPSG50000\n \"Monitoring Database Activity with Auditing\" in the Oracle Database Security\n Guide:\n http://docs.oracle.com/database/121/DBSEG/part_6.htm#CCHEHCGI\n \"DBMS_AUDIT_MGMT\" in the Oracle Database PL/SQL Packages and Types Reference:\n http://docs.oracle.com/database/121/ARPLS/d_audit_mgmt.htm#ARPLS241\n Oracle Database Upgrade Guide:\n http://docs.oracle.com/database/121/UPGRD/afterup.htm#UPGRD52810" + "check": "Review the system (OS, applications external to Oracle, and/or\n a separate log aggregation and query server) to determine whether it provides\n the ability to automatically process audit records for events based on\n selectable event criteria. If the system does not provide these abilities, they\n may be handled by a separate application.\n\n If the ability to automatically process audit records for events based on\n selectable event criteria does not exist, this is a finding.", + "fix": "Utilize a tool, application or service that provides the ability\n to automatically process audit records for events based on selectable event\n criteria." }, - "code": "control 'V-61641' do\n title \"The DBMS must include organization-defined additional, more detailed\n information in the audit records for audit events identified by type, location,\n or subject.\"\n desc \"Information system auditing capability is critical for accurate\n forensic analysis. Audit record content that may be necessary to satisfy the\n requirement of this control includes: timestamps, source and destination\n addresses, user/process identifiers, event descriptions, success/fail\n indications, file names involved, and access control or flow control rules\n invoked.\n\n In addition, the application must have the capability to include\n organization-defined additional, more detailed information in the audit records\n for audit events. These events may be identified by type, location, or subject.\n\n An example of detailed information the organization may require in audit\n records is full-text recording of privileged commands or the individual\n identities of shared account users.\n\n Some organizations may determine that more detailed information is required\n for specific database event types. If this information is not available, it\n could negatively impact forensic investigations into user actions or other\n malicious events.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000101-DB-000044'\n tag \"gid\": 'V-61641'\n tag \"rid\": 'SV-76131r1_rule'\n tag \"stig_id\": 'O121-C2-008000'\n tag \"fix_id\": 'F-67553r2_fix'\n tag \"cci\": ['CCI-000135']\n tag \"nist\": ['AU-3 (1)', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Verify, using vendor and system documentation if necessary,\n that the DBMS is configured to use Oracle's auditing features, or that a\n third-party product or custom code is deployed and configured to satisfy this\n requirement.\n\n If a third-party product or custom code is used, compare its current\n configuration with the audit requirements. If any of the requirements is not\n covered by the configuration, this is a finding.\n\n The remainder of this Check is applicable specifically where Oracle auditing is\n in use.\n\n If Standard Auditing is used:\n To see if Oracle is configured to capture audit data, enter the following\n SQL*Plus command:\n\n SHOW PARAMETER AUDIT_TRAIL\n\n or the following SQL query:\n\n SELECT * FROM SYS.V$PARAMETER WHERE NAME = 'audit_trail';\n\n If Oracle returns the value \\\"NONE\\\", this is a finding.\n\n Compare the organization-defined auditable events with the Oracle documentation\n to determine whether standard auditing covers all the requirements.\n\n If it does, this is not a finding.\n\n Compare those organization-defined auditable events that are not covered by the\n standard auditing, with the existing Fine-Grained Auditing (FGA) specifications\n returned by the following query:\n\n SELECT * FROM SYS.DBA_FGA_AUDIT_TRAIL;\n\n If any such auditable event is not covered by the existing FGA specifications,\n this is a finding.\n\n If Unified Auditing is used:\n To see if Oracle is configured to capture audit data, enter the following\n SQL*Plus command:\n\n SELECT * FROM V$OPTION WHERE PARAMETER = 'Unified Auditing';\n\n If Oracle returns the value \\\"TRUE\\\", this is not a finding.\n\n Compare the organization-defined auditable events with the Oracle documentation\n to determine whether standard auditing covers all the requirements.\n\n If it does, this is not a finding.\n\n Compare those organization-defined auditable events that are not covered by the\n standard auditing, with the existing Fine-Grained Auditing (FGA) specifications\n returned by the following query:\n\n SELECT * FROM SYS.UNIFIED_AUDIT_TRAIL WHERE AUDIT_TYPE = 'FineGrainedAudit';\n\n If any such auditable event is not covered by the existing FGA specifications,\n this is a finding.\"\n tag \"fix\": \"Either configure the DBMS's auditing to audit\n organization-defined auditable events, or, if preferred, use a third-party or\n custom tool. The tool must provide the minimum capability to audit the required\n events.\n\n If using a third-party product, proceed in accordance with the product\n documentation. If using Oracle's capabilities, proceed as follows.\n\n If Standard Auditing is used:\n Use this process to ensure auditable events are captured:\n\n ALTER SYSTEM SET AUDIT_TRAIL= SCOPE=SPFILE;\n\n Audit trail type can be \\\"OS\\\", \\\"DB\\\", \\\"DB,EXTENDED\\\", \\\"XML\\\" or\n \\\"XML,EXTENDED\\\".\n\n After executing this statement, it may be necessary to shut down and restart\n the Oracle database.\n\n If the organization-defined additional audit requirements are not covered by\n the default audit options, deploy and configure Fine-Grained Auditing. For\n details, refer to Oracle documentation at the location below.\n\n If the site-specific audit requirements are not covered by the default audit\n options, deploy and configure Fine-Grained Auditing. For details, refer to\n Oracle documentation, at the location below.\n\n If Unified Auditing is used:\n Use this process to ensure auditable events are captured:\n\n SELECT * FROM V$OPTION WHERE PARAMETER = 'Unified Auditing';\n\n If Oracle returns the value \\\"TRUE\\\", this is not a finding.\n\n Otherwise,\n Link the oracle binary with uniaud_on, and then restart the database. Oracle\n Database Upgrade Guide describes how to enable unified auditing.\n\n If the organization-defined additional audit requirements are not covered by\n the default audit options, deploy and configure Fine-Grained Auditing. For\n details, refer to Oracle documentation at the location below.\n\n If the site-specific audit requirements are not covered by the default audit\n options, deploy and configure Fine-Grained Auditing. For details, refer to\n Oracle documentation, at the location below.\n\n For more information on the configuration of auditing, refer to the following\n documents:\n \\\"Auditing Database Activity\\\" in the Oracle Database 2 Day + Security Guide:\n http://docs.oracle.com/database/121/TDPSG/tdpsg_auditing.htm#TDPSG50000\n \\\"Monitoring Database Activity with Auditing\\\" in the Oracle Database Security\n Guide:\n http://docs.oracle.com/database/121/DBSEG/part_6.htm#CCHEHCGI\n \\\"DBMS_AUDIT_MGMT\\\" in the Oracle Database PL/SQL Packages and Types Reference:\n http://docs.oracle.com/database/121/ARPLS/d_audit_mgmt.htm#ARPLS241\n Oracle Database Upgrade Guide:\n http://docs.oracle.com/database/121/UPGRD/afterup.htm#UPGRD52810\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n standard_auditing_used = input('standard_auditing_used')\n unified_auditing_used = input('unified_auditing_used')\n\n describe.one do\n describe 'Standard auditing is in use for audit purposes' do\n subject { standard_auditing_used }\n it { should be true }\n end\n\n describe 'Unified auditing is in use for audit purposes' do\n subject { unified_auditing_used }\n it { should be true }\n end\n end\n\n audit_trail = sql.query(\"select value from v$parameter where name = 'audit_trail';\").column('value')\n audit_info_captured = sql.query('SELECT EVENT_TIMESTAMP FROM UNIFIED_AUDIT_TRAIL ORDER BY EVENT_TIMESTAMP DESC FETCH FIRST 10 ROWS ONLY;').column('event_timestamp')\n fga_audit_events = sql.query(\" SELECT * FROM SYS.UNIFIED_AUDIT_TRAIL WHERE AUDIT_TYPE = 'FineGrainedAudit';\").column('TIMESTAMP')\n\n if standard_auditing_used\n describe 'The oracle database audit_trail parameter' do\n subject { audit_trail }\n it { should_not cmp 'NONE' }\n end\n end\n\n unified_auditing = sql.query(\"SELECT value FROM V$OPTION WHERE PARAMETER = 'Unified Auditing';\").column('value')\n\n if unified_auditing_used\n describe 'The oracle database unified auditing parameter' do\n subject { unified_auditing }\n it { should_not cmp 'FALSE' }\n end\n\n describe 'The oracle database unified auditing events captured' do\n subject { audit_info_captured }\n it { should_not be_empty }\n end\n\n describe 'The oracle database fine grained auditing events captured' do\n subject { fga_audit_events }\n it { should_not be_empty }\n end\n\n end\nend\n", + "code": "control 'V-61649' do\n title \"The system must provide the capability to automatically process audit\n records for events of interest based upon selectable event criteria.\"\n desc \"Before a security review, information systems and/or applications with\n an audit reduction capability may remove many audit records known to have\n little security significance.\n\n This is generally accomplished by removing records generated by specified\n classes of events, such as records generated by nightly backups.\n\n An audit reduction capability provides support for near real-time audit\n review and analysis based on policy requirements regarding what must be audited\n on the system and after-the-fact investigations of security incidents. It is\n important to recognize audit reduction does not alter original audit records.\n\n Audit reduction and reporting tools do not alter original audit records.\n\n To leverage the complete capability of audit reduction, the application\n must possess the ability to specify and automatically process certain event\n criteria that are selectable in nature. In other words, a system administrator\n (SA) may be performing a manual review of audit data to identify a particular\n problem. The SA has determined that backup activity and network connections\n from a particular host comprise the bulk of the events. However, these events\n are not related to the activity being investigated. The application must be\n able to automatically process these audit records for audit reduction purposes\n rather than making the administrator manually process them.\n\n The lack of audit reduction and reporting in a database can require the\n DBA, or others responsible for reviewing audit logs, to sort through large\n amounts of data in order to find relevant records. This can cause important\n audit records to be missed.\n\n Oracle offers the choice of storing audit data internally in database\n tables, or in external files. The WHERE clause in the SELECT statement\n provides the necessary functionality for a table-based audit. For an audit\n based on external files (or for a table-based audit trail archived to external\n files) Oracle Database does not provide tools for retrieving and managing the\n data once written. Therefore, an external tool is needed.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000115-DB-000055'\n tag \"gid\": 'V-61649'\n tag \"rid\": 'SV-76139r2_rule'\n tag \"stig_id\": 'O121-C2-008900'\n tag \"fix_id\": 'F-67563r2_fix'\n tag \"cci\": ['CCI-000158']\n tag \"nist\": ['AU-7 (1)', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Review the system (OS, applications external to Oracle, and/or\n a separate log aggregation and query server) to determine whether it provides\n the ability to automatically process audit records for events based on\n selectable event criteria. If the system does not provide these abilities, they\n may be handled by a separate application.\n\n If the ability to automatically process audit records for events based on\n selectable event criteria does not exist, this is a finding.\"\n tag \"fix\": \"Utilize a tool, application or service that provides the ability\n to automatically process audit records for events based on selectable event\n criteria.\"\n describe service('auditd') do\n it { should be_enabled }\n it { should be_running }\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61641.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61649.rb", "line": 1 }, - "id": "V-61641" + "id": "V-61649" }, { - "title": "The system must provide a report generation capability for audit\n reduction data.", - "desc": "In support of Audit Review, Analysis, and Reporting requirements,\n audit reduction is a technique used to reduce the volume of audit records in\n order to facilitate a manual review.\n\n Before a security review is conducted, information systems and/or\n applications with an audit reduction capability may remove many audit records\n known to have little security significance. This is generally accomplished by\n removing records generated by specified classes of events, such as records\n generated by nightly backups.\n\n In order to identify and report on what (repetitive) data has been removed\n via the use of audit reduction, the application must provide a capability to\n generate reports containing what values were removed by the audit reduction.\n\n Audit reduction does not alter original audit records. An audit reduction\n capability provides support for near real-time audit review and analysis based\n on policy-based requirements and after-the-fact investigations of security\n incidents.\n\n Reporting tools employing audit reduction methods must not alter the\n original audit data. An example of a tool employing audit reduction methods is\n the Windows Event Viewer tool which is used to view and analyze audit logs on\n Windows systems.\n\n The lack of reporting tools for audit reduction can require the DBA, or\n others responsible for reviewing audit logs, to sort through large amounts of\n data in order to find relevant records. This can cause important audit records\n to be missed.", + "title": "OS accounts utilized to run external procedures called by the DBMS\n must have limited privileges.", + "desc": "This requirement is intended to limit exposure due to operating from\n within a privileged account or role. The inclusion of role is intended to\n address those situations where an access control policy, such as Role Based\n Access Control (RBAC) is being implemented and where a change of role provides\n the same degree of assurance in the change of access authorizations for both\n the user and all processes acting on behalf of the user as would be provided by\n a change between a privileged and non-privileged account.\n\n To limit exposure when operating from within a privileged account or role,\n the application must support organizational requirements that users of\n information system accounts, or roles, with access to organization-defined\n lists of security functions or security-relevant information, use\n non-privileged accounts, or roles, when accessing other (non-security) system\n functions.\n\n Use of privileged accounts for non-administrative purposes puts data at\n risk of unintended or unauthorized loss, modification, or exposure. In\n particular, DBA accounts if used for non-administration application development\n or application maintenance can lead to miss-assignment of privileges where\n privileges are inherited by object owners. It may also lead to loss or\n compromise of application data where the elevated privileges bypass controls\n designed in and provided by applications.\n\n External applications called or spawned by the DBMS process may be executed\n under OS accounts with unnecessary privileges. This can lead to unauthorized\n access to OS resources and compromise of the OS, the DBMS or any other services\n provided by the host platform.", "descriptions": { - "default": "In support of Audit Review, Analysis, and Reporting requirements,\n audit reduction is a technique used to reduce the volume of audit records in\n order to facilitate a manual review.\n\n Before a security review is conducted, information systems and/or\n applications with an audit reduction capability may remove many audit records\n known to have little security significance. This is generally accomplished by\n removing records generated by specified classes of events, such as records\n generated by nightly backups.\n\n In order to identify and report on what (repetitive) data has been removed\n via the use of audit reduction, the application must provide a capability to\n generate reports containing what values were removed by the audit reduction.\n\n Audit reduction does not alter original audit records. An audit reduction\n capability provides support for near real-time audit review and analysis based\n on policy-based requirements and after-the-fact investigations of security\n incidents.\n\n Reporting tools employing audit reduction methods must not alter the\n original audit data. An example of a tool employing audit reduction methods is\n the Windows Event Viewer tool which is used to view and analyze audit logs on\n Windows systems.\n\n The lack of reporting tools for audit reduction can require the DBA, or\n others responsible for reviewing audit logs, to sort through large amounts of\n data in order to find relevant records. This can cause important audit records\n to be missed." + "default": "This requirement is intended to limit exposure due to operating from\n within a privileged account or role. The inclusion of role is intended to\n address those situations where an access control policy, such as Role Based\n Access Control (RBAC) is being implemented and where a change of role provides\n the same degree of assurance in the change of access authorizations for both\n the user and all processes acting on behalf of the user as would be provided by\n a change between a privileged and non-privileged account.\n\n To limit exposure when operating from within a privileged account or role,\n the application must support organizational requirements that users of\n information system accounts, or roles, with access to organization-defined\n lists of security functions or security-relevant information, use\n non-privileged accounts, or roles, when accessing other (non-security) system\n functions.\n\n Use of privileged accounts for non-administrative purposes puts data at\n risk of unintended or unauthorized loss, modification, or exposure. In\n particular, DBA accounts if used for non-administration application development\n or application maintenance can lead to miss-assignment of privileges where\n privileges are inherited by object owners. It may also lead to loss or\n compromise of application data where the elevated privileges bypass controls\n designed in and provided by applications.\n\n External applications called or spawned by the DBMS process may be executed\n under OS accounts with unnecessary privileges. This can lead to unauthorized\n access to OS resources and compromise of the OS, the DBMS or any other services\n provided by the host platform." }, - "impact": 0.3, - "refs": [], + "impact": 0, + "refs": [ + { + "ref": [] + } + ], "tags": { - "gtitle": "SRG-APP-000114-DB-000054", - "gid": "V-61969", - "rid": "SV-76459r1_rule", - "stig_id": "O121-C3-008800", - "fix_id": "F-67889r1_fix", + "gtitle": "SRG-APP-000063-DB-000020", + "gid": "V-61601", + "rid": "SV-76091r2_rule", + "stig_id": "O121-C2-004400", + "fix_id": "F-67517r2_fix", "cci": [ - "CCI-001878" + "CCI-000366" ], "nist": [ - "AU-7 a", + "CM-6 b", "Rev_4" ], "false_negatives": null, @@ -132,35 +136,39 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Verify that audit reduction capabilities are in place for the\n Oracle audit data. Since Oracle has no reduction capability per se, a\n third-party tool or in-house-developed software must be in place to provide\n this functionality. This must include the ability to report on the excluded\n audit data.\n\n If this capability has not been implemented, this is a finding.", - "fix": "Deploy software capable of performing audit data reduction and of\n reporting on the excluded audit data." + "check": "Determine which OS accounts are used by the DBMS to run\n external procedures.\n\n Validate that these OS accounts have only the privileges necessary to perform\n the required functionality.\n\n If any OS accounts, utilized by the database for running external procedures,\n have privileges beyond those required for running the external procedures, this\n is a finding.\n\n If use of the external procedure agent is authorized, ensure extproc is\n restricted to execution of authorized applications.\n\n External jobs are run using the account nobody by default.\n\n Review the contents of the file ORACLE_HOME/rdbms/admin/externaljob.ora for the\n lines run_user= and run_group=.\n\n If the user assigned to these parameters is not \"nobody\", this is a finding.\n\n System views providing privilege information are:\n DBA_SYS_PRIVS\n DBA_TAB_PRIVS\n DBA_ROLE_PRIVS", + "fix": "Limit privileges to DBMS-related OS accounts to those required to\n perform their DBMS specific functionality." }, - "code": "control 'V-61969' do\n title \"The system must provide a report generation capability for audit\n reduction data.\"\n desc \"In support of Audit Review, Analysis, and Reporting requirements,\n audit reduction is a technique used to reduce the volume of audit records in\n order to facilitate a manual review.\n\n Before a security review is conducted, information systems and/or\n applications with an audit reduction capability may remove many audit records\n known to have little security significance. This is generally accomplished by\n removing records generated by specified classes of events, such as records\n generated by nightly backups.\n\n In order to identify and report on what (repetitive) data has been removed\n via the use of audit reduction, the application must provide a capability to\n generate reports containing what values were removed by the audit reduction.\n\n Audit reduction does not alter original audit records. An audit reduction\n capability provides support for near real-time audit review and analysis based\n on policy-based requirements and after-the-fact investigations of security\n incidents.\n\n Reporting tools employing audit reduction methods must not alter the\n original audit data. An example of a tool employing audit reduction methods is\n the Windows Event Viewer tool which is used to view and analyze audit logs on\n Windows systems.\n\n The lack of reporting tools for audit reduction can require the DBA, or\n others responsible for reviewing audit logs, to sort through large amounts of\n data in order to find relevant records. This can cause important audit records\n to be missed.\n \"\n impact 0.3\n tag \"gtitle\": 'SRG-APP-000114-DB-000054'\n tag \"gid\": 'V-61969'\n tag \"rid\": 'SV-76459r1_rule'\n tag \"stig_id\": 'O121-C3-008800'\n tag \"fix_id\": 'F-67889r1_fix'\n tag \"cci\": ['CCI-001878']\n tag \"nist\": ['AU-7 a', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Verify that audit reduction capabilities are in place for the\n Oracle audit data. Since Oracle has no reduction capability per se, a\n third-party tool or in-house-developed software must be in place to provide\n this functionality. This must include the ability to report on the excluded\n audit data.\n\n If this capability has not been implemented, this is a finding.\"\n tag \"fix\": \"Deploy software capable of performing audit data reduction and of\n reporting on the excluded audit data.\"\n describe 'A manual review is required to ensure the system provides a report generation capability for audit\n reduction data' do\n skip 'A manual review is required to ensure the system provides a report generation capability for audit\n reduction data'\n end\nend\n", + "code": " control 'V-61601' do\n impact 0.0\n describe 'This control is not applicable on oracle within aws rds, as aws manages the operating system in which the oracle database is running on' do\n skip 'This control is not applicable on oracle within aws rds, as aws manages the operating system in which the oracle database is running on'\n end\n end\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61969.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61601.rb", "line": 1 }, - "id": "V-61969" + "id": "V-61601" }, { - "title": "The DBMS must protect the integrity of publicly available information\n and applications.", - "desc": "The purpose of this control is to ensure organizations explicitly\n address the protection needs for public information and applications with such\n protection likely being implemented as part of other security controls.\n\n Databases designed to contain publicly available information, though not\n concerned with confidentiality, must still maintain the integrity of the data\n they house. If data available to the public is not protected from unauthorized\n modification, then it cannot be trusted by those accessing it.", + "title": "The DBMS must use NIST-validated FIPS 140-2-compliant cryptography\n for authentication mechanisms.", + "desc": "Encryption is only as good as the encryption modules utilized.\n Unapproved cryptographic module algorithms cannot be verified and cannot be\n relied upon to provide confidentiality or integrity, and DoD data may be\n compromised due to weak algorithms.\n\n Applications utilizing encryption are required to use approved encryption\n modules that meet the requirements of applicable federal laws, Executive\n Orders, directives, policies, regulations, standards, and guidance.\n\n FIPS 140-2 is the current standard for validating cryptographic modules,\n and NSA Type-X (where X=1, 2, 3, 4) products are NSA-certified hardware-based\n encryption modules.\n\n Authentication modules with weak encryption could allow an attacker to gain\n access to data stored in the database and to the administration settings of the\n DBMS.", "descriptions": { - "default": "The purpose of this control is to ensure organizations explicitly\n address the protection needs for public information and applications with such\n protection likely being implemented as part of other security controls.\n\n Databases designed to contain publicly available information, though not\n concerned with confidentiality, must still maintain the integrity of the data\n they house. If data available to the public is not protected from unauthorized\n modification, then it cannot be trusted by those accessing it." + "default": "Encryption is only as good as the encryption modules utilized.\n Unapproved cryptographic module algorithms cannot be verified and cannot be\n relied upon to provide confidentiality or integrity, and DoD data may be\n compromised due to weak algorithms.\n\n Applications utilizing encryption are required to use approved encryption\n modules that meet the requirements of applicable federal laws, Executive\n Orders, directives, policies, regulations, standards, and guidance.\n\n FIPS 140-2 is the current standard for validating cryptographic modules,\n and NSA Type-X (where X=1, 2, 3, 4) products are NSA-certified hardware-based\n encryption modules.\n\n Authentication modules with weak encryption could allow an attacker to gain\n access to data stored in the database and to the administration settings of the\n DBMS." }, - "impact": 0.5, - "refs": [], + "impact": 0, + "refs": [ + { + "ref": [] + } + ], "tags": { - "gtitle": "SRG-APP-000201-DB-000145", - "gid": "V-61763", - "rid": "SV-76253r1_rule", - "stig_id": "O121-C2-017100", - "fix_id": "F-67679r1_fix", + "gtitle": "SRG-APP-000179-DB-000114", + "gid": "V-61747", + "rid": "SV-76237r2_rule", + "stig_id": "O121-C2-015700", + "fix_id": "F-67663r2_fix", "cci": [ - "CCI-000366" + "CCI-000803" ], "nist": [ - "CM-6 b", + "IA-7", "Rev_4" ], "false_negatives": null, @@ -173,30 +181,30 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Determine whether the database houses and distributes\n information to the public. Review DBMS settings to determine whether controls\n exist to protect the integrity of publicly available information.\n\n If not, this is a finding.\n\n - - - - -\n All of the permissions and policies we would employ to protect information\n would be in play, like access control mechanisms, auditing, and password\n protection. For data that is for display or download to the public for their\n informational needs, it may be appropriate to place the data in a read-only\n tablespace. This will provide the DBA with the ability to modify content as\n needed by modifying the tablespace from read-only to read-write in the event\n the content needs to be modified. Check with the Application Developer to see\n what tables are used to store the data and/or content that is displayed to the\n public. Then find the tablespace name the data objects are stored in.\n\n $ sqlplus connect as sysdba\n\n SQL> SELECT table_name, tablespace_name from dba_tables where upper(table_name)\n like &tablename_from_developer;\n\n For better performance while accessing data in a read-only tablespace, can\n issue a query that accesses all of the blocks of the tables in the tablespace\n just before making it read-only. A simple query, such as SELECT COUNT (*),\n executed against each table ensures that the data blocks in the tablespace can\n be subsequently accessed most efficiently. This eliminates the need for the\n database to check the status of the transactions that most recently modified\n the blocks.\n\n The following statement makes the flights tablespace read-only:\n\n ALTER TABLESPACE flights READ ONLY;\n\n Can issue the ALTER TABLESPACE...READ ONLY statement while the database is\n processing transactions. After the statement is issued, the tablespace is put\n into a transitional read-only state. No transactions are allowed to make\n further changes (using DML statements) to the tablespace.\n\n If a transaction attempts further changes, it is terminated and rolled back.\n However, transactions that already made changes and that attempt no further\n changes are allowed to commit or roll back.\n\n The ALTER TABLESPACE...READ ONLY statement waits for the following transactions\n to either commit or roll back before returning: transactions that have pending\n or uncommitted changes to the tablespace and that were started before the\n statement was issued.\n\n If a transaction started before the statement remains active, but rolls back to\n a savepoint, rolling back its changes to the tablespace, then the statement no\n longer waits for this active transaction.", - "fix": "Apply appropriate controls to protect the integrity of publicly\n available information.\n\n - - - - -\n If the appropriate controls include placing the data in a read-only tablespace,\n proceed as follows.\n\n After we figure out the tablespace the data object is stored in:\n $ sqlplus connect as sysdba\n SQL> SELECT table_name, tablespace_name from dba_tables where upper(table_name)\n like &tablename_from_developer;\n\n Once we get the name of the tablespace where all of the important data is\n stored, alter the tablespace to be read-only.\n SQL> ALTER TABLESPACE &tablespace_where_data_is READ ONLY;\n\n The following statement makes the flights tablespace read-only:\n ALTER TABLESPACE flights READ ONLY;\n\n Can issue the ALTER TABLESPACE...READ ONLY statement while the database is\n processing transactions. After the statement is issued, the tablespace is put\n into a transitional read-only state. No transactions are allowed to make\n further changes (using DML statements) to the tablespace. If a transaction\n attempts further changes, it is terminated and rolled back. However,\n transactions that already made changes and that attempt no further changes are\n allowed to commit or roll back.\n\n The ALTER TABLESPACE...READ ONLY statement waits for the following transactions\n to either commit or roll back before returning: transactions that have pending\n or uncommitted changes to the tablespace and that were started before the\n statement was issued. If a transaction started before the statement remains\n active, but rolls back to a savepoint, rolling back its changes to the\n tablespace, then the statement no longer waits for this active transaction." + "check": "Check the following settings to see if FIPS 140-2\n authentication/encryption is configured. If encryption is required but not\n configured, check with the DBA and system administrator to see if other\n mechanisms or third-party cryptography products are deployed for authentication.\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 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.", + "fix": "Utilize NIST-validated FIPS 140-2-compliant cryptography for all\n authentication mechanisms.\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 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).\n\n There is more information on this topic in the Oracle Database 12c Advanced\n Security Administrator's Guide, which may be found at\n https://docs.oracle.com/database/121/DBSEG/E48135-11.pdf. (Note, however, that\n because of changes in Oracle's licensing policy, it is no longer necessary to\n purchase Oracle Advanced Security to use network encryption and advanced\n authentication.)\n\n FIPS 140-2 documentation can be downloaded from\n http://csrc.nist.gov/publications/PubsFIPS.html#140-2 " }, - "code": "control 'V-61763' do\n title \"The DBMS must protect the integrity of publicly available information\n and applications.\"\n desc \"The purpose of this control is to ensure organizations explicitly\n address the protection needs for public information and applications with such\n protection likely being implemented as part of other security controls.\n\n Databases designed to contain publicly available information, though not\n concerned with confidentiality, must still maintain the integrity of the data\n they house. If data available to the public is not protected from unauthorized\n modification, then it cannot be trusted by those accessing it.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000201-DB-000145'\n tag \"gid\": 'V-61763'\n tag \"rid\": 'SV-76253r1_rule'\n tag \"stig_id\": 'O121-C2-017100'\n tag \"fix_id\": 'F-67679r1_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\": \"Determine whether the database houses and distributes\n information to the public. Review DBMS settings to determine whether controls\n exist to protect the integrity of publicly available information.\n\n If not, this is a finding.\n\n - - - - -\n All of the permissions and policies we would employ to protect information\n would be in play, like access control mechanisms, auditing, and password\n protection. For data that is for display or download to the public for their\n informational needs, it may be appropriate to place the data in a read-only\n tablespace. This will provide the DBA with the ability to modify content as\n needed by modifying the tablespace from read-only to read-write in the event\n the content needs to be modified. Check with the Application Developer to see\n what tables are used to store the data and/or content that is displayed to the\n public. Then find the tablespace name the data objects are stored in.\n\n $ sqlplus connect as sysdba\n\n SQL> SELECT table_name, tablespace_name from dba_tables where upper(table_name)\n like &tablename_from_developer;\n\n For better performance while accessing data in a read-only tablespace, can\n issue a query that accesses all of the blocks of the tables in the tablespace\n just before making it read-only. A simple query, such as SELECT COUNT (*),\n executed against each table ensures that the data blocks in the tablespace can\n be subsequently accessed most efficiently. This eliminates the need for the\n database to check the status of the transactions that most recently modified\n the blocks.\n\n The following statement makes the flights tablespace read-only:\n\n ALTER TABLESPACE flights READ ONLY;\n\n Can issue the ALTER TABLESPACE...READ ONLY statement while the database is\n processing transactions. After the statement is issued, the tablespace is put\n into a transitional read-only state. No transactions are allowed to make\n further changes (using DML statements) to the tablespace.\n\n If a transaction attempts further changes, it is terminated and rolled back.\n However, transactions that already made changes and that attempt no further\n changes are allowed to commit or roll back.\n\n The ALTER TABLESPACE...READ ONLY statement waits for the following transactions\n to either commit or roll back before returning: transactions that have pending\n or uncommitted changes to the tablespace and that were started before the\n statement was issued.\n\n If a transaction started before the statement remains active, but rolls back to\n a savepoint, rolling back its changes to the tablespace, then the statement no\n longer waits for this active transaction.\"\n tag \"fix\": \"Apply appropriate controls to protect the integrity of publicly\n available information.\n\n - - - - -\n If the appropriate controls include placing the data in a read-only tablespace,\n proceed as follows.\n\n After we figure out the tablespace the data object is stored in:\n $ sqlplus connect as sysdba\n SQL> SELECT table_name, tablespace_name from dba_tables where upper(table_name)\n like &tablename_from_developer;\n\n Once we get the name of the tablespace where all of the important data is\n stored, alter the tablespace to be read-only.\n SQL> ALTER TABLESPACE &tablespace_where_data_is READ ONLY;\n\n The following statement makes the flights tablespace read-only:\n ALTER TABLESPACE flights READ ONLY;\n\n Can issue the ALTER TABLESPACE...READ ONLY statement while the database is\n processing transactions. After the statement is issued, the tablespace is put\n into a transitional read-only state. No transactions are allowed to make\n further changes (using DML statements) to the tablespace. If a transaction\n attempts further changes, it is terminated and rolled back. However,\n transactions that already made changes and that attempt no further changes are\n allowed to commit or roll back.\n\n The ALTER TABLESPACE...READ ONLY statement waits for the following transactions\n to either commit or roll back before returning: transactions that have pending\n or uncommitted changes to the tablespace and that were started before the\n statement was issued. If a transaction started before the statement remains\n active, but rolls back to a savepoint, rolling back its changes to the\n tablespace, then the statement no longer waits for this active transaction.\"\n describe 'A manual review is required to ensure the DBMS protects the integrity of publicly available information\n and applications.' do\n skip 'A manual review is required to ensure the DBMS protects the integrity of publicly available information\n and applications.'\n end\nend\n", + "code": " control 'V-61747' 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-61763.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61747.rb", "line": 1 }, - "id": "V-61763" + "id": "V-61747" }, { - "title": "The ISSM must review changes to DBA role assignments.", - "desc": "Unauthorized assignment of DBA privileges can lead to a compromise of\n DBMS integrity. Providing oversight to the authorization and assignment of\n privileges provides the separation of duty to support sufficient oversight.", + "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": "Unauthorized assignment of DBA privileges can lead to a compromise of\n DBMS integrity. Providing oversight to the authorization and assignment of\n privileges provides the separation of duty to support sufficient oversight." + "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.5, "refs": [], "tags": { "gtitle": "SRG-APP-000516-DB-999900", - "gid": "V-61497", - "rid": "SV-75987r1_rule", - "stig_id": "O121-BP-024600", - "fix_id": "F-67413r1_fix", + "gid": "V-61413", + "rid": "SV-75903r1_rule", + "stig_id": "O121-BP-021300", + "fix_id": "F-67329r1_fix", "cci": [ "CCI-000366" ], @@ -214,39 +222,39 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Review policy and procedures documented or noted in the System\n Security Plan as well as evidence of implementation for monitoring changes to\n DBA role assignments and procedures for notifying the ISSM of the changes for\n review.\n\n If policy, procedures or implementation evidence do not exist, this is a\n finding.", - "fix": "Develop, document and implement procedures to monitor changes to\n DBA role assignments.\n\n Develop, document and implement procedures to notify the ISSM of changes to DBA\n role assignments.\n\n Include in the procedures methods that provide evidence of monitoring and\n notification." + "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-61497' do\n title 'The ISSM must review changes to DBA role assignments.'\n desc \"Unauthorized assignment of DBA privileges can lead to a compromise of\n DBMS integrity. Providing oversight to the authorization and assignment of\n privileges provides the separation of duty to support sufficient oversight.\"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000516-DB-999900'\n tag \"gid\": 'V-61497'\n tag \"rid\": 'SV-75987r1_rule'\n tag \"stig_id\": 'O121-BP-024600'\n tag \"fix_id\": 'F-67413r1_fix'\n tag \"cci\": ['CCI-000366']\n tag \"nist\": ['CM-6 b', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Review policy and procedures documented or noted in the System\n Security Plan as well as evidence of implementation for monitoring changes to\n DBA role assignments and procedures for notifying the ISSM of the changes for\n review.\n\n If policy, procedures or implementation evidence do not exist, this is a\n finding.\"\n tag \"fix\": \"Develop, document and implement procedures to monitor changes to\n DBA role assignments.\n\n Develop, document and implement procedures to notify the ISSM of changes to DBA\n role assignments.\n\n Include in the procedures methods that provide evidence of monitoring and\n notification.\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n database_roles = sql.query('select * from dba_roles;').column('role')\n\n describe \"A manual review is required to ensure the ISSM reviews changes to DBA role assignments. The database roles to review are: #{database_roles}\" do\n skip \"A manual review is required to ensure the ISSM reviews changes to DBA role assignments. The database roles to review are: #{database_roles}\"\n end\nend\n", + "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-61497.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61413.rb", "line": 1 }, - "id": "V-61497" + "id": "V-61413" }, { - "title": "The DBMS must support organizational requirements to enforce password\n complexity by the number of upper-case characters used.", - "desc": "Password complexity or strength is a measure of the effectiveness of a\n password in resisting attempts at guessing and brute-force attacks.\n\n Password complexity is one factor of several that determine how long it\n takes to crack a password. The more complex the password is, the greater the\n number of possible combinations that need to be tested before the password is\n compromised.\n\n Use of a complex password helps to increase the time and resources required\n to compromise the password.\n\n Note that user authentication and account management must be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP This requirement applies to cases where it is necessary to\n have accounts directly managed by Oracle.", + "title": "Access to DBMS software files and directories must not be granted to\n unauthorized users.", + "desc": "The DBMS software libraries contain the executables used by the DBMS\n to operate. Unauthorized access to the libraries can result in malicious\n alteration or planting of operational executables. This may in turn jeopardize\n data stored in the DBMS and/or operation of the host system.", "descriptions": { - "default": "Password complexity or strength is a measure of the effectiveness of a\n password in resisting attempts at guessing and brute-force attacks.\n\n Password complexity is one factor of several that determine how long it\n takes to crack a password. The more complex the password is, the greater the\n number of possible combinations that need to be tested before the password is\n compromised.\n\n Use of a complex password helps to increase the time and resources required\n to compromise the password.\n\n Note that user authentication and account management must be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP This requirement applies to cases where it is necessary to\n have accounts directly managed by Oracle." + "default": "The DBMS software libraries contain the executables used by the DBMS\n to operate. Unauthorized access to the libraries can result in malicious\n alteration or planting of operational executables. This may in turn jeopardize\n data stored in the DBMS and/or operation of the host system." }, - "impact": 0.5, + "impact": 0, "refs": [ { "ref": [] } ], "tags": { - "gtitle": "SRG-APP-000166-DB-000070", - "gid": "V-61723", - "rid": "SV-76213r1_rule", - "stig_id": "O121-C2-014100", - "fix_id": "F-67639r1_fix", + "gtitle": "SRG-APP-000516-DB-999900", + "gid": "V-61511", + "rid": "SV-76001r1_rule", + "stig_id": "O121-BP-025400", + "fix_id": "F-67427r1_fix", "cci": [ - "CCI-000192" + "CCI-000366" ], "nist": [ - "IA-5 (1) (a)", + "CM-6 b", "Rev_4" ], "false_negatives": null, @@ -259,21 +267,21 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "If all user accounts are managed and authenticated by the OS or\n an enterprise-level authentication/access mechanism, and not by Oracle, this is\n not a finding.\n\n For each profile that can be applied to accounts where authentication is under\n Oracle's control, determine the password verification function, if any, that is\n in use:\n\n SELECT * FROM SYS.DBA_PROFILES\n WHERE RESOURCE_NAME = 'PASSWORD_VERIFY_FUNCTION'\n [AND PROFILE NOT IN ()]\n ORDER BY PROFILE;\n Bearing in mind that a profile can inherit from another profile, and the root\n profile is called DEFAULT, determine the name of the password verification\n function effective for each profile.\n\n If, for any profile, the function name is null, this is a finding.\n\n For each password verification function, examine its source code. If it does\n not enforce the organization-defined minimum number of upper-case characters (1\n unless otherwise specified), this is a finding.", - "fix": "If all user accounts are authenticated by the OS or an\n enterprise-level authentication/access mechanism, and not by Oracle, no fix to\n the DBMS is required.\n\n If any user accounts are managed by Oracle: Develop, test and implement a\n password verification function that enforces DoD requirements.\n\n (Oracle supplies a sample function called ORA12C_STRONG_VERIFY_FUNCTION, in the\n script file\n /RDBMS/ADMIN/utlpwdmg.sql. This can be used as the starting point\n for a customized function.)" + "check": "For UNIX Systems:\n\n log on using the Oracle software owner account and enter the command:\n\n umask\n\n If the value returned is 022 or more restrictive, this is not a finding.\n\n If the value returned is less restrictive than 022, this is a finding.\n\n The first number sets the mask for user/owner file permissions. The second\n number sets the mask for group file permissions. The third number sets file\n permission mask for other users. The list below shows the available settings:\n\n 0 = read/write/execute\n 1 = read/write\n 2 = read/execute\n 3 = read\n 4 = write/execute\n 5 = write\n 6 = execute\n 7 = no permissions\n\n Setting the umask to 022 effectively sets files for user/owner to read/write,\n group to read and other to read. Directories are set for user/owner to\n read/write/execute, group to read/execute and other to read/execute.\n\n For Windows Systems:\n Review the permissions that control access to the Oracle installation software\n directories (e.g. \\Program Files\\Oracle\\).\n\n DBA accounts, the DBMS process account, the DBMS software\n installation/maintenance account, SA accounts if access by them is required for\n some operational level of support such as backups, and the host system itself\n require access.\n\n Compare the access control employed with that documented in the System Security\n Plan.\n\n If access controls do not match the documented requirement, this is a finding.\n\n If access controls appear excessive without justification, this is a finding.", + "fix": "For UNIX Systems:\n\n Set the umask of the Oracle software owner account to 022. Determine the shell\n being used for the Oracle software owner account:\n\n env | grep -i shell\n\n Startup files for each shell are as follows (located in users $HOME directory):\n\n C-Shell (CSH) = .cshrc\n Bourne Shell (SH) = .profile\n Korn Shell (KSH) = .kshrc\n TC Shell (TCS) = .tcshrc\n BASH Shell = .bash_profile or .bashrc\n\n Edit the shell startup file for the account and add or modify the line:\n\n umask 022\n\n Log off and logon, then enter the umask command to confirm the setting.\n\n Note: To effect this change for all Oracle processes, a reboot of the DBMS\n server may be required.\n\n For Windows Systems:\n Restrict access to the DBMS software libraries to the fewest accounts that\n clearly require access based on job function.\n\n Document authorized access controls and justify any access grants that do not\n fall under DBA, DBMS process, ownership, or SA accounts." }, - "code": "control 'V-61723' do\n title \"The DBMS must support organizational requirements to enforce password\n complexity by the number of upper-case characters used.\"\n desc \"Password complexity or strength is a measure of the effectiveness of a\n password in resisting attempts at guessing and brute-force attacks.\n\n Password complexity is one factor of several that determine how long it\n takes to crack a password. The more complex the password is, the greater the\n number of possible combinations that need to be tested before the password is\n compromised.\n\n Use of a complex password helps to increase the time and resources required\n to compromise the password.\n\n Note that user authentication and account management must be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP This requirement applies to cases where it is necessary to\n have accounts directly managed by Oracle.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000166-DB-000070'\n tag \"gid\": 'V-61723'\n tag \"rid\": 'SV-76213r1_rule'\n tag \"stig_id\": 'O121-C2-014100'\n tag \"fix_id\": 'F-67639r1_fix'\n tag \"cci\": ['CCI-000192']\n tag \"nist\": ['IA-5 (1) (a)', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"If all user accounts are managed and authenticated by the OS or\n an enterprise-level authentication/access mechanism, and not by Oracle, this is\n not a finding.\n\n For each profile that can be applied to accounts where authentication is under\n Oracle's control, determine the password verification function, if any, that is\n in use:\n\n SELECT * FROM SYS.DBA_PROFILES\n WHERE RESOURCE_NAME = 'PASSWORD_VERIFY_FUNCTION'\n [AND PROFILE NOT IN ()]\n ORDER BY PROFILE;\n Bearing in mind that a profile can inherit from another profile, and the root\n profile is called DEFAULT, determine the name of the password verification\n function effective for each profile.\n\n If, for any profile, the function name is null, this is a finding.\n\n For each password verification function, examine its source code. If it does\n not enforce the organization-defined minimum number of upper-case characters (1\n unless otherwise specified), this is a finding.\"\n tag \"fix\": \"If all user accounts are authenticated by the OS or an\n enterprise-level authentication/access mechanism, and not by Oracle, no fix to\n the DBMS is required.\n\n If any user accounts are managed by Oracle: Develop, test and implement a\n password verification function that enforces DoD requirements.\n\n (Oracle supplies a sample function called ORA12C_STRONG_VERIFY_FUNCTION, in the\n script file\n /RDBMS/ADMIN/utlpwdmg.sql. This can be used as the starting point\n for a customized function.)\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n query = %{\n SELECT PROFILE, RESOURCE_NAME, LIMIT FROM DBA_PROFILES WHERE PROFILE =\n '%s' AND RESOURCE_NAME = 'PASSWORD_VERIFY_FUNCTION'\n }\n\n user_profiles = sql.query('SELECT profile FROM dba_users;').column('profile').uniq\n\n user_profiles.each do |profile|\n next if profile == \"RDSADMIN\"\n password_verify_function = sql.query(format(query, profile: profile)).column('limit')\n\n describe \"The oracle database account password verify function for profile: #{profile}\" do\n subject { password_verify_function }\n it { should_not eq ['NULL'] }\n end\n end\n if user_profiles.empty?\n describe 'There are no user profiles, therefore this control is NA' do\n skip 'There are no user profiles, therefore this control is NA'\n end\n end\nend\n", + "code": " control 'V-61511' 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-61723.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61511.rb", "line": 1 }, - "id": "V-61723" + "id": "V-61511" }, { - "title": "The /diag subdirectory under the directory assigned to the\n DIAGNOSTIC_DEST parameter must be protected from unauthorized access.", - "desc": "/diag indicates the directory where trace, alert, core and incident directories and files are located. The files may contain sensitive data or information that could prove useful to potential attackers.", + "title": "The DBMS must employ cryptographic mechanisms to protect the integrity\n and confidentiality of nonlocal maintenance and diagnostic communications.", + "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 communication channels used to\n remotely access the system are adequately protected. If the communication\n channel is not adequately protected authentication information, application\n data, and configuration information could be compromised.", "descriptions": { - "default": "/diag indicates the directory where trace, alert, core and incident directories and files are located. The files may contain sensitive data or information that could prove useful to potential attackers." + "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 communication channels used to\n remotely access the system are adequately protected. If the communication\n channel is not adequately protected authentication information, application\n data, and configuration information could be compromised." }, "impact": 0, "refs": [ @@ -282,16 +290,17 @@ } ], "tags": { - "gtitle": "SRG-APP-000516-DB-999900", - "gid": "V-61531", - "rid": "SV-76021r2_rule", - "stig_id": "O121-BP-026400", - "fix_id": "F-67447r2_fix", + "gtitle": "SRG-APP-000184-DB-000119", + "gid": "V-61749", + "rid": "SV-76239r1_rule", + "stig_id": "O121-C2-016000", + "fix_id": "F-67665r1_fix", "cci": [ - "CCI-000366" + "CCI-002890", + "CCI-003123" ], "nist": [ - "CM-6 b", + "MA-4 (6)", "Rev_4" ], "false_negatives": null, @@ -304,35 +313,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "From SQL*Plus:\n\n select value from v$parameter where name='diagnostic_dest';\n\n On UNIX Systems:\n\n ls -ld [pathname]/diag\n\n Substitute [pathname] with the directory path listed from the above SQL\n command, and append \"/diag\" to it, as shown.\n\n If permissions are granted for world access, this is a Finding.\n\n If any groups that include members other than the Oracle process and software\n owner accounts, DBAs, auditors, or backup accounts are listed, this is a\n Finding.\n\n On Windows Systems (From Windows Explorer):\n\n Browse to the \\diag directory under the directory specified.\n\n Select and right-click on the directory, select Properties, select the Security\n tab.\n\n If permissions are granted to everyone, this is a Finding.\n\n If any account other than the Oracle process and software owner accounts,\n Administrators, DBAs, System group or developers authorized to write and debug\n applications on this database are listed, this is a Finding.", - "fix": "Alter host system permissions to the /diag\n directory to the Oracle process and software owner accounts, DBAs, SAs (if\n required) and developers or other users that may specifically require access\n for debugging or other purposes.\n\n Authorize and document user access requirements to the directory outside of the\n Oracle, DBA and SA account list." + "check": "Review DBMS configuration to determine if cryptographic\n mechanisms are being utilized to protect the integrity and confidentiality of\n nonlocal maintenance and diagnostic communications.\n\n If not, this is a finding.", + "fix": "Configure DBMS to utilize cryptographic mechanisms to protect the\n integrity and confidentiality of nonlocal maintenance and diagnostic\n communications." }, - "code": " control 'V-61531' 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-61749' 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-61531.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61749.rb", "line": 1 }, - "id": "V-61531" + "id": "V-61749" }, { - "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.", + "title": "The DBMS must uniquely identify and authenticate organizational users\n (or processes acting on behalf of organizational users).", + "desc": "To assure accountability and prevent unauthorized access,\n organizational users shall be identified and authenticated.\n\n Organizational users include organizational employees or individuals the\n organization deems to have equivalent status of employees (e.g., contractors,\n guest researchers, individuals from allied nations).\n\n Users (and any processes acting on behalf of users) are uniquely identified\n and authenticated for all accesses other than those accesses explicitly\n identified and documented by the organization which outlines specific user\n actions that can be performed on the information system without identification\n or authentication.", "descriptions": { - "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." + "default": "To assure accountability and prevent unauthorized access,\n organizational users shall be identified and authenticated.\n\n Organizational users include organizational employees or individuals the\n organization deems to have equivalent status of employees (e.g., contractors,\n guest researchers, individuals from allied nations).\n\n Users (and any processes acting on behalf of users) are uniquely identified\n and authenticated for all accesses other than those accesses explicitly\n identified and documented by the organization which outlines specific user\n actions that can be performed on the information system without identification\n or authentication." }, "impact": 0.5, "refs": [], "tags": { - "gtitle": "SRG-APP-000177-DB-000069", - "gid": "V-61745", - "rid": "SV-76235r2_rule", - "stig_id": "O121-C2-015501", - "fix_id": "F-67661r1_fix", + "gtitle": "SRG-APP-000148-DB-000103", + "gid": "V-61879", + "rid": "SV-76369r1_rule", + "stig_id": "O121-P2-012800", + "fix_id": "F-67795r1_fix", "cci": [ - "CCI-000366" + "CCI-000764" ], "nist": [ - "CM-6 b", + "IA-2", "Rev_4" ], "false_negatives": null, @@ -345,82 +354,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "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." + "check": "Review DBMS settings, OS settings, and/or enterprise-level\n authentication/access mechanism settings, and site practices, to determine\n whether organizational users are uniquely identified and authenticated when\n logging on to the system.\n\n If organizational users are not uniquely identified and authenticated, this is\n a finding.", + "fix": "Configure DBMS, OS and/or enterprise-level authentication/access\n mechanism to uniquely identify and authenticate all organizational users who\n log on to the system. Ensure that each user has a separate account from all\n other users." }, - "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", + "code": "control 'V-61879' do\n title \"The DBMS must uniquely identify and authenticate organizational users\n (or processes acting on behalf of organizational users).\"\n desc \"To assure accountability and prevent unauthorized access,\n organizational users shall be identified and authenticated.\n\n Organizational users include organizational employees or individuals the\n organization deems to have equivalent status of employees (e.g., contractors,\n guest researchers, individuals from allied nations).\n\n Users (and any processes acting on behalf of users) are uniquely identified\n and authenticated for all accesses other than those accesses explicitly\n identified and documented by the organization which outlines specific user\n actions that can be performed on the information system without identification\n or authentication.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000148-DB-000103'\n tag \"gid\": 'V-61879'\n tag \"rid\": 'SV-76369r1_rule'\n tag \"stig_id\": 'O121-P2-012800'\n tag \"fix_id\": 'F-67795r1_fix'\n tag \"cci\": ['CCI-000764']\n tag \"nist\": ['IA-2', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Review DBMS settings, OS settings, and/or enterprise-level\n authentication/access mechanism settings, and site practices, to determine\n whether organizational users are uniquely identified and authenticated when\n logging on to the system.\n\n If organizational users are not uniquely identified and authenticated, this is\n a finding.\"\n tag \"fix\": \"Configure DBMS, OS and/or enterprise-level authentication/access\n mechanism to uniquely identify and authenticate all organizational users who\n log on to the system. Ensure that each user has a separate account from all\n other users.\"\n describe 'A manual review is required to ensure the DBMS uniquely identifies and authenticates organizational users\n (or processes acting on behalf of organizational users).' do\n skip 'A manual review is required to ensure the DBMS uniquely identifies and authenticates organizational users\n (or processes acting on behalf of organizational users).'\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61745.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61879.rb", "line": 1 }, - "id": "V-61745" + "id": "V-61879" }, { - "title": "The DBMS must employ cryptographic mechanisms to protect the integrity\n and confidentiality of nonlocal maintenance and diagnostic communications.", - "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 communication channels used to\n remotely access the system are adequately protected. If the communication\n channel is not adequately protected authentication information, application\n data, and configuration information could be compromised.", - "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 communication channels used to\n remotely access the system are adequately protected. If the communication\n channel is not adequately protected authentication information, application\n data, and configuration information could be compromised." - }, - "impact": 0, - "refs": [ - { - "ref": [] - } - ], - "tags": { - "gtitle": "SRG-APP-000184-DB-000119", - "gid": "V-61749", - "rid": "SV-76239r1_rule", - "stig_id": "O121-C2-016000", - "fix_id": "F-67665r1_fix", - "cci": [ - "CCI-002890", - "CCI-003123" - ], - "nist": [ - "MA-4 (6)", - "Rev_4" - ], - "false_negatives": null, - "false_positives": null, - "documentable": false, - "mitigations": null, - "severity_override_guidance": false, - "potential_impacts": null, - "third_party_tools": null, - "mitigation_controls": null, - "responsibility": null, - "ia_controls": null, - "check": "Review DBMS configuration to determine if cryptographic\n mechanisms are being utilized to protect the integrity and confidentiality of\n nonlocal maintenance and diagnostic communications.\n\n If not, this is a finding.", - "fix": "Configure DBMS to utilize cryptographic mechanisms to protect the\n integrity and confidentiality of nonlocal maintenance and diagnostic\n communications." - }, - "code": " control 'V-61749' 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-61749.rb", - "line": 1 - }, - "id": "V-61749" - }, - { - "title": "The DBMS must be protected from unauthorized access by developers on\n shared production/development host systems.", - "desc": "Applications employ the concept of least privilege for specific duties\n and information systems (including specific functions, ports, protocols, and\n services). The concept of least privilege is also applied to information system\n processes, ensuring that the processes operate at privilege levels no higher\n than necessary to accomplish required organizational missions and/or functions.\n Organizations consider the creation of additional processes, roles, and\n information system accounts as necessary to achieve least privilege.\n Organizations also apply least privilege concepts to the design, development,\n implementation, and operations of information systems.\n\n Developers granted elevated database and/or operating system privileges on\n systems that support both development and production databases can affect the\n operation and/or security of the production database system. Operating system\n and database privileges assigned to developers on shared development and\n production systems must be restricted.", + "title": "A DBMS utilizing Discretionary Access Control (DAC) must enforce a\n policy that includes or excludes access to the granularity of a single user.", + "desc": "DAC is based on the notion that individual users are \"owners\" of\n objects and therefore have discretion over who should be authorized to access\n the object and in which mode (e.g., read or write). Ownership is usually\n acquired as a consequence of creating the object or via specified ownership\n assignment.\n\n DAC allows the owner to determine who will have access to objects they\n control. An example of DAC includes user-controlled file permissions.\n\n Including or excluding access to the granularity of a single user means\n providing the capability to either allow or deny access to objects (e.g.,\n files, folders) on a per single user basis.\n\n Databases using DAC must have the ability for the owner of an object or\n information to assign or revoke rights to view or modify the object or\n information. If the owner of an object or information does not have rights to\n exclude access to an object or information at a user level, users may gain\n access to objects and information they are not authorized to view/modify.", "descriptions": { - "default": "Applications employ the concept of least privilege for specific duties\n and information systems (including specific functions, ports, protocols, and\n services). The concept of least privilege is also applied to information system\n processes, ensuring that the processes operate at privilege levels no higher\n than necessary to accomplish required organizational missions and/or functions.\n Organizations consider the creation of additional processes, roles, and\n information system accounts as necessary to achieve least privilege.\n Organizations also apply least privilege concepts to the design, development,\n implementation, and operations of information systems.\n\n Developers granted elevated database and/or operating system privileges on\n systems that support both development and production databases can affect the\n operation and/or security of the production database system. Operating system\n and database privileges assigned to developers on shared development and\n production systems must be restricted." + "default": "DAC is based on the notion that individual users are \"owners\" of\n objects and therefore have discretion over who should be authorized to access\n the object and in which mode (e.g., read or write). Ownership is usually\n acquired as a consequence of creating the object or via specified ownership\n assignment.\n\n DAC allows the owner to determine who will have access to objects they\n control. An example of DAC includes user-controlled file permissions.\n\n Including or excluding access to the granularity of a single user means\n providing the capability to either allow or deny access to objects (e.g.,\n files, folders) on a per single user basis.\n\n Databases using DAC must have the ability for the owner of an object or\n information to assign or revoke rights to view or modify the object or\n information. If the owner of an object or information does not have rights to\n exclude access to an object or information at a user level, users may gain\n access to objects and information they are not authorized to view/modify." }, "impact": 0.5, "refs": [], "tags": { - "gtitle": "SRG-APP-000062-DB-000015", - "gid": "V-61587", - "rid": "SV-76077r1_rule", - "stig_id": "O121-C2-003800", - "fix_id": "F-67503r1_fix", + "gtitle": "SRG-APP-000087-DB-000013", + "gid": "V-61619", + "rid": "SV-76109r1_rule", + "stig_id": "O121-C2-006700", + "fix_id": "F-67535r1_fix", "cci": [ - "CCI-000366", - "CCI-002220" + "CCI-002165" ], "nist": [ - "AC-5 c", + "AC-3 (4)", "Rev_4" ], "false_negatives": null, @@ -433,35 +395,39 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Identify whether any hosts contain both development and\n production databases. If no hosts contain both production and development\n databases, this is NA.\n\n For any host containing both a development and a production database, determine\n if developers have been granted elevated privileges on the production database\n or on the OS. If they have, ask for documentation that shows these accounts\n have formal approval and risk acceptance. If this documentation does not exist,\n this is a finding.\n\n If developer accounts exist with the right to create and maintain tables (or\n other database objects) in production tablespaces, this is a finding.\n\n (Where applicable, to check the number of instances on the host machine, check\n the /etc/oratab. The /etc/oratab file is updated by the Oracle Installer when\n the database is installed when the root.sh file is executed. Each line in the\n represents an ORACLE_SID:ORACLE_HOME:Y or N. The ORACLE_SID and ORACLE_HOME\n are self-explanatory. The Y or N signals the DBSTART program to automatically\n start or not start that specific instance when the machine is restarted. Check\n with the system owner and application development team to see what each entry\n represents. If a system is deemed to be a production system, review the system\n for development users.)", - "fix": "Restrict developer privileges to production objects to only\n objects and data where those privileges are required and authorized. Document\n the approval and risk acceptance.\n\n Consider using separate accounts for a person's developer duties and production\n duties. At a minimum, use separate roles for developer privileges and\n production privileges.\n\n If developers need the ability to create and maintain tables (or other database\n objects) as part of their development activities, provide dedicated\n tablespaces, and revoke any rights that allowed them to use production\n tablespaces for this purpose." + "check": "Check DBMS settings and documentation to determine if users are\n able to assign and revoke rights to the objects and information they own. If\n users cannot assign or revoke rights to the objects and information they own to\n the granularity of a single user, this is a finding.\n\n (This is default Oracle behavior.)", + "fix": "Modify DBMS settings to allow users to assign or revoke access\n rights to objects and information owned by the user. The ability to grant or\n revoke rights must include the ability to grant or revoke those rights down to\n the granularity of a single user.\n\n (This is default Oracle behavior.)" }, - "code": "control 'V-61587' do\n title \"The DBMS must be protected from unauthorized access by developers on\n shared production/development host systems.\"\n desc \"Applications employ the concept of least privilege for specific duties\n and information systems (including specific functions, ports, protocols, and\n services). The concept of least privilege is also applied to information system\n processes, ensuring that the processes operate at privilege levels no higher\n than necessary to accomplish required organizational missions and/or functions.\n Organizations consider the creation of additional processes, roles, and\n information system accounts as necessary to achieve least privilege.\n Organizations also apply least privilege concepts to the design, development,\n implementation, and operations of information systems.\n\n Developers granted elevated database and/or operating system privileges on\n systems that support both development and production databases can affect the\n operation and/or security of the production database system. Operating system\n and database privileges assigned to developers on shared development and\n production systems must be restricted.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000062-DB-000015'\n tag \"gid\": 'V-61587'\n tag \"rid\": 'SV-76077r1_rule'\n tag \"stig_id\": 'O121-C2-003800'\n tag \"fix_id\": 'F-67503r1_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\": \"Identify whether any hosts contain both development and\n production databases. If no hosts contain both production and development\n databases, this is NA.\n\n For any host containing both a development and a production database, determine\n if developers have been granted elevated privileges on the production database\n or on the OS. If they have, ask for documentation that shows these accounts\n have formal approval and risk acceptance. If this documentation does not exist,\n this is a finding.\n\n If developer accounts exist with the right to create and maintain tables (or\n other database objects) in production tablespaces, this is a finding.\n\n (Where applicable, to check the number of instances on the host machine, check\n the /etc/oratab. The /etc/oratab file is updated by the Oracle Installer when\n the database is installed when the root.sh file is executed. Each line in the\n represents an ORACLE_SID:ORACLE_HOME:Y or N. The ORACLE_SID and ORACLE_HOME\n are self-explanatory. The Y or N signals the DBSTART program to automatically\n start or not start that specific instance when the machine is restarted. Check\n with the system owner and application development team to see what each entry\n represents. If a system is deemed to be a production system, review the system\n for development users.)\"\n tag \"fix\": \"Restrict developer privileges to production objects to only\n objects and data where those privileges are required and authorized. Document\n the approval and risk acceptance.\n\n Consider using separate accounts for a person's developer duties and production\n duties. At a minimum, use separate roles for developer privileges and\n production privileges.\n\n If developers need the ability to create and maintain tables (or other database\n objects) as part of their development activities, provide dedicated\n tablespaces, and revoke any rights that allowed them to use production\n tablespaces for this purpose.\"\n describe 'A manual review is required to ensure the DBMS is protected from unauthorized access by developers on\n shared production/development host systems.' do\n skip 'A manual review is required to ensure the DBMS is protected from unauthorized access by developers on\n shared production/development host systems.'\n end\nend\n", + "code": "control 'V-61619' do\n title \"A DBMS utilizing Discretionary Access Control (DAC) must enforce a\n policy that includes or excludes access to the granularity of a single user.\"\n desc \"DAC is based on the notion that individual users are \\\"owners\\\" of\n objects and therefore have discretion over who should be authorized to access\n the object and in which mode (e.g., read or write). Ownership is usually\n acquired as a consequence of creating the object or via specified ownership\n assignment.\n\n DAC allows the owner to determine who will have access to objects they\n control. An example of DAC includes user-controlled file permissions.\n\n Including or excluding access to the granularity of a single user means\n providing the capability to either allow or deny access to objects (e.g.,\n files, folders) on a per single user basis.\n\n Databases using DAC must have the ability for the owner of an object or\n information to assign or revoke rights to view or modify the object or\n information. If the owner of an object or information does not have rights to\n exclude access to an object or information at a user level, users may gain\n access to objects and information they are not authorized to view/modify.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000087-DB-000013'\n tag \"gid\": 'V-61619'\n tag \"rid\": 'SV-76109r1_rule'\n tag \"stig_id\": 'O121-C2-006700'\n tag \"fix_id\": 'F-67535r1_fix'\n tag \"cci\": ['CCI-002165']\n tag \"nist\": ['AC-3 (4)', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Check DBMS settings and documentation to determine if users are\n able to assign and revoke rights to the objects and information they own. If\n users cannot assign or revoke rights to the objects and information they own to\n the granularity of a single user, this is a finding.\n\n (This is default Oracle behavior.)\"\n tag \"fix\": \"Modify DBMS settings to allow users to assign or revoke access\n rights to objects and information owned by the user. The ability to grant or\n revoke rights must include the ability to grant or revoke those rights down to\n the granularity of a single user.\n\n (This is default Oracle behavior.)\"\n describe 'A manual review is required to ensure a DBMS utilizing Discretionary Access Control (DAC) enforces a\n policy that includes or excludes access to the granularity of a single user' do\n skip 'A manual review is required to ensure a DBMS utilizing Discretionary Access Control (DAC) enforces a\n policy that includes or excludes access to the granularity of a single user'\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61587.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61619.rb", "line": 1 }, - "id": "V-61587" + "id": "V-61619" }, { - "title": "Oracle software must be evaluated and patched against newly found\n vulnerabilities.", - "desc": "Security faults with software applications and operating systems are\n discovered daily. Vendors are constantly updating and patching their products\n to address newly discovered security vulnerabilities. Organizations (including\n any contractor to the organization) are required to promptly install\n security-relevant software updates (e.g., patches, service packs, and hot\n fixes). Flaws discovered during security assessments, continuous monitoring,\n incident response activities, or information system error handling, must also\n be addressed expeditiously.\n\n Anytime new software code is introduced to a system there is the potential\n for unintended consequences. There have been documented instances where the\n application of a patch has caused problems with system integrity or\n availability. Due to information system integrity and availability concerns,\n organizations must give careful consideration to the methodology used to carry\n out automatic updates.\n\n Unsupported software versions are not patched by vendors to address newly\n discovered security versions. An unpatched version is vulnerable to attack.", + "title": "Use of the DBMS installation account must be logged.", + "desc": "The DBMS installation account may be used by any authorized user to\n perform DBMS installation or maintenance. Without logging, accountability for\n actions attributed to the account is lost.", "descriptions": { - "default": "Security faults with software applications and operating systems are\n discovered daily. Vendors are constantly updating and patching their products\n to address newly discovered security vulnerabilities. Organizations (including\n any contractor to the organization) are required to promptly install\n security-relevant software updates (e.g., patches, service packs, and hot\n fixes). Flaws discovered during security assessments, continuous monitoring,\n incident response activities, or information system error handling, must also\n be addressed expeditiously.\n\n Anytime new software code is introduced to a system there is the potential\n for unintended consequences. There have been documented instances where the\n application of a patch has caused problems with system integrity or\n availability. Due to information system integrity and availability concerns,\n organizations must give careful consideration to the methodology used to carry\n out automatic updates.\n\n Unsupported software versions are not patched by vendors to address newly\n discovered security versions. An unpatched version is vulnerable to attack." + "default": "The DBMS installation account may be used by any authorized user to\n perform DBMS installation or maintenance. Without logging, accountability for\n actions attributed to the account is lost." }, - "impact": 0.7, - "refs": [], + "impact": 0, + "refs": [ + { + "ref": [] + } + ], "tags": { - "gtitle": "SRG-APP-000133-DB-000205", - "gid": "V-61539", - "rid": "SV-76029r2_rule", - "stig_id": "O121-C1-011100", - "fix_id": "F-67455r4_fix", + "gtitle": "SRG-APP-000516-DB-999900", + "gid": "V-61489", + "rid": "SV-75979r1_rule", + "stig_id": "O121-BP-024200", + "fix_id": "F-67405r1_fix", "cci": [ - "CCI-001499" + "CCI-000366" ], "nist": [ - "CM-5 (6)", + "CM-6 b", "Rev_4" ], "false_negatives": null, @@ -474,35 +440,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "When the Quarterly CPU is released, check the CPU Notice and\n note the specific patch number for the system.\n\n Then, issue the following command:\n\n SELECT patch_id, version, action, status, description from\n dba_registry_sqlpatch;\n\n This will generate the patch levels for the home and any specific patches that\n have been applied to it.\n\n If the currently installed patch levels are lower than the latest, this is a\n finding.", - "fix": "Follow the process below to apply the security patch.\n\n Log on to My Oracle Support.\n\n Select patches and download the specific patch number and corresponding MD5\n checksum. Once the patch is downloaded to the server, check the MD5 checksum to\n make sure the patch is valid.\n\n To check the MD5 Checksum in Linux/UNIX, the command is:\n $md5sum absolute_path_of_file_name - file_name is the complete location of the\n downloaded file.\n $md5sum /home/oracle/test.zip\n a34d8cd98f00cf24e9800998ecf823e4 /home/oracle/test.zip\n\n Once the checksum is validated, apply the patch:\n $ cd $ORACLE_HOME\n $ opatch apply\n\n Check that the patch was applied and the inventory was updated with the\n following command (UNIX/Linux):\n $ opatch lsinventory -detail\n\n Windows:\n opatch lsinventory –detail" + "check": "Review documented and implemented procedures for monitoring the\n use of the DBMS software installation account in the System Security Plan.\n\n If use of this account is not monitored or procedures for monitoring its use do\n not exist or are incomplete, this is a finding.\n\n Note: On Windows systems, The Oracle DBMS software is installed using an\n account with administrator privileges. Ownership should be reassigned to a\n dedicated OS account used to operate the DBMS software. If monitoring does not\n include all accounts with administrator privileges on the DBMS host, this is a\n finding.", + "fix": "Develop, document and implement a logging procedure for use of\n the DBMS software installation account that provides accountability to\n individuals for any actions taken by the account.\n\n Host system audit logs should be included in the DBMS account usage log along\n with an indication of the person who accessed the account and an explanation\n for the access.\n\n Ensure all accounts with administrator privileges are monitored for DBMS host\n on Windows OS platforms." }, - "code": "control 'V-61539' do\n title \"Oracle software must be evaluated and patched against newly found\n vulnerabilities.\"\n desc \"Security faults with software applications and operating systems are\n discovered daily. Vendors are constantly updating and patching their products\n to address newly discovered security vulnerabilities. Organizations (including\n any contractor to the organization) are required to promptly install\n security-relevant software updates (e.g., patches, service packs, and hot\n fixes). Flaws discovered during security assessments, continuous monitoring,\n incident response activities, or information system error handling, must also\n be addressed expeditiously.\n\n Anytime new software code is introduced to a system there is the potential\n for unintended consequences. There have been documented instances where the\n application of a patch has caused problems with system integrity or\n availability. Due to information system integrity and availability concerns,\n organizations must give careful consideration to the methodology used to carry\n out automatic updates.\n\n Unsupported software versions are not patched by vendors to address newly\n discovered security versions. An unpatched version is vulnerable to attack.\n \"\n impact 0.7\n tag \"gtitle\": 'SRG-APP-000133-DB-000205'\n tag \"gid\": 'V-61539'\n tag \"rid\": 'SV-76029r2_rule'\n tag \"stig_id\": 'O121-C1-011100'\n tag \"fix_id\": 'F-67455r4_fix'\n tag \"cci\": ['CCI-001499']\n tag \"nist\": ['CM-5 (6)', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"When the Quarterly CPU is released, check the CPU Notice and\n note the specific patch number for the system.\n\n Then, issue the following command:\n\n SELECT patch_id, version, action, status, description from\n dba_registry_sqlpatch;\n\n This will generate the patch levels for the home and any specific patches that\n have been applied to it.\n\n If the currently installed patch levels are lower than the latest, this is a\n finding.\"\n tag \"fix\": \"Follow the process below to apply the security patch.\n\n Log on to My Oracle Support.\n\n Select patches and download the specific patch number and corresponding MD5\n checksum. Once the patch is downloaded to the server, check the MD5 checksum to\n make sure the patch is valid.\n\n To check the MD5 Checksum in Linux/UNIX, the command is:\n $md5sum absolute_path_of_file_name - file_name is the complete location of the\n downloaded file.\n $md5sum /home/oracle/test.zip\n a34d8cd98f00cf24e9800998ecf823e4 /home/oracle/test.zip\n\n Once the checksum is validated, apply the patch:\n $ cd $ORACLE_HOME\n $ opatch apply\n\n Check that the patch was applied and the inventory was updated with the\n following command (UNIX/Linux):\n $ opatch lsinventory -detail\n\n Windows:\n opatch lsinventory –detail\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n patches = sql.query('SELECT patch_id from dba_registry_sqlpatch;').column('patch_id')\n\n describe 'The oracle database installed patches' do\n subject { patches }\n it { should_not cmp nil }\n end\nend\n", + "code": " control 'V-61489' 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-61539.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61489.rb", "line": 1 }, - "id": "V-61539" + "id": "V-61489" }, { - "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.", + "title": "DBMS production application and data directories must be protected\n from developers on shared production/development DBMS host systems.", + "desc": "Developer roles must not be assigned DBMS administrative privileges to\n production DBMS application and data directories. The separation of production\n DBA and developer roles helps protect the production system from unauthorized,\n malicious or unintentional interruption due to development activities.", "descriptions": { - "default": "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." + "default": "Developer roles must not be assigned DBMS administrative privileges to\n production DBMS application and data directories. The separation of production\n DBA and developer roles helps protect the production system from unauthorized,\n malicious or unintentional interruption due to development activities." }, "impact": 0.5, "refs": [], "tags": { - "gtitle": "SRG-APP-000142-DB-000094", - "gid": "V-61687", - "rid": "SV-76177r1_rule", - "stig_id": "O121-C2-011900", - "fix_id": "F-67601r1_fix", + "gtitle": "SRG-APP-000516-DB-999900", + "gid": "V-61487", + "rid": "SV-75977r1_rule", + "stig_id": "O121-BP-024100", + "fix_id": "F-67403r1_fix", "cci": [ - "CCI-000382" + "CCI-000366" ], "nist": [ - "CM-7 b", + "CM-6 b", "Rev_4" ], "false_negatives": null, @@ -515,35 +481,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "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" + "check": "If the DBMS or DBMS host is not shared by production and\n development activities, this check is not a finding.\n\n Review OS DBA group membership.\n\n If any developer accounts, as identified in the System Security Plan, have been\n assigned DBA privileges, this is a finding.\n\n Note: Though shared production/non-production DBMS installations was allowed\n under previous database STIG guidance, doing so may place it in violation of\n OS, Application, Network or Enclave STIG guidance. Ensure that any shared\n production/non-production DBMS installation meets STIG guidance requirements at\n all levels or mitigate any conflicts in STIG guidance with the AO.", + "fix": "Create separate DBMS host OS groups for developer and production\n DBAs.\n\n Do not assign production DBA OS group membership to accounts used for\n development.\n\n Remove development accounts from production DBA OS group membership.\n\n Recommend establishing a dedicated DBMS host for production DBMS installations.\n A dedicated host system in this case refers to an instance of the operating\n system at a minimum. The operating system may reside on a virtual host machine\n where supported by the DBMS vendor." }, - "code": "control 'V-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", + "code": "control 'V-61487' do\n title \"DBMS production application and data directories must be protected\n from developers on shared production/development DBMS host systems.\"\n desc \"Developer roles must not be assigned DBMS administrative privileges to\n production DBMS application and data directories. The separation of production\n DBA and developer roles helps protect the production system from unauthorized,\n malicious or unintentional interruption due to development activities.\"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000516-DB-999900'\n tag \"gid\": 'V-61487'\n tag \"rid\": 'SV-75977r1_rule'\n tag \"stig_id\": 'O121-BP-024100'\n tag \"fix_id\": 'F-67403r1_fix'\n tag \"cci\": ['CCI-000366']\n tag \"nist\": ['CM-6 b', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"If the DBMS or DBMS host is not shared by production and\n development activities, this check is not a finding.\n\n Review OS DBA group membership.\n\n If any developer accounts, as identified in the System Security Plan, have been\n assigned DBA privileges, this is a finding.\n\n Note: Though shared production/non-production DBMS installations was allowed\n under previous database STIG guidance, doing so may place it in violation of\n OS, Application, Network or Enclave STIG guidance. Ensure that any shared\n production/non-production DBMS installation meets STIG guidance requirements at\n all levels or mitigate any conflicts in STIG guidance with the AO.\"\n tag \"fix\": \"Create separate DBMS host OS groups for developer and production\n DBAs.\n\n Do not assign production DBA OS group membership to accounts used for\n development.\n\n Remove development accounts from production DBA OS group membership.\n\n Recommend establishing a dedicated DBMS host for production DBMS installations.\n A dedicated host system in this case refers to an instance of the operating\n system at a minimum. The operating system may reside on a virtual host machine\n where supported by the DBMS vendor.\"\n describe 'A manual review is required to ensure DBMS production application and data directories are protected\n from developers on shared production/development DBMS host systems.' do\n skip 'A manual review is required to ensure DBMS production application and data directories are protected\n from developers on shared production/development DBMS host systems.'\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61687.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61487.rb", "line": 1 }, - "id": "V-61687" + "id": "V-61487" }, { - "title": "Database data files containing sensitive information must be\n encrypted.", - "desc": "Cryptography is only as strong as the encryption modules/algorithms\n employed to encrypt the data.\n\n Use of weak or untested encryption algorithms undermines the purposes of\n utilizing encryption to protect data.\n\n Data files that are not encrypted are vulnerable to theft. When data files\n are not encrypted they can be copied and opened on a separate system. The data\n can be compromised without the information owner's knowledge that the theft has\n even taken place.", + "title": "The DBMS must limit the number of concurrent sessions for each system\n account to an organization-defined number of sessions.", + "desc": "Application management includes the ability to control the number of\n users and user sessions utilizing an application. Limiting the number of\n allowed users, and sessions per user, is helpful in limiting risks related to\n Denial of Service attacks.\n\n This requirement addresses concurrent session control for a single\n information system account and does not address concurrent sessions by a single\n user via multiple system accounts.\n\n Unlimited concurrent connections to the DBMS could allow a successful\n Denial of Service (DoS) attack by exhausting connection resources.\n\n The organization will need to define the maximum number of concurrent\n sessions by account type, by account, or a combination thereof. In deciding on\n the appropriate number, it is important to take into account the work\n requirements of the various types of user. For example, 2 might be an\n acceptable limit for general users accessing the database via an application;\n but 10 might be too few for a database administrator using a database\n management GUI tool, where each query tab and navigation pane may count as a\n separate session.", "descriptions": { - "default": "Cryptography is only as strong as the encryption modules/algorithms\n employed to encrypt the data.\n\n Use of weak or untested encryption algorithms undermines the purposes of\n utilizing encryption to protect data.\n\n Data files that are not encrypted are vulnerable to theft. When data files\n are not encrypted they can be copied and opened on a separate system. The data\n can be compromised without the information owner's knowledge that the theft has\n even taken place." + "default": "Application management includes the ability to control the number of\n users and user sessions utilizing an application. Limiting the number of\n allowed users, and sessions per user, is helpful in limiting risks related to\n Denial of Service attacks.\n\n This requirement addresses concurrent session control for a single\n information system account and does not address concurrent sessions by a single\n user via multiple system accounts.\n\n Unlimited concurrent connections to the DBMS could allow a successful\n Denial of Service (DoS) attack by exhausting connection resources.\n\n The organization will need to define the maximum number of concurrent\n sessions by account type, by account, or a combination thereof. In deciding on\n the appropriate number, it is important to take into account the work\n requirements of the various types of user. For example, 2 might be an\n acceptable limit for general users accessing the database via an application;\n but 10 might be too few for a database administrator using a database\n management GUI tool, where each query tab and navigation pane may count as a\n separate session." }, "impact": 0.5, "refs": [], "tags": { - "gtitle": "SRG-APP-000196-DB-000141", - "gid": "V-61761", - "rid": "SV-76251r1_rule", - "stig_id": "O121-C2-016700", - "fix_id": "F-67677r1_fix", + "gtitle": "SRG-APP-000001-DB-000031", + "gid": "V-61967", + "rid": "SV-76457r2_rule", + "stig_id": "O121-C2-000100", + "fix_id": "F-67887r4_fix", "cci": [ - "CCI-002450" + "CCI-000054" ], "nist": [ - "SC-13", + "AC-10", "Rev_4" ], "false_negatives": null, @@ -556,35 +522,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "If the database does not handle sensitive information, this is\n not a finding.\n\n Review the system documentation to determine whether the database handles\n classified information. If the database handles classified information, upgrade\n the severity Category Code to I.\n\n Review the system documentation to discover sensitive or classified data\n identified by the Information Owner that requires encryption.\n\n If no sensitive or classified data is identified as requiring encryption by the\n Information Owner, this is not a finding.\n\n Have the DBA use select statements in the database to review sensitive data\n stored in tables as identified in the system documentation.\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\n SHOW PARAMETER DBFIPS_140\n\n or the following SQL query:\n\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 there are encrypted tablespaces, enter the following SQL*Plus command:\n\n SELECT * FROM V$ENCRYPTED_TABLESPACES;\n\n If no rows are returned, then there are no encrypted tablespaces.\n\n To see if there are encrypted columns within existing tables, enter the\n following SQL*Plus command:\n\n SELECT * FROM DBA_ENCRYPTED_COLUMNS;\n\n If no rows are returned, then there are no encrypted columns within existing\n tables.\n\n If all sensitive data identified is encrypted within the database objects,\n encryption of the DBMS data files is optional and not a finding.\n\n If all sensitive data is not encrypted within database objects, review\n encryption applied to the DBMS host data files. If no encryption is applied,\n this is a finding.", - "fix": "Obtain and utilize native or third-party NIST-validated FIPS\n 140-2-compliant cryptography solution for the DBMS. Configure cryptographic\n functions to use FIPS 140-2-compliant algorithms and hashing functions.\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).\n\n There is more information on this topic in the Oracle Database 12c Advanced\n Security Administrator's Guide, which may be found at\n https://docs.oracle.com/database/121/ASOAG/toc.htm. (Note, however, that\n because of changes in Oracle's licensing policy, it is no longer necessary to\n purchase Oracle Advanced Security to use network encryption and advanced\n authentication.)\n\n FIPS 140-2 documentation can be downloaded from\n http://csrc.nist.gov/publications/PubsFIPS.html#140-2" + "check": "Retrieve the settings for concurrent sessions for each profile\n with the query:\n SELECT * FROM SYS.DBA_PROFILES WHERE RESOURCE_NAME = 'SESSIONS_PER_USER';\n\n If the DBMS settings for concurrent sessions for each profile are greater than\n the site-specific maximum number of sessions, this is a finding.", + "fix": "Limit concurrent connections for each system account to a number\n less than or equal to the organization-defined number of sessions using the\n following SQL. Create profiles that conform to the requirements. Assign users\n to the appropriate profile.\n\n The user profile, ORA_STIG_PROFILE, has been provided (starting with Oracle\n 12.1.0.2) to satisfy the STIG requirements pertaining to the profile\n parameters. Oracle recommends that this profile be customized with any\n site-specific requirements and assigned to all users where applicable. Note:\n It remains necessary to create a customized replacement for the password\n validation function, ORA12C_STRONG_VERIFY_FUNCTION, if relying on this\n technique to verify password complexity.\n\n The defaults for ORA_STIG_PROFILE are set as follows:\n Resource Name Limit\n ------------- ------\n COMPOSITE_LIMIT DEFAULT\n SESSIONS_PER_USER DEFAULT\n CPU_PER_SESSION DEFAULT\n CPU_PER_CALL DEFAULT\n LOGICAL_READS_PER_SESSION DEFAULT\n LOGICAL_READS_PER_CALL DEFAULT\n IDLE_TIME 15\n CONNECT_TIME DEFAULT\n PRIVATE_SGA DEFAULT\n FAILED_LOGIN_ATTEMPTS 3\n PASSWORD_LIFE_TIME 60\n PASSWORD_REUSE_TIME 365\n PASSWORD_REUSE_MAX 10\n PASSWORD_VERIFY_FUNCTION ORA12C_STRONG_VERIFY_FUNCTION\n PASSWORD_LOCK_TIME UNLIMITED\n PASSWORD_GRACE_TIME 5\n\n Change the value of SESSIONS_PER_USER (along with the other parameters, where\n relevant) from UNLIMITED to DoD-compliant, site-specific requirements and then\n assign users to the profile.\n ALTER PROFILE ORA_STIG_PROFILE LIMIT SESSIONS_PER_USER ;\n\n To assign the user to the profile do the following:\n ALTER USER PROFILE ORA_STIG_PROFILE;" }, - "code": "control 'V-61761' do\n title \"Database data files containing sensitive information must be\n encrypted.\"\n desc \"Cryptography is only as strong as the encryption modules/algorithms\n employed to encrypt the data.\n\n Use of weak or untested encryption algorithms undermines the purposes of\n utilizing encryption to protect data.\n\n Data files that are not encrypted are vulnerable to theft. When data files\n are not encrypted they can be copied and opened on a separate system. The data\n can be compromised without the information owner's knowledge that the theft has\n even taken place.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000196-DB-000141'\n tag \"gid\": 'V-61761'\n tag \"rid\": 'SV-76251r1_rule'\n tag \"stig_id\": 'O121-C2-016700'\n tag \"fix_id\": 'F-67677r1_fix'\n tag \"cci\": ['CCI-002450']\n tag \"nist\": ['SC-13', '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 database does not handle sensitive information, this is\n not a finding.\n\n Review the system documentation to determine whether the database handles\n classified information. If the database handles classified information, upgrade\n the severity Category Code to I.\n\n Review the system documentation to discover sensitive or classified data\n identified by the Information Owner that requires encryption.\n\n If no sensitive or classified data is identified as requiring encryption by the\n Information Owner, this is not a finding.\n\n Have the DBA use select statements in the database to review sensitive data\n stored in tables as identified in the system documentation.\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\n SHOW PARAMETER DBFIPS_140\n\n or the following SQL query:\n\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 there are encrypted tablespaces, enter the following SQL*Plus command:\n\n SELECT * FROM V$ENCRYPTED_TABLESPACES;\n\n If no rows are returned, then there are no encrypted tablespaces.\n\n To see if there are encrypted columns within existing tables, enter the\n following SQL*Plus command:\n\n SELECT * FROM DBA_ENCRYPTED_COLUMNS;\n\n If no rows are returned, then there are no encrypted columns within existing\n tables.\n\n If all sensitive data identified is encrypted within the database objects,\n encryption of the DBMS data files is optional and not a finding.\n\n If all sensitive data is not encrypted within database objects, review\n encryption applied to the DBMS host data files. If no encryption is applied,\n this is a finding.\"\n tag \"fix\": \"Obtain and utilize native or third-party NIST-validated FIPS\n 140-2-compliant cryptography solution for the DBMS. Configure cryptographic\n functions to use FIPS 140-2-compliant algorithms and hashing functions.\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).\n\n There is more information on this topic in the Oracle Database 12c Advanced\n Security Administrator's Guide, which may be found at\n https://docs.oracle.com/database/121/ASOAG/toc.htm. (Note, however, that\n because of changes in Oracle's licensing policy, it is no longer necessary to\n purchase Oracle Advanced Security to use network encryption and advanced\n authentication.)\n\n FIPS 140-2 documentation can be downloaded from\n http://csrc.nist.gov/publications/PubsFIPS.html#140-2\"\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 * from v$parameter where name = 'DBFIPS_140c';\").column('value')\n\n describe 'The oracle database DBFIPS_140c parameter' do\n subject { parameter }\n it { should_not be_empty }\n end\n\n encrypted_tablespaces = sql.query('SELECT * FROM V$ENCRYPTED_TABLESPACES;').column('MASTERKEYID')\n\n describe 'The oracle tablespaces that are encrypted' do\n subject { encrypted_tablespaces }\n it { should_not be_empty }\n end\n\n encrypted_colums = sql.query('SELECT * FROM DBA_ENCRYPTED_COLUMNS;').column('COLUMN_NAME')\n\n describe 'The oracle table columns that are encrypted' do\n subject { encrypted_colums }\n it { should_not be_empty }\n end\nend\n", + "code": "control 'V-61967' do\n title \"The DBMS must limit the number of concurrent sessions for each system\n account to an organization-defined number of sessions.\"\n desc \"Application management includes the ability to control the number of\n users and user sessions utilizing an application. Limiting the number of\n allowed users, and sessions per user, is helpful in limiting risks related to\n Denial of Service attacks.\n\n This requirement addresses concurrent session control for a single\n information system account and does not address concurrent sessions by a single\n user via multiple system accounts.\n\n Unlimited concurrent connections to the DBMS could allow a successful\n Denial of Service (DoS) attack by exhausting connection resources.\n\n The organization will need to define the maximum number of concurrent\n sessions by account type, by account, or a combination thereof. In deciding on\n the appropriate number, it is important to take into account the work\n requirements of the various types of user. For example, 2 might be an\n acceptable limit for general users accessing the database via an application;\n but 10 might be too few for a database administrator using a database\n management GUI tool, where each query tab and navigation pane may count as a\n separate session.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000001-DB-000031'\n tag \"gid\": 'V-61967'\n tag \"rid\": 'SV-76457r2_rule'\n tag \"stig_id\": 'O121-C2-000100'\n tag \"fix_id\": 'F-67887r4_fix'\n tag \"cci\": ['CCI-000054']\n tag \"nist\": ['AC-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\": \"Retrieve the settings for concurrent sessions for each profile\n with the query:\n SELECT * FROM SYS.DBA_PROFILES WHERE RESOURCE_NAME = 'SESSIONS_PER_USER';\n\n If the DBMS settings for concurrent sessions for each profile are greater than\n the site-specific maximum number of sessions, this is a finding.\"\n tag \"fix\": \"Limit concurrent connections for each system account to a number\n less than or equal to the organization-defined number of sessions using the\n following SQL. Create profiles that conform to the requirements. Assign users\n to the appropriate profile.\n\n The user profile, ORA_STIG_PROFILE, has been provided (starting with Oracle\n 12.1.0.2) to satisfy the STIG requirements pertaining to the profile\n parameters. Oracle recommends that this profile be customized with any\n site-specific requirements and assigned to all users where applicable. Note:\n It remains necessary to create a customized replacement for the password\n validation function, ORA12C_STRONG_VERIFY_FUNCTION, if relying on this\n technique to verify password complexity.\n\n The defaults for ORA_STIG_PROFILE are set as follows:\n Resource Name Limit\n ------------- ------\n COMPOSITE_LIMIT DEFAULT\n SESSIONS_PER_USER DEFAULT\n CPU_PER_SESSION DEFAULT\n CPU_PER_CALL DEFAULT\n LOGICAL_READS_PER_SESSION DEFAULT\n LOGICAL_READS_PER_CALL DEFAULT\n IDLE_TIME 15\n CONNECT_TIME DEFAULT\n PRIVATE_SGA DEFAULT\n FAILED_LOGIN_ATTEMPTS 3\n PASSWORD_LIFE_TIME 60\n PASSWORD_REUSE_TIME 365\n PASSWORD_REUSE_MAX 10\n PASSWORD_VERIFY_FUNCTION ORA12C_STRONG_VERIFY_FUNCTION\n PASSWORD_LOCK_TIME UNLIMITED\n PASSWORD_GRACE_TIME 5\n\n Change the value of SESSIONS_PER_USER (along with the other parameters, where\n relevant) from UNLIMITED to DoD-compliant, site-specific requirements and then\n assign users to the profile.\n ALTER PROFILE ORA_STIG_PROFILE LIMIT SESSIONS_PER_USER ;\n\n To assign the user to the profile do the following:\n ALTER USER PROFILE ORA_STIG_PROFILE;\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n concurrent_sessions = sql.query(\"SELECT limit FROM SYS.DBA_PROFILES WHERE RESOURCE_NAME = 'SESSIONS_PER_USER';\").column('limit')\n\n describe 'The oracle database number of concurrent sessions allowed' do\n subject { concurrent_sessions }\n it { should_not include 'UNLIMITED' }\n it { should_not include 'DEFAULT' }\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61761.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61967.rb", "line": 1 }, - "id": "V-61761" + "id": "V-61967" }, { - "title": "Applications must obscure feedback of authentication information\n during the authentication process to protect the information from possible\n exploitation/use by unauthorized individuals.", - "desc": "To prevent the compromise of authentication information, such as\n passwords, during the authentication process, the feedback from the information\n system shall not provide any information that would allow an unauthorized user\n to compromise the authentication mechanism.\n\n Obfuscation of user-provided information when typed into the system is a\n method used in addressing this risk.\n\n For example, displaying asterisks when a user types in a password, is an\n example of obscuring feedback of authentication information.\n\n Database applications may allow for entry of the account name and password\n as a visible parameter of the application execution command. This practice\n should be prohibited and disabled to prevent shoulder surfing.\n\n This calls for inspection of application source code, which will require\n collaboration with the application developers. It is recognized that in many\n cases, the database administrator (DBA) is organizationally separate from the\n application developers and may have limited, if any, access to source code.\n Nevertheless, protections of this type are so important to the secure operation\n of databases that they must not be ignored. At a minimum, the DBA must attempt\n to obtain assurances from the development organization that this issue has been\n addressed and must document what has been discovered.", + "title": "The DBMS must produce audit records containing sufficient information\n to establish what type of events occurred.", + "desc": "Information system auditing capability is critical for accurate\n forensic analysis. Audit record content that may be necessary to satisfy the\n requirement of this control includes: timestamps, source and destination\n addresses, user/process identifiers, event descriptions, success/fail\n indications, file names involved, and access control or flow control rules\n invoked.\n\n Database software is capable of a range of actions on data stored within\n the database. It is important, for accurate forensic analysis, to know exactly\n what actions were performed. This requires specific information regarding the\n event type an audit record is referring to. If event type information is not\n recorded and stored with the audit record, the record itself is of very limited\n use.", "descriptions": { - "default": "To prevent the compromise of authentication information, such as\n passwords, during the authentication process, the feedback from the information\n system shall not provide any information that would allow an unauthorized user\n to compromise the authentication mechanism.\n\n Obfuscation of user-provided information when typed into the system is a\n method used in addressing this risk.\n\n For example, displaying asterisks when a user types in a password, is an\n example of obscuring feedback of authentication information.\n\n Database applications may allow for entry of the account name and password\n as a visible parameter of the application execution command. This practice\n should be prohibited and disabled to prevent shoulder surfing.\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": "Information system auditing capability is critical for accurate\n forensic analysis. Audit record content that may be necessary to satisfy the\n requirement of this control includes: timestamps, source and destination\n addresses, user/process identifiers, event descriptions, success/fail\n indications, file names involved, and access control or flow control rules\n invoked.\n\n Database software is capable of a range of actions on data stored within\n the database. It is important, for accurate forensic analysis, to know exactly\n what actions were performed. This requires specific information regarding the\n event type an audit record is referring to. If event type information is not\n recorded and stored with the audit record, the record itself is of very limited\n use." }, - "impact": 0.7, + "impact": 0.5, "refs": [], "tags": { - "gtitle": "SRG-APP-000178-DB-000083", - "gid": "V-61843", - "rid": "SV-76333r2_rule", - "stig_id": "O121-N1-015601", - "fix_id": "F-67759r1_fix", + "gtitle": "SRG-APP-000095-DB-000039", + "gid": "V-61627", + "rid": "SV-76117r1_rule", + "stig_id": "O121-C2-007400", + "fix_id": "F-67543r1_fix", "cci": [ - "CCI-000366" + "CCI-000130" ], "nist": [ - "CM-6 b", + "AU-3", "Rev_4" ], "false_negatives": null, @@ -597,35 +563,39 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Interview the DBA to determine if any applications that access\n the database allow for entry of the account name and password on the command\n line. If any do, determine whether these applications obfuscate authentication\n data. If they do not, this is a finding.", - "fix": "Configure or modify applications to prohibit display of passwords\n in clear text on the command line." + "check": "Verify, using vendor and system documentation if necessary,\n that the DBMS is configured to use Oracle's auditing features, or that a\n third-party product or custom code is deployed and configured to satisfy this\n requirement.\n\n If a third-party product or custom code is used, compare its current\n configuration with the audit requirements. If any of the requirements is not\n covered by the configuration, this is a finding.\n\n The remainder of this Check is applicable specifically where Oracle auditing is\n in use.\n\n If Standard Auditing is used:\n To see if Oracle is configured to capture audit data, enter the following\n SQL*Plus command:\n\n SHOW PARAMETER AUDIT_TRAIL\n\n or the following SQL query:\n\n SELECT * FROM SYS.V$PARAMETER WHERE NAME = 'audit_trail';\n\n If Oracle returns the value \"NONE\", this is a finding.\n\n To confirm that Oracle audit is capturing sufficient information to establish\n the identity of the user/subject or process, perform a successful auditable\n action and an auditable action that results in an SQL error, and then view the\n results in the SYS.AUD$ table or the audit file, whichever is in use.\n\n If no ACTION#, or the wrong value, is returned for the auditable actions just\n performed, this is a finding.\n\n If Unified Auditing is used:\n To see if Oracle is configured to capture audit data, enter the following\n SQL*Plus command:\n\n SELECT * FROM V$OPTION WHERE PARAMETER = 'Unified Auditing';\n\n If Oracle returns the value \"TRUE\", this is not a finding.\n\n To confirm that Oracle audit is capturing sufficient information to establish\n the identity of the user/subject or process, perform a successful auditable\n action and an auditable action that results in an SQL error, and then view the\n results in the SYS.UNIFIED_AUDIT_TRAIL view.\n\n If no ACTION#, or the wrong value, is returned for the auditable actions just\n performed, this is a finding.", + "fix": "Configure the DBMS's auditing to audit standard and\n organization-defined auditable events, the audit record to include what type of\n event occurred. If preferred, use a third-party or custom tool.\n\n If using a third-party product, proceed in accordance with the product\n documentation. If using Oracle's capabilities, proceed as follows.\n\n If Standard Auditing is used:\n Use this process to ensure auditable events are captured:\n\n ALTER SYSTEM SET AUDIT_TRAIL= SCOPE=SPFILE;\n\n Audit trail type can be 'OS', 'DB', 'DB,EXTENDED', 'XML' or '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.\n\n\n\n Oracle 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" }, - "code": "control 'V-61843' do\n title \"Applications must obscure feedback of authentication information\n during the authentication process to protect the information from possible\n exploitation/use by unauthorized individuals.\"\n desc \"To prevent the compromise of authentication information, such as\n passwords, during the authentication process, the feedback from the information\n system shall not provide any information that would allow an unauthorized user\n to compromise the authentication mechanism.\n\n Obfuscation of user-provided information when typed into the system is a\n method used in addressing this risk.\n\n For example, displaying asterisks when a user types in a password, is an\n example of obscuring feedback of authentication information.\n\n Database applications may allow for entry of the account name and password\n as a visible parameter of the application execution command. This practice\n should be prohibited and disabled to prevent shoulder surfing.\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.7\n tag \"gtitle\": 'SRG-APP-000178-DB-000083'\n tag \"gid\": 'V-61843'\n tag \"rid\": 'SV-76333r2_rule'\n tag \"stig_id\": 'O121-N1-015601'\n tag \"fix_id\": 'F-67759r1_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\": \"Interview the DBA to determine if any applications that access\n the database allow for entry of the account name and password on the command\n line. If any do, determine whether these applications obfuscate authentication\n data. If they do not, this is a finding.\"\n tag \"fix\": \"Configure or modify applications to prohibit display of passwords\n in clear text on the command line.\"\n describe 'A manual review is required to ensure the applications obscures feedback of authentication information\n during the authentication process to protect the information from possible\n exploitation/use by unauthorized individuals' do\n skip 'A manual review is required to ensure the applications obscures feedback of authentication information\n during the authentication process to protect the information from possible\n exploitation/use by unauthorized individuals'\n end\nend\n", + "code": "control 'V-61627' do\n title \"The DBMS must produce audit records containing sufficient information\n to establish what type of events occurred.\"\n desc \"Information system auditing capability is critical for accurate\n forensic analysis. Audit record content that may be necessary to satisfy the\n requirement of this control includes: timestamps, source and destination\n addresses, user/process identifiers, event descriptions, success/fail\n indications, file names involved, and access control or flow control rules\n invoked.\n\n Database software is capable of a range of actions on data stored within\n the database. It is important, for accurate forensic analysis, to know exactly\n what actions were performed. This requires specific information regarding the\n event type an audit record is referring to. If event type information is not\n recorded and stored with the audit record, the record itself is of very limited\n use.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000095-DB-000039'\n tag \"gid\": 'V-61627'\n tag \"rid\": 'SV-76117r1_rule'\n tag \"stig_id\": 'O121-C2-007400'\n tag \"fix_id\": 'F-67543r1_fix'\n tag \"cci\": ['CCI-000130']\n tag \"nist\": ['AU-3', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Verify, using vendor and system documentation if necessary,\n that the DBMS is configured to use Oracle's auditing features, or that a\n third-party product or custom code is deployed and configured to satisfy this\n requirement.\n\n If a third-party product or custom code is used, compare its current\n configuration with the audit requirements. If any of the requirements is not\n covered by the configuration, this is a finding.\n\n The remainder of this Check is applicable specifically where Oracle auditing is\n in use.\n\n If Standard Auditing is used:\n To see if Oracle is configured to capture audit data, enter the following\n SQL*Plus command:\n\n SHOW PARAMETER AUDIT_TRAIL\n\n or the following SQL query:\n\n SELECT * FROM SYS.V$PARAMETER WHERE NAME = 'audit_trail';\n\n If Oracle returns the value \\\"NONE\\\", this is a finding.\n\n To confirm that Oracle audit is capturing sufficient information to establish\n the identity of the user/subject or process, perform a successful auditable\n action and an auditable action that results in an SQL error, and then view the\n results in the SYS.AUD$ table or the audit file, whichever is in use.\n\n If no ACTION#, or the wrong value, is returned for the auditable actions just\n performed, this is a finding.\n\n If Unified Auditing is used:\n To see if Oracle is configured to capture audit data, enter the following\n SQL*Plus command:\n\n SELECT * FROM V$OPTION WHERE PARAMETER = 'Unified Auditing';\n\n If Oracle returns the value \\\"TRUE\\\", this is not a finding.\n\n To confirm that Oracle audit is capturing sufficient information to establish\n the identity of the user/subject or process, perform a successful auditable\n action and an auditable action that results in an SQL error, and then view the\n results in the SYS.UNIFIED_AUDIT_TRAIL view.\n\n If no ACTION#, or the wrong value, is returned for the auditable actions just\n performed, this is a finding.\"\n tag \"fix\": \"Configure the DBMS's auditing to audit standard and\n organization-defined auditable events, the audit record to include what type of\n event occurred. If preferred, use a third-party or custom tool.\n\n If using a third-party product, proceed in accordance with the product\n documentation. If using Oracle's capabilities, proceed as follows.\n\n If Standard Auditing is used:\n Use this process to ensure auditable events are captured:\n\n ALTER SYSTEM SET AUDIT_TRAIL= SCOPE=SPFILE;\n\n Audit trail type can be 'OS', 'DB', 'DB,EXTENDED', 'XML' or '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.\n\n\n\n Oracle 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 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", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61843.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61627.rb", "line": 1 }, - "id": "V-61843" + "id": "V-61627" }, { - "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 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": "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": "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-000120-DB-000061", - "gid": "V-61657", - "rid": "SV-76147r1_rule", - "stig_id": "O121-C2-009500", - "fix_id": "F-67571r2_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-000164" + "CCI-001094" ], "nist": [ - "AU-9", + "SC-5 (1)", "Rev_4" ], "false_negatives": null, @@ -638,15 +608,15 @@ "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 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-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-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-61657.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61815.rb", "line": 1 }, - "id": "V-61657" + "id": "V-61815" }, { "title": "Database backup procedures must be defined, documented, and\n implemented.", @@ -690,24 +660,24 @@ "id": "V-61695" }, { - "title": "The DBMS must uniquely identify and authenticate non-organizational\n users (or processes acting on behalf of non-organizational users).", - "desc": "Non-organizational users include all information system users other\n than organizational users which include organizational employees or individuals\n the organization deems to have equivalent status of employees (e.g.,\n contractors, guest researchers, individuals from allied nations).\n\n Non-organizational users shall be uniquely identified and authenticated for\n all accesses other than those accesses explicitly identified and documented by\n the organization when related to the use of anonymous access, such as accessing\n a web server.\n\n Accordingly, a risk assessment is used in determining the authentication\n needs of the organization.\n\n Scalability, practicality, and security are simultaneously considered in\n balancing the need to ensure ease of use for access to federal information and\n information systems with the need to protect and adequately mitigate risk to\n organizational operations, organizational assets, individuals, other\n organizations, and the Nation.", + "title": "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.", "descriptions": { - "default": "Non-organizational users include all information system users other\n than organizational users which include organizational employees or individuals\n the organization deems to have equivalent status of employees (e.g.,\n contractors, guest researchers, individuals from allied nations).\n\n Non-organizational users shall be uniquely identified and authenticated for\n all accesses other than those accesses explicitly identified and documented by\n the organization when related to the use of anonymous access, such as accessing\n a web server.\n\n Accordingly, a risk assessment is used in determining the authentication\n needs of the organization.\n\n Scalability, practicality, and security are simultaneously considered in\n balancing the need to ensure ease of use for access to federal information and\n information systems with the need to protect and adequately mitigate risk to\n organizational operations, organizational assets, individuals, other\n organizations, and the Nation." + "default": "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." }, "impact": 0.5, "refs": [], "tags": { - "gtitle": "SRG-APP-000180-DB-000115", - "gid": "V-61881", - "rid": "SV-76371r1_rule", - "stig_id": "O121-P2-015800", - "fix_id": "F-67797r1_fix", + "gtitle": "SRG-APP-000516-DB-999900", + "gid": "V-61963", + "rid": "SV-76453r1_rule", + "stig_id": "O121-BP-025100", + "fix_id": "F-67883r1_fix", "cci": [ - "CCI-000804" + "CCI-000366" ], "nist": [ - "IA-8", + "CM-6 b", "Rev_4" ], "false_negatives": null, @@ -720,30 +690,30 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Review DBMS settings to determine whether non-organizational\n users are uniquely identified and authenticated when logging onto the system.\n\n If non-organizational users are not uniquely identified and authenticated, this\n is a finding.", - "fix": "Configure DBMS settings to uniquely identify and authenticate all\n non-organizational users who log onto the system." + "check": "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." }, - "code": "control 'V-61881' do\n title \"The DBMS must uniquely identify and authenticate non-organizational\n users (or processes acting on behalf of non-organizational users).\"\n desc \"Non-organizational users include all information system users other\n than organizational users which include organizational employees or individuals\n the organization deems to have equivalent status of employees (e.g.,\n contractors, guest researchers, individuals from allied nations).\n\n Non-organizational users shall be uniquely identified and authenticated for\n all accesses other than those accesses explicitly identified and documented by\n the organization when related to the use of anonymous access, such as accessing\n a web server.\n\n Accordingly, a risk assessment is used in determining the authentication\n needs of the organization.\n\n Scalability, practicality, and security are simultaneously considered in\n balancing the need to ensure ease of use for access to federal information and\n information systems with the need to protect and adequately mitigate risk to\n organizational operations, organizational assets, individuals, other\n organizations, and the Nation.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000180-DB-000115'\n tag \"gid\": 'V-61881'\n tag \"rid\": 'SV-76371r1_rule'\n tag \"stig_id\": 'O121-P2-015800'\n tag \"fix_id\": 'F-67797r1_fix'\n tag \"cci\": ['CCI-000804']\n tag \"nist\": ['IA-8', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Review DBMS settings to determine whether non-organizational\n users are uniquely identified and authenticated when logging onto the system.\n\n If non-organizational users are not uniquely identified and authenticated, this\n is a finding.\"\n tag \"fix\": \"Configure DBMS settings to uniquely identify and authenticate all\n non-organizational users who log onto the system.\"\n describe 'A manual review is required to ensure the DBMS uniquely identifies and authenticates non-organizational\n users (or processes acting on behalf of non-organizational users).' do\n skip 'A manual review is required to ensure the DBMS uniquely identifies and authenticates non-organizational\n users (or processes acting on behalf of non-organizational users).'\n end\nend\n", + "code": "control 'V-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", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61881.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61963.rb", "line": 1 }, - "id": "V-61881" + "id": "V-61963" }, { - "title": "Oracle application administration roles must be disabled if not\n required and authorized.", - "desc": "Application administration roles, which are assigned system or\n elevated application object privileges, must be protected from default\n activation. Application administration roles are determined by system privilege\n assignment (create / alter / drop user) and application user role ADMIN OPTION\n privileges.", + "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": "Application administration roles, which are assigned system or\n elevated application object privileges, must be protected from default\n activation. Application administration roles are determined by system privilege\n assignment (create / alter / drop user) and application user role ADMIN OPTION\n privileges." + "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, + "impact": 0.5, "refs": [], "tags": { "gtitle": "SRG-APP-000516-DB-999900", - "gid": "V-61445", - "rid": "SV-75935r2_rule", - "stig_id": "O121-BP-022900", - "fix_id": "F-67361r1_fix", + "gid": "V-61527", + "rid": "SV-76017r4_rule", + "stig_id": "O121-BP-026200", + "fix_id": "F-67443r2_fix", "cci": [ "CCI-000366" ], @@ -761,39 +731,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Run the SQL query:\n\n select grantee, granted_role from dba_role_privs\n where default_role='YES'\n and granted_role in\n (select grantee from dba_sys_privs where upper(privilege) like '%USER%')\n and grantee not in\n ()\n and grantee not in (select distinct owner from dba_tables)\n and grantee not in\n (select distinct username from dba_users where upper(account_status) like\n '%LOCKED%');\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 list of accounts reported for this check and ensures that they are\n authorized application administration roles.\n\n If any are not authorized application administration roles, this is a finding.", - "fix": "For each role assignment returned, issue:\n\n From SQL*Plus:\n\n alter user [username] default role all except [role];\n\n If the user has more than one application administration role assigned, then\n remove assigned roles from default assignment and assign individually the\n appropriate default roles." + "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-61445' do\n title \"Oracle application administration roles must be disabled if not\n required and authorized.\"\n desc \"Application administration roles, which are assigned system or\n elevated application object privileges, must be protected from default\n activation. Application administration roles are determined by system privilege\n assignment (create / alter / drop user) and application user role ADMIN OPTION\n privileges.\"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000516-DB-999900'\n tag \"gid\": 'V-61445'\n tag \"rid\": 'SV-75935r2_rule'\n tag \"stig_id\": 'O121-BP-022900'\n tag \"fix_id\": 'F-67361r1_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\": \"Run the SQL query:\n\n select grantee, granted_role from dba_role_privs\n where default_role='YES'\n and granted_role in\n (select grantee from dba_sys_privs where upper(privilege) like '%USER%')\n and grantee not in\n ()\n and grantee not in (select distinct owner from dba_tables)\n and grantee not in\n (select distinct username from dba_users where upper(account_status) like\n '%LOCKED%');\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 list of accounts reported for this check and ensures that they are\n authorized application administration roles.\n\n If any are not authorized application administration roles, this is a finding.\"\n tag \"fix\": \"For each role assignment returned, issue:\n\n From SQL*Plus:\n\n alter user [username] default role all except [role];\n\n If the user has more than one application administration role assigned, then\n remove assigned roles from default assignment and assign individually the\n appropriate default 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 users_with_dba_role = sql.query(\"select grantee from dba_role_privs\n where default_role='YES'\n and granted_role in\n (select grantee from dba_sys_privs where upper(privilege) like '%USER%')\n and grantee not in (select distinct owner from dba_tables)\n and grantee not in\n (select distinct username from dba_users where upper(account_status) like\n '%LOCKED%');\").column('grantee').uniq\n if users_with_dba_role.empty?\n impact 0.0\n describe 'There are no oracle users with the dba role, therefore control N/A' do\n skip 'There are no oracle users with the dba role, therefore control N/A'\n end\n else\n users_with_dba_role.each do |user|\n describe \"oracle users with admin option: #{user}\" do\n subject { user }\n it { should be_in input('allowed_users_dba_role') }\n end\n end\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-61445.rb", - "line": 3 + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61527.rb", + "line": 1 }, - "id": "V-61445" + "id": "V-61527" }, { - "title": "The DBMS must support organizational requirements to enforce the\n number of characters that get changed when passwords are changed.", - "desc": "Passwords need to be changed at specific policy-based intervals.\n\n If the information system or application allows the user to consecutively\n reuse extensive portions of their password when they change their password, the\n end result is a password that has not had enough elements changed to meet the\n policy requirements.\n\n Changing passwords frequently can thwart password-guessing attempts or\n re-establish protection of a compromised DBMS account. Minor changes to\n passwords may not accomplish this since password guessing may be able to\n continue to build on previous guesses, or the new password may be easily\n guessed using the old password.\n\n Note that user authentication and account management must be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP This requirement applies to cases where it is necessary to\n have accounts directly managed by Oracle.", + "title": "The 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.", "descriptions": { - "default": "Passwords need to be changed at specific policy-based intervals.\n\n If the information system or application allows the user to consecutively\n reuse extensive portions of their password when they change their password, the\n end result is a password that has not had enough elements changed to meet the\n policy requirements.\n\n Changing passwords frequently can thwart password-guessing attempts or\n re-establish protection of a compromised DBMS account. Minor changes to\n passwords may not accomplish this since password guessing may be able to\n continue to build on previous guesses, or the new password may be easily\n guessed using the old password.\n\n Note that user authentication and account management must be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP This requirement applies to cases where it is necessary to\n have accounts directly managed by Oracle." + "default": "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." }, - "impact": 0.5, - "refs": [ - { - "ref": [] - } - ], + "impact": 0, + "refs": [], "tags": { - "gtitle": "SRG-APP-000170-DB-000073", - "gid": "V-61731", - "rid": "SV-76221r1_rule", - "stig_id": "O121-C2-014500", - "fix_id": "F-67647r1_fix", + "gtitle": "SRG-APP-000120-DB-000061", + "gid": "V-61657", + "rid": "SV-76147r1_rule", + "stig_id": "O121-C2-009500", + "fix_id": "F-67571r2_fix", "cci": [ - "CCI-000195" + "CCI-000164" ], "nist": [ - "IA-5 (1) (b)", + "AU-9", "Rev_4" ], "false_negatives": null, @@ -806,35 +772,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "If all user accounts are managed and authenticated by the OS or\n an enterprise-level authentication/access mechanism, and not by Oracle, this is\n not a finding.\n\n For each profile that can be applied to accounts where authentication is under\n Oracle's control, determine the password verification function, if any, that is\n in use:\n\n SELECT * FROM SYS.DBA_PROFILES\n WHERE RESOURCE_NAME = 'PASSWORD_VERIFY_FUNCTION'\n [AND PROFILE NOT IN ()] 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 organization-defined minimum number of characters by\n which the password must differ from the previous password (eight of the\n characters unless otherwise specified), this is a finding.", - "fix": "If any user accounts are managed by Oracle: Develop, test and\n implement a password verification function that enforces DoD requirements.\n\n (Oracle supplies a sample function called ORA12C_STRONG_VERIFY_FUNCTION, in the\n script file /RDBMS/ADMIN/utlpwdmg.sql. This can be used as the\n starting point for a customized function.)" + "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." }, - "code": "control 'V-61731' do\n title \"The DBMS must support organizational requirements to enforce the\n number of characters that get changed when passwords are changed.\"\n desc \"Passwords need to be changed at specific policy-based intervals.\n\n If the information system or application allows the user to consecutively\n reuse extensive portions of their password when they change their password, the\n end result is a password that has not had enough elements changed to meet the\n policy requirements.\n\n Changing passwords frequently can thwart password-guessing attempts or\n re-establish protection of a compromised DBMS account. Minor changes to\n passwords may not accomplish this since password guessing may be able to\n continue to build on previous guesses, or the new password may be easily\n guessed using the old password.\n\n Note that user authentication and account management must be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP This requirement applies to cases where it is necessary to\n have accounts directly managed by Oracle.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000170-DB-000073'\n tag \"gid\": 'V-61731'\n tag \"rid\": 'SV-76221r1_rule'\n tag \"stig_id\": 'O121-C2-014500'\n tag \"fix_id\": 'F-67647r1_fix'\n tag \"cci\": ['CCI-000195']\n tag \"nist\": ['IA-5 (1) (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 all user accounts are managed and authenticated by the OS or\n an enterprise-level authentication/access mechanism, and not by Oracle, this is\n not a finding.\n\n For each profile that can be applied to accounts where authentication is under\n Oracle's control, determine the password verification function, if any, that is\n in use:\n\n SELECT * FROM SYS.DBA_PROFILES\n WHERE RESOURCE_NAME = 'PASSWORD_VERIFY_FUNCTION'\n [AND PROFILE NOT IN ()] 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 organization-defined minimum number of characters by\n which the password must differ from the previous password (eight of the\n characters unless otherwise specified), this is a finding.\"\n tag \"fix\": \"If any user accounts are managed by Oracle: Develop, test and\n implement a password verification function that enforces DoD requirements.\n\n (Oracle supplies a sample function called ORA12C_STRONG_VERIFY_FUNCTION, in the\n script file /RDBMS/ADMIN/utlpwdmg.sql. This can be used as the\n starting point 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-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", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61731.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61657.rb", "line": 1 }, - "id": "V-61731" + "id": "V-61657" }, { - "title": "The DBMS must produce audit records containing sufficient information\n to establish the sources (origins) of the events.", - "desc": "Information system auditing capability is critical for accurate\n forensic analysis. Audit record content that may be necessary to satisfy the\n requirement of this control, includes, but is not limited to: timestamps,\n source and destination IP addresses, user/process identifiers, event\n descriptions, application specific events, success/fail indications, file names\n involved, access control or flow control rules invoked.\n\n Without information establishing the source of activity, the value of audit\n records from a forensics perspective is questionable.", + "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.", "descriptions": { - "default": "Information system auditing capability is critical for accurate\n forensic analysis. Audit record content that may be necessary to satisfy the\n requirement of this control, includes, but is not limited to: timestamps,\n source and destination IP addresses, user/process identifiers, event\n descriptions, application specific events, success/fail indications, file names\n involved, access control or flow control rules invoked.\n\n Without information establishing the source of activity, the value of audit\n records from a forensics perspective is questionable." + "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." }, "impact": 0.5, "refs": [], "tags": { - "gtitle": "SRG-APP-000098-DB-000042", - "gid": "V-61635", - "rid": "SV-76125r1_rule", - "stig_id": "O121-C2-007700", - "fix_id": "F-67547r1_fix", + "gtitle": "SRG-APP-000212-DB-000123", + "gid": "V-61885", + "rid": "SV-76375r1_rule", + "stig_id": "O121-P2-017400", + "fix_id": "F-67801r1_fix", "cci": [ - "CCI-000133" + "CCI-001083" ], "nist": [ - "AU-3", + "SC-2 (1)", "Rev_4" ], "false_negatives": null, @@ -847,21 +813,21 @@ "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\n SHOW PARAMETER AUDIT_TRAIL\n\n or the following SQL query:\n\n SELECT * FROM SYS.V$PARAMETER WHERE NAME = 'audit_trail';\n\n If Oracle returns the value 'NONE', this is a finding.\n\n To confirm that Oracle audit is capturing sufficient information to establish\n the source of events, perform a successful auditable action and an auditable\n action that results in an SQL error, and then view the results in the SYS.AUD$\n table or the audit file, whichever is in use.\n\n If correct values for User ID, User Host, and Terminal are not returned when\n applicable, this is a finding.\n\n If Unified Auditing is used:\n To see if Oracle is configured to capture audit data, enter the following\n SQL*Plus command:\n\n SELECT * FROM V$OPTION WHERE PARAMETER = 'Unified Auditing';\n\n If Oracle returns the value \"TRUE\", this is not a finding.\n\n To confirm that Oracle audit is capturing sufficient information to establish\n the source of events, perform a successful auditable action and an auditable\n action that results in an SQL error, and then view the results in the\n SYS.UNIFIED_AUDIT_TRAIL view.\n\n If correct values for User ID, User Host, and Terminal are not returned when\n applicable, this is a finding.", - "fix": "Configure the DBMS's auditing to audit standard and\n organization-defined auditable events, the audit record to include the source\n of the event. If preferred, use a third-party or custom tool.\n\n If using a third-party product, proceed in accordance with the product\n documentation. If using Oracle's capabilities, proceed as follows.\n\n If Standard Auditing is used:\n Use this process to ensure auditable events are captured:\n\n ALTER SYSTEM SET AUDIT_TRAIL= SCOPE=SPFILE;\n\n Audit trail type can be 'OS', 'DB', 'DB,EXTENDED', 'XML' or '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.\n\n\n\n Oracle 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" + "check": "Check DBMS settings and vendor documentation to verify\n administrative functionality is separate from user functionality.\n\n If administrator and general user functionality is not separated either\n physically or logically, this is a finding.", + "fix": "Configure DBMS settings to separate database administration and\n general user functionality. Provide those who have both administrative and\n general-user responsibilities with separate accounts for these separate\n functions." }, - "code": "control 'V-61635' do\n title \"The DBMS must produce audit records containing sufficient information\n to establish the sources (origins) of the events.\"\n desc \"Information system auditing capability is critical for accurate\n forensic analysis. Audit record content that may be necessary to satisfy the\n requirement of this control, includes, but is not limited to: timestamps,\n source and destination IP addresses, user/process identifiers, event\n descriptions, application specific events, success/fail indications, file names\n involved, access control or flow control rules invoked.\n\n Without information establishing the source of activity, the value of audit\n records from a forensics perspective is questionable.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000098-DB-000042'\n tag \"gid\": 'V-61635'\n tag \"rid\": 'SV-76125r1_rule'\n tag \"stig_id\": 'O121-C2-007700'\n tag \"fix_id\": 'F-67547r1_fix'\n tag \"cci\": ['CCI-000133']\n tag \"nist\": ['AU-3', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Verify, using vendor and system documentation if necessary,\n that the DBMS is configured to use Oracle's auditing features, or that a\n third-party product or custom code is deployed and configured to satisfy this\n requirement.\n\n If a third-party product or custom code is used, compare its current\n configuration with the audit requirements. If any of the requirements is not\n covered by the configuration, this is a finding.\n\n The remainder of this Check is applicable specifically where Oracle auditing is\n in use.\n\n If Standard Auditing is used:\n To see if Oracle is configured to capture audit data, enter the following\n SQL*Plus command:\n\n SHOW PARAMETER AUDIT_TRAIL\n\n or the following SQL query:\n\n SELECT * FROM SYS.V$PARAMETER WHERE NAME = 'audit_trail';\n\n If Oracle returns the value 'NONE', this is a finding.\n\n To confirm that Oracle audit is capturing sufficient information to establish\n the source of events, perform a successful auditable action and an auditable\n action that results in an SQL error, and then view the results in the SYS.AUD$\n table or the audit file, whichever is in use.\n\n If correct values for User ID, User Host, and Terminal are not returned when\n applicable, this is a finding.\n\n If Unified Auditing is used:\n To see if Oracle is configured to capture audit data, enter the following\n SQL*Plus command:\n\n SELECT * FROM V$OPTION WHERE PARAMETER = 'Unified Auditing';\n\n If Oracle returns the value \\\"TRUE\\\", this is not a finding.\n\n To confirm that Oracle audit is capturing sufficient information to establish\n the source of events, perform a successful auditable action and an auditable\n action that results in an SQL error, and then view the results in the\n SYS.UNIFIED_AUDIT_TRAIL view.\n\n If correct values for User ID, User Host, and Terminal are not returned when\n applicable, this is a finding.\"\n tag \"fix\": \"Configure the DBMS's auditing to audit standard and\n organization-defined auditable events, the audit record to include the source\n of the event. If preferred, use a third-party or custom tool.\n\n If using a third-party product, proceed in accordance with the product\n documentation. If using Oracle's capabilities, proceed as follows.\n\n If Standard Auditing is used:\n Use this process to ensure auditable events are captured:\n\n ALTER SYSTEM SET AUDIT_TRAIL= SCOPE=SPFILE;\n\n Audit trail type can be 'OS', 'DB', 'DB,EXTENDED', 'XML' or '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.\n\n\n\n Oracle 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 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-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", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61635.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61885.rb", "line": 1 }, - "id": "V-61635" + "id": "V-61885" }, { - "title": "The DBMS must limit the number of consecutive failed logon attempts to\n 3.", - "desc": "Anytime an authentication method is exposed, to allow for the\n utilization of an application, there is a risk that attempts will be made to\n obtain unauthorized access.\n\n To defeat these attempts, organizations define the number of times a user\n account may consecutively fail a logon attempt. The organization also defines\n the period of time in which these consecutive failed attempts may occur.\n\n By limiting the number of failed logon attempts, the risk of unauthorized\n system access via user password guessing, otherwise known as brute forcing, is\n reduced. Limits are imposed by locking the account.\n\n More recent brute force attacks make attempts over long periods of time to\n circumvent intrusion detection systems and system account lockouts based\n entirely on the number of failed logons that are typically reset after a\n successful logon.\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 Note also that a policy that places no limit on the length of the timeframe\n (for counting consecutive invalid attempts) does satisfy this requirement.", + "title": "The DBMS must support organizational requirements to prohibit password\n reuse for the organization-defined number of generations.", + "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 Password reuse restrictions protect against bypass of password expiration\n requirements and help protect accounts from password guessing attempts.\n\n Note that user authentication and account management must be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP. This requirement applies to cases where it is necessary to\n have accounts directly managed by Oracle.", "descriptions": { - "default": "Anytime an authentication method is exposed, to allow for the\n utilization of an application, there is a risk that attempts will be made to\n obtain unauthorized access.\n\n To defeat these attempts, organizations define the number of times a user\n account may consecutively fail a logon attempt. The organization also defines\n the period of time in which these consecutive failed attempts may occur.\n\n By limiting the number of failed logon attempts, the risk of unauthorized\n system access via user password guessing, otherwise known as brute forcing, is\n reduced. Limits are imposed by locking the account.\n\n More recent brute force attacks make attempts over long periods of time to\n circumvent intrusion detection systems and system account lockouts based\n entirely on the number of failed logons that are typically reset after a\n successful logon.\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 Note also that a policy that places no limit on the length of the timeframe\n (for counting consecutive invalid attempts) does satisfy this requirement." + "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 Password reuse restrictions protect against bypass of password expiration\n requirements and help protect accounts from password guessing attempts.\n\n Note that user authentication and account management must be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP. This requirement applies to cases where it is necessary to\n have accounts directly managed by Oracle." }, "impact": 0.5, "refs": [ @@ -870,16 +836,16 @@ } ], "tags": { - "gtitle": "SRG-APP-000065-DB-000025", - "gid": "V-61605", - "rid": "SV-76095r2_rule", - "stig_id": "O121-C2-005000", - "fix_id": "F-67521r3_fix", + "gtitle": "SRG-APP-000165-DB-000081", + "gid": "V-61721", + "rid": "SV-76211r2_rule", + "stig_id": "O121-C2-014000", + "fix_id": "F-67637r2_fix", "cci": [ - "CCI-000044" + "CCI-000200" ], "nist": [ - "AC-7 a", + "IA-5 (1) (e)", "Rev_4" ], "false_negatives": null, @@ -892,21 +858,21 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "(This addresses both O121-C2-005000 and O121-C2-005200.)\n\n The limit on the number of consecutive failed logon attempts is defined in the\n profile assigned to a user.\n\n To see what profile is assigned to a user, enter the following query:\n SQL>SELECT profile FROM dba_users WHERE username = '&USERNAME'\n This will return the profile name assigned to that user.\n\n Now check the values assigned to the profile returned from the query above:\n SQL>SELECT PROFILE, RESOURCE_NAME, LIMIT FROM DBA_PROFILES WHERE PROFILE LIKE\n '&PROFILE_NAME'\n\n Check the settings for FAILED_LOGIN_ATTEMPTS - this is the number of\n consecutive failed logon attempts before locking the Oracle user account. If\n the value is greater than 3, this is a finding.", - "fix": "(This addresses both O121-C2-005000 and O121-C2-005200.)\n\n Configure the DBMS settings to specify the maximum number of consecutive failed\n logon attempts to 3 (or less):\n ALTER PROFILE ORA_STIG_PROFILE LIMIT FAILED_LOGIN_ATTEMPTS 3;\n\n (ORA_STIG_PROFILE is available in DBA_PROFILES, starting with Oracle 12.1.0.2.\n Note: It remains necessary to create a customized replacement for the password\n validation function, ORA12C_STRONG_VERIFY_FUNCTION, if relying on this\n technique to verify password complexity.)" + "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 reuse rule, if any, that is in effect:\n SELECT * FROM SYS.DBA_PROFILES\n WHERE RESOURCE_NAME IN ('PASSWORD_REUSE_MAX', 'PASSWORD_REUSE_TIME')\n [AND PROFILE NOT IN ()]\n ORDER BY PROFILE, RESOURCE_NAME;\n Bearing in mind that a profile can inherit from another profile, and the root\n profile is called DEFAULT, determine the value of the PASSWORD_REUSE_MAX\n effective for each profile.\n\n If, for any profile, the PASSWORD_REUSE_MAX value does not enforce the\n DoD-defined minimum number of password changes before a password may be\n repeated (five or greater), this is a finding.\n\n PASSWORD_REUSE_MAX is effective if and only if PASSWORD_REUSE_TIME is\n specified, so if both are UNLIMITED, 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: For each profile, set the\n PASSWORD_REUSE_MAX to enforce the DoD-defined minimum number of password\n changes before a password may be repeated (five or greater).\n\n PASSWORD_REUSE_MAX is effective if and only if PASSWORD_REUSE_TIME is\n specified, so ensure also that it has a meaningful value. Since the minimum\n password lifetime is 1 day, the smallest meaningful value is the same as the\n PASSWORD_REUSE_MAX value.\n\n Using PPPPPP as an example, the statement to do this is:\n ALTER PROFILE PPPPPP LIMIT PASSWORD_REUSE_MAX 5 PASSWORD_REUSE_TIME 5;" }, - "code": "control 'V-61605' do\n title \"The DBMS must limit the number of consecutive failed logon attempts to\n 3.\"\n desc \"Anytime an authentication method is exposed, to allow for the\n utilization of an application, there is a risk that attempts will be made to\n obtain unauthorized access.\n\n To defeat these attempts, organizations define the number of times a user\n account may consecutively fail a logon attempt. The organization also defines\n the period of time in which these consecutive failed attempts may occur.\n\n By limiting the number of failed logon attempts, the risk of unauthorized\n system access via user password guessing, otherwise known as brute forcing, is\n reduced. Limits are imposed by locking the account.\n\n More recent brute force attacks make attempts over long periods of time to\n circumvent intrusion detection systems and system account lockouts based\n entirely on the number of failed logons that are typically reset after a\n successful logon.\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 Note also that a policy that places no limit on the length of the timeframe\n (for counting consecutive invalid attempts) does satisfy this requirement.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000065-DB-000025'\n tag \"gid\": 'V-61605'\n tag \"rid\": 'SV-76095r2_rule'\n tag \"stig_id\": 'O121-C2-005000'\n tag \"fix_id\": 'F-67521r3_fix'\n tag \"cci\": ['CCI-000044']\n tag \"nist\": ['AC-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\": \"(This addresses both O121-C2-005000 and O121-C2-005200.)\n\n The limit on the number of consecutive failed logon attempts is defined in the\n profile assigned to a user.\n\n To see what profile is assigned to a user, enter the following query:\n SQL>SELECT profile FROM dba_users WHERE username = '&USERNAME'\n This will return the profile name assigned to that user.\n\n Now check the values assigned to the profile returned from the query above:\n SQL>SELECT PROFILE, RESOURCE_NAME, LIMIT FROM DBA_PROFILES WHERE PROFILE LIKE\n '&PROFILE_NAME'\n\n Check the settings for FAILED_LOGIN_ATTEMPTS - this is the number of\n consecutive failed logon attempts before locking the Oracle user account. If\n the value is greater than 3, this is a finding.\"\n tag \"fix\": \"(This addresses both O121-C2-005000 and O121-C2-005200.)\n\n Configure the DBMS settings to specify the maximum number of consecutive failed\n logon attempts to 3 (or less):\n ALTER PROFILE ORA_STIG_PROFILE LIMIT FAILED_LOGIN_ATTEMPTS 3;\n\n (ORA_STIG_PROFILE is available in DBA_PROFILES, starting with Oracle 12.1.0.2.\n Note: It remains necessary to create a customized replacement for the password\n validation function, ORA12C_STRONG_VERIFY_FUNCTION, if relying on this\n technique to verify password complexity.)\"\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 = 'FAILED_LOGIN_ATTEMPTS'\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_lock_time = sql.query(format(query, profile: profile)).column('limit')\n\n describe \"The oracle database limit for failed login attempts for profile: #{profile}\" do\n subject { password_lock_time.first }\n it { should cmp <= input('failed_logon_attempts') }\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-61721' do\n title \"The DBMS must support organizational requirements to prohibit password\n reuse for the organization-defined number of generations.\"\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 Password reuse restrictions protect against bypass of password expiration\n requirements and help protect accounts from password guessing attempts.\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-000165-DB-000081'\n tag \"gid\": 'V-61721'\n tag \"rid\": 'SV-76211r2_rule'\n tag \"stig_id\": 'O121-C2-014000'\n tag \"fix_id\": 'F-67637r2_fix'\n tag \"cci\": ['CCI-000200']\n tag \"nist\": ['IA-5 (1) (e)', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"If all user accounts are 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 reuse rule, if any, that is in effect:\n SELECT * FROM SYS.DBA_PROFILES\n WHERE RESOURCE_NAME IN ('PASSWORD_REUSE_MAX', 'PASSWORD_REUSE_TIME')\n [AND PROFILE NOT IN ()]\n ORDER BY PROFILE, RESOURCE_NAME;\n Bearing in mind that a profile can inherit from another profile, and the root\n profile is called DEFAULT, determine the value of the PASSWORD_REUSE_MAX\n effective for each profile.\n\n If, for any profile, the PASSWORD_REUSE_MAX value does not enforce the\n DoD-defined minimum number of password changes before a password may be\n repeated (five or greater), this is a finding.\n\n PASSWORD_REUSE_MAX is effective if and only if PASSWORD_REUSE_TIME is\n specified, so if both are UNLIMITED, 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: For each profile, set the\n PASSWORD_REUSE_MAX to enforce the DoD-defined minimum number of password\n changes before a password may be repeated (five or greater).\n\n PASSWORD_REUSE_MAX is effective if and only if PASSWORD_REUSE_TIME is\n specified, so ensure also that it has a meaningful value. Since the minimum\n password lifetime is 1 day, the smallest meaningful value is the same as the\n PASSWORD_REUSE_MAX value.\n\n Using PPPPPP as an example, the statement to do this is:\n ALTER PROFILE PPPPPP LIMIT PASSWORD_REUSE_MAX 5 PASSWORD_REUSE_TIME 5;\"\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_password_max_reuse = %{\n SELECT PROFILE, RESOURCE_NAME, LIMIT FROM DBA_PROFILES WHERE PROFILE =\n '%s' AND RESOURCE_NAME = 'PASSWORD_REUSE_MAX'\n }\n\n query_password_reuse_time = %{\n SELECT PROFILE, RESOURCE_NAME, LIMIT FROM DBA_PROFILES WHERE PROFILE =\n '%s' AND RESOURCE_NAME = 'PASSWORD_REUSE_TIME'\n }\n\n user_profiles = sql.query('SELECT profile FROM dba_users;').column('profile').uniq\n\n user_profiles.each do |profile|\n next if profile == \"RDSADMIN\"\n password_reuse_max = sql.query(format(query_password_max_reuse, profile: profile)).column('limit')\n password_reuse_time = sql.query(format(query_password_reuse_time, profile: profile)).column('limit')\n\n describe \"The oracle database account password reuse max for profile: #{profile}\" do\n subject { password_reuse_max }\n it { should_not cmp 'UNLIMITED' }\n end\n\n describe \"The oracle database account password reuse time for profile: #{profile}\" do\n subject { password_reuse_time }\n it { should_not cmp 'UNLIMITED' }\n end\n end\n if user_profiles.empty?\n describe 'There are no user profiles, therefore this control is NA' do\n skip 'There are no user profiles, therefore this control is NA'\n end\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61605.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61721.rb", "line": 1 }, - "id": "V-61605" + "id": "V-61721" }, { - "title": "The DBMS must use multifactor authentication for network access to\n privileged accounts.", - "desc": "Multifactor authentication is defined as using two or more factors to\n achieve authentication.\n\n Factors include:\n (i) Something a user knows (e.g., password/PIN);\n (ii) Something a user has (e.g., cryptographic identification device,\n token); or\n (iii) Something a user is (e.g., biometric).\n\n A privileged account is defined as an information system account with\n authorizations of a privileged user.\n\n Network access is defined as access to an information system by a user (or\n a process acting on behalf of a user) communicating through a network (e.g.,\n local area network, wide area network, Internet).\n\n The lack of multifactor authentication makes it much easier for an attacker\n to gain unauthorized access to a system.\n\n Transport Layer Security (TLS) is the successor protocol to Secure Sockets\n Layer (SSL). Although the Oracle configuration parameters have names including\n 'SSL', such as SSL_VERSION and SSL_CIPHER_SUITES, they refer to TLS.", + "title": "Remote administrative access to the database must be monitored by the\n ISSO or ISSM.", + "desc": "Remote administrative access to systems provides a path for access to\n and exploit of DBA privileges. Where the risk has been accepted to allow remote\n administrative access, it is imperative to instate increased monitoring of this\n access to detect any abuse or compromise.", "descriptions": { - "default": "Multifactor authentication is defined as using two or more factors to\n achieve authentication.\n\n Factors include:\n (i) Something a user knows (e.g., password/PIN);\n (ii) Something a user has (e.g., cryptographic identification device,\n token); or\n (iii) Something a user is (e.g., biometric).\n\n A privileged account is defined as an information system account with\n authorizations of a privileged user.\n\n Network access is defined as access to an information system by a user (or\n a process acting on behalf of a user) communicating through a network (e.g.,\n local area network, wide area network, Internet).\n\n The lack of multifactor authentication makes it much easier for an attacker\n to gain unauthorized access to a system.\n\n Transport Layer Security (TLS) is the successor protocol to Secure Sockets\n Layer (SSL). Although the Oracle configuration parameters have names including\n 'SSL', such as SSL_VERSION and SSL_CIPHER_SUITES, they refer to TLS." + "default": "Remote administrative access to systems provides a path for access to\n and exploit of DBA privileges. Where the risk has been accepted to allow remote\n administrative access, it is imperative to instate increased monitoring of this\n access to detect any abuse or compromise." }, "impact": 0, "refs": [ @@ -915,16 +881,16 @@ } ], "tags": { - "gtitle": "SRG-APP-000149-DB-000104", - "gid": "V-61703", - "rid": "SV-76193r2_rule", - "stig_id": "O121-C2-012900", - "fix_id": "F-67619r1_fix", + "gtitle": "SRG-APP-000516-DB-999900", + "gid": "V-61493", + "rid": "SV-75983r1_rule", + "stig_id": "O121-BP-024400", + "fix_id": "F-67409r1_fix", "cci": [ - "CCI-000765" + "CCI-000366" ], "nist": [ - "IA-2 (1)", + "CM-6 b", "Rev_4" ], "false_negatives": null, @@ -937,39 +903,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Review DBMS settings, OS settings, and/or enterprise-level\n authentication/access mechanism settings to determine whether users logging on\n to privileged accounts via a network are required to use multifactor\n authentication.\n\n If users logging on to privileged accounts via a network are not required to\n use multifactor authentication, this is a finding.\n\n Use authentication to prove the identities of users who are attempting to log\n on to the database. Authenticating user identity is imperative in distributed\n environments, without which there can be little confidence in network security.\n Passwords are the most common means of authentication. Oracle Database enables\n strong authentication with Oracle authentication adapters that support various\n third-party authentication services, including TLS with digital certificates,\n as well as Smart Cards (CAC, PIV).\n\n If the $ORACLE_HOME/network/admin/sqlnet.ora contains entries similar to the\n following, TLS is enabled. (Note: This assumes that a single sqlnet.ora file,\n in the default location, is in use. Please see the supplemental file\n \"Non-default sqlnet.ora configurations.pdf\" for how to find multiple and/or\n differently located sqlnet.ora files.)\n\n SQLNET.AUTHENTICATION_SERVICES= (BEQ, TCPS)\n SSL_VERSION = 1.2 or 1.1\n SSL_CLIENT_AUTHENTICATION = TRUE\n WALLET_LOCATION =\n (SOURCE =\n (METHOD = FILE)\n (METHOD_DATA =\n (DIRECTORY = /u01/app/oracle/product/12.1.0/dbhome_1/owm/wallets)\n )\n )\n\n SSL_CIPHER_SUITES= (SSL_RSA_WITH_AES_256_CBC_SHA384)\n ADR_BASE = /u01/app/oracle\n\n Note: \"SSL_VERSION = 1.2 or 1.1\" is the actual value, not a suggestion to use\n one or the other.", - "fix": "Configure DBMS, OS and/or enterprise-level authentication/access\n mechanism to require multifactor authentication for network users logging on to\n 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)." + "check": "If remote administrative access to the database is prohibited\n and is disabled, this check is not a finding.\n\n Review policy, procedure and evidence of implementation for monitoring of\n remote administrative access to the database.\n\n If monitoring procedures for remote administrative access are not documented or\n implemented, this is a finding.", + "fix": "Develop, document and implement policy and procedures to monitor\n remote administrative access to the DBMS.\n\n The automated generation of a log report with automatic dissemination to the\n ISSO/ISSM may be used.\n\n Require and store an acknowledgement of receipt and confirmation of review for\n the log report." }, - "code": " control 'V-61703' 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-61493' 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-61703.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61493.rb", "line": 1 }, - "id": "V-61703" + "id": "V-61493" }, { - "title": "The DBMS must support organizational requirements to enforce password\n encryption for storage.", - "desc": "Applications must enforce password encryption when storing passwords.\n Passwords need to be protected at all times, and encryption is the standard\n method for protecting passwords. If passwords are not encrypted, they can be\n plainly read and easily compromised.\n\n Database passwords stored in clear text are vulnerable to unauthorized\n disclosure. Database passwords must always be encoded or encrypted when stored\n internally or externally to the DBMS.\n\n Transport Layer Security (TLS) is the successor protocol to Secure Sockets\n Layer (SSL). Although the Oracle configuration parameters have names including\n 'SSL', such as SSL_VERSION and SSL_CIPHER_SUITES, they refer to TLS.", + "title": "Owners of privileged accounts must use non-privileged accounts for\n non-administrative activities.", + "desc": "Use of privileged accounts for non-administrative purposes puts data\n at risk of unintended or unauthorized loss, modification, or exposure. In\n particular, DBA accounts, if used for non-administration application\n development or application maintenance, can lead to excessive 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.", "descriptions": { - "default": "Applications must enforce password encryption when storing passwords.\n Passwords need to be protected at all times, and encryption is the standard\n method for protecting passwords. If passwords are not encrypted, they can be\n plainly read and easily compromised.\n\n Database passwords stored in clear text are vulnerable to unauthorized\n disclosure. Database passwords must always be encoded or encrypted when stored\n internally or externally to the DBMS.\n\n Transport Layer Security (TLS) is the successor protocol to Secure Sockets\n Layer (SSL). Although the Oracle configuration parameters have names including\n 'SSL', such as SSL_VERSION and SSL_CIPHER_SUITES, they refer to TLS." + "default": "Use of privileged accounts for non-administrative purposes puts data\n at risk of unintended or unauthorized loss, modification, or exposure. In\n particular, DBA accounts, if used for non-administration application\n development or application maintenance, can lead to excessive 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." }, - "impact": 0, - "refs": [ - { - "ref": [] - } - ], + "impact": 0.5, + "refs": [], "tags": { - "gtitle": "SRG-APP-000171-DB-000074", - "gid": "V-61733", - "rid": "SV-76223r2_rule", - "stig_id": "O121-C2-014600", - "fix_id": "F-67649r5_fix", + "gtitle": "SRG-APP-000063-DB-000018", + "gid": "V-61597", + "rid": "SV-76087r1_rule", + "stig_id": "O121-C2-004210", + "fix_id": "F-67513r1_fix", "cci": [ - "CCI-000196" + "CCI-000366" ], "nist": [ - "IA-5 (1) (c)", + "CM-6 b", "Rev_4" ], "false_negatives": null, @@ -982,39 +944,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "(Oracle stores and displays its passwords in encrypted form.\n Nevertheless, this should be verified by reviewing the relevant system views,\n along with the other items to be checked here.)\n\n Ask the DBA to review the list of DBMS database objects, database configuration\n files, associated scripts, and applications defined within and external to the\n DBMS that access the database. The list should also include files, tables, or\n settings used to configure the operational environment for the DBMS and for\n interactive DBMS user accounts.\n\n Ask the DBA and/or ISSO to determine if any DBMS database objects, database\n configuration files, associated scripts, and applications defined within or\n external to the DBMS that access the database, and DBMS/user environment\n files/settings/tables, contain database passwords. If any do, confirm that DBMS\n passwords stored internally or externally to the DBMS are encoded or encrypted.\n\n If any passwords are stored in clear text, this is a finding.\n\n Ask the DBA/SA/Application Support staff if they have created an external\n password store for applications, batch jobs, and scripts to use. Verify that\n all passwords stored there are encrypted.\n\n If a password store is used and any password is not encrypted, this is a\n finding.\n\n - - - - -\n The following are notes on implementing a Secure External Password Store using\n Oracle Wallet.\n\n You can store password credentials for connecting to databases by using a\n client-side Oracle wallet. An Oracle wallet is a secure software container that\n stores authentication and signing credentials.\n\n This wallet usage can simplify large-scale deployments that rely on password\n credentials for connecting to databases. When this feature is configured,\n application code, batch jobs, and scripts no longer need embedded user names\n and passwords. This reduces risk because the passwords are no longer exposed,\n and password management policies are more easily enforced without changing\n application code whenever user names or passwords change.\n\n The external password store of the wallet is separate from the area where\n public key infrastructure (PKI) credentials are stored. Consequently, you\n cannot use Oracle Wallet Manager to manage credentials in the external password\n store of the wallet. Instead, use the command-line utility mkstore to manage\n these credentials.\n\n How Does the External Password Store Work?\n\n Typically, users (and applications, batch jobs, and scripts) connect to\n databases by using a standard CONNECT statement that specifies a database\n connection string. This string can include a user name and password, and an\n Oracle Net service name identifying the database on an Oracle Database network.\n If the password is omitted, the connection prompts the user for the password.\n\n For example, the service name could be the URL that identifies that database,\n or a TNS alias entered in the tnsnames.ora file in the database. Another\n possibility is a host:port:sid string.\n\n The following examples are standard CONNECT statements that could be used for a\n client that is not configured to use the external password store:\n\n CONNECT salesapp@sales_db.us.example.com\n Enter password: password\n\n CONNECT salesapp@orasales\n Enter password: password\n\n CONNECT salesapp@ourhost37:1527:DB17\n Enter password: password\n\n In these examples, salesapp is the user name, with the unique connection string\n for the database shown as specified in three different ways. Could use its URL\n sales_db.us.example.com, or its TNS alias, orasales, from the tnsnames.ora\n file, or its host:port:sid string.\n\n However, when clients are configured to use the secure external password store,\n applications can connect to a database with the following CONNECT statement\n syntax, without specifying database logon credentials:\n\n CONNECT /@db_connect_string\n\n CONNECT /@db_connect_string AS SYSDBA\n\n CONNECT /@db_connect_string AS SYSOPER\n\n In this specification, db_connect_string is a valid connection string to access\n the intended database, such as the service name, URL, or alias as shown in the\n earlier examples. Each user account must have its own unique connection string;\n cannot create one connection string for multiple users.\n\n In this case, the database credentials, user name and password, are securely\n stored in an Oracle wallet created for this purpose. The autologon feature of\n this wallet is turned on, so the system does not need a password to open the\n wallet. From the wallet, it gets the credentials to access the database for the\n user they represent.", - "fix": "Develop, document, and maintain a list of DBMS database objects,\n database configuration files, associated scripts, and applications defined\n within or external to the DBMS that access the database, and DBMS/user\n environment files/settings in the System Security Plan.\n\n Record whether they do or do not contain DBMS passwords. If passwords are\n present, ensure they are encoded or encrypted and protected by host system\n security.\n\n - - - - -\n The following are notes on implementing a Secure External Password Store using\n Oracle Wallet.\n\n Oracle provides the capability to provide for a secure external password\n facility. Use the Oracle mkstore to create a secure storage area for passwords\n for applications, batch jobs, and scripts to use, or deploy a site-authorized\n facility to perform this function.\n\n Check to see what has been stored in the Oracle External Password Store\n\n To view all contents of a client wallet external password store, check specific\n credentials by viewing them. Listing the external password store contents\n provides information that can be used to decide whether to add or delete\n credentials from the store. To list the contents of the external password\n store, enter the following command at the command line:\n\n $ mkstore -wrl wallet_location -listCredential\n\n For example: $ mkstore -wrl c:\\oracle\\product\\12.1.0\\db_1\\wallets\n -listCredential\n\n The wallet_location specifies the path to the directory where the wallet, whose\n external password store contents is to be viewed, is located. This command\n lists all of the credential database service names (aliases) and the\n corresponding user name (schema) for that database. Passwords are not listed.\n\n Configuring Clients to Use the External Password Store\n\n If the client is already configured to use external authentication, such as\n Windows native authentication or Transport Layer Security (TLS), then Oracle\n Database uses that authentication method. The same credentials used for this\n type of authentication are typically also used to log on to the database.\n\n For clients not using such authentication methods or wanting to override them\n for database authentication, can set the SQLNET.WALLET_OVERRIDE parameter in\n sqlnet.ora to TRUE. The default value for SQLNET.WALLET_OVERRIDE is FALSE,\n allowing standard use of authentication credentials as before.\n\n If wanting a client to use the secure external password store feature, then\n perform the following configuration task:\n\n 1. Create a wallet on the client by using the following syntax at the command\n line:\n\n mkstore -wrl wallet_location -create\n\n For example: mkstore -wrl c:\\oracle\\product\\12.1.0\\db_1\\wallets -create\n Enter password: password\n\n The wallet_location is the path to the directory where the wallet is to be\n created and stored. This command creates an Oracle wallet with the autologon\n feature enabled at the location specified. The autologon feature enables the\n client to access the wallet contents without supplying a password.\n\n The mkstore utility -create option uses password complexity verification.\n\n 2. Create database connection credentials in the wallet by using the following\n syntax at the command line:\n\n mkstore -wrl wallet_location -createCredential db_connect_string username\n Enter password: password\n\n For example: mkstore -wrl c:\\oracle\\product\\12.1.0\\db_1\\wallets\n -createCredential oracle system\n Enter password: password\n\n In this specification, the wallet_location is the path to the directory where\n the wallet was created. The db_connect_string used in the CONNECT\n /@db_connect_string statement must be identical to the db_connect_string\n specified in the -createCredential command. The db_connect_string is the TNS\n alias used to specify the database in the tnsnames.ora file or any service name\n used to identify the database on an Oracle network. By default, tnsnames.ora is\n located in the $ORACLE_HOME/network/admin directory on UNIX systems and in\n ORACLE_HOME etwork\\admin on Windows. The username is the database logon credential. When\n prompted, enter the password for this user.\n\n 3. In the client sqlnet.ora file, enter the WALLET_LOCATION parameter and set\n it to the directory location of the wallet created in Step 1. For example, if\n created the wallet in $ORACLE_HOME/network/admin and Oracle home is set to\n /private/ora12, then need to enter the following into client sqlnet.ora file:\n\n WALLET_LOCATION =\n (SOURCE =\n (METHOD = FILE)\n (METHOD_DATA =\n (DIRECTORY = /private/ora12/network/admin)\n )\n )\n\n 4. In the client sqlnet.ora file, enter the SQLNET.WALLET_OVERRIDE parameter\n and set it to TRUE as follows:\n\n SQLNET.WALLET_OVERRIDE = TRUE\n\n This setting causes all CONNECT /@db_connect_string statements to use the\n information in the wallet at the specified location to authenticate to\n databases.\n\n When external authentication is in use, an authenticated user with such a\n wallet can use the CONNECT /@db_connect_string syntax to access the previously\n specified databases without providing a user name and password. However, if a\n user fails that external authentication, then these connect statements also\n fail.\n\n Below is a sample sqlnet.ora file with the WALLET_LOCATION and the\n SQLNET.WALLET_OVERRIDE parameters set as described in Steps 3 and 4.\n\n WALLET_LOCATION =\n (SOURCE =\n (METHOD = FILE)\n (METHOD_DATA =\n (DIRECTORY = /private/ora12/network/admin)\n )\n )\n SQLNET.WALLET_OVERRIDE = TRUE\n SSL_CLIENT_AUTHENTICATION = FALSE\n SSL_VERSION = 1.2 or 1.1\n\n Note: \"SSL_VERSION = 1.2 or 1.1\" is the actual value, not a suggestion to use\n one or the other.\n\n (Note: This assumes that a single sqlnet.ora file, in the default location, is\n in use. Please see the supplemental file \"Non-default sqlnet.ora\n configurations.pdf\" for how to find multiple and/or differently located\n sqlnet.ora files.)" + "check": "Review procedures and practices. If there is not a policy\n requiring owners of privileged accounts to use non-privileged accounts for\n non-administrative activities, this is a finding. If there is evidence that\n owners of privileged accounts do not adhere to this policy, this is a finding.", + "fix": "Require that DBAs and other privileged users use non-privileged\n accounts for non-administrative activities." }, - "code": " control 'V-61733' do\n impact 0.0\n describe 'This control is not applicable on oracle within aws rds, as aws manages the operating system in which the oracle database is running on' do\n skip 'This control is not applicable on oracle within aws rds, as aws manages the operating system in which the oracle database is running on'\n end\n end\n", + "code": "control 'V-61597' do\n title \"Owners of privileged accounts must use non-privileged accounts for\n non-administrative activities.\"\n desc \"Use of privileged accounts for non-administrative purposes puts data\n at risk of unintended or unauthorized loss, modification, or exposure. In\n particular, DBA accounts, if used for non-administration application\n development or application maintenance, can lead to excessive 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 impact 0.5\n tag \"gtitle\": 'SRG-APP-000063-DB-000018'\n tag \"gid\": 'V-61597'\n tag \"rid\": 'SV-76087r1_rule'\n tag \"stig_id\": 'O121-C2-004210'\n tag \"fix_id\": 'F-67513r1_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 procedures and practices. If there is not a policy\n requiring owners of privileged accounts to use non-privileged accounts for\n non-administrative activities, this is a finding. If there is evidence that\n owners of privileged accounts do not adhere to this policy, this is a finding.\"\n tag \"fix\": \"Require that DBAs and other privileged users use non-privileged\n accounts for non-administrative activities.\"\n describe 'A manual review is required to ensure owners of privileged accounts use non-privileged accounts for\n non-administrative activities' do\n skip 'A manual review is required to ensure owners of privileged accounts use non-privileged accounts for\n non-administrative activities'\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61733.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61597.rb", "line": 1 }, - "id": "V-61733" + "id": "V-61597" }, { - "title": "The DBMS must support organizational requirements to enforce password\n complexity by the number of numeric characters used.", - "desc": "Password complexity or strength is a measure of the effectiveness of a\n password in resisting attempts at guessing and brute-force attacks.\n\n Password complexity is one factor of several that determine how long it\n takes to crack a password. The more complex the password is, the greater the\n number of possible combinations that need to be tested before the password is\n compromised.\n\n Use of a complex password helps to increase the time and resources required\n to compromise the password.\n\n Note that user authentication and account management must be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP This requirement applies to cases where it is necessary to\n have accounts directly managed by Oracle.", + "title": "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": "Password complexity or strength is a measure of the effectiveness of a\n password in resisting attempts at guessing and brute-force attacks.\n\n Password complexity is one factor of several that determine how long it\n takes to crack a password. The more complex the password is, the greater the\n number of possible combinations that need to be tested before the password is\n compromised.\n\n Use of a complex password helps to increase the time and resources required\n to compromise the password.\n\n Note that user authentication and account management must be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP This requirement applies to cases where it is necessary to\n have accounts directly managed by Oracle." + "default": "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, - "refs": [ - { - "ref": [] - } - ], + "impact": 0, + "refs": [], "tags": { - "gtitle": "SRG-APP-000168-DB-000072", - "gid": "V-61727", - "rid": "SV-76217r1_rule", - "stig_id": "O121-C2-014300", - "fix_id": "F-67643r1_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-000194" + "CCI-000381" ], "nist": [ - "IA-5 (1) (a)", + "CM-7 a", "Rev_4" ], "false_negatives": null, @@ -1027,39 +985,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "If all user accounts are managed and authenticated by the OS or\n an enterprise-level authentication/access mechanism, and not by Oracle, this is\n not a finding.\n\n For each profile that can be applied to accounts where authentication is under\n Oracle's control, determine the password verification function, if any, that is\n in use:\n\n SELECT * FROM SYS.DBA_PROFILES\n WHERE RESOURCE_NAME = 'PASSWORD_VERIFY_FUNCTION'\n [AND PROFILE NOT IN ()]\n ORDER BY PROFILE;\n Bearing in mind that a profile can inherit from another profile, and the root\n profile is called DEFAULT, determine the name of the password verification\n function effective for each profile.\n\n If, for any profile, the function name is null, this is a finding.\n\n For each password verification function, examine its source code.\n\n If it does not enforce the organization-defined minimum number of numeric\n characters (1 unless otherwise specified), this is a finding.", - "fix": "If all user accounts are authenticated by the OS or an\n enterprise-level authentication/access mechanism, and not by Oracle, no fix to\n the DBMS is required.\n\n If any user accounts are managed by Oracle: Develop, test and implement a\n password verification function that enforces DoD requirements.\n\n (Oracle supplies a sample function called ORA12C_STRONG_VERIFY_FUNCTION, in the\n script file\n /RDBMS/ADMIN/utlpwdmg.sql. This can be used as the starting point\n for a customized function.)" + "check": "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