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 61dc9b7a..ce43cb0c 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 identify potentially security-relevant error conditions.", - "desc": "The structure and content of error messages need to be carefully\n considered by the organization and development team. The extent to which the\n application is able to identify and handle error conditions is guided by\n organizational policy and operational requirements.\n\n Database logs can be monitored for specific security-related errors. Any\n error that can have a negative effect on database security should be quickly\n identified and forwarded to the appropriate personnel. If security-relevant\n error conditions are not identified by the DBMS, they may be overlooked by the\n personnel responsible for addressing them.", + "title": "The DBMS must only generate error messages that provide information\n necessary for corrective actions without revealing organization-defined\n sensitive or potentially harmful information in error logs and administrative\n messages that could be exploited.", + "desc": "Any application providing too much information in error logs and in\n administrative messages to the screen risks compromising the data and security\n of the application and system. The structure and content of error messages\n needs to be carefully considered by the organization and development team.\n\n The extent to which the application is able to identify and handle error\n conditions is guided by organizational policy and operational requirements.\n Sensitive information includes account numbers, social security numbers, and\n credit card numbers.\n\n Databases can inadvertently provide a wealth of information to an attacker\n through improperly handled error messages. In addition to sensitive business or\n personal information, database errors can provide host names, IP addresses,\n user names, and other system information not required for troubleshooting but\n very useful to someone targeting the system.\n\n This calls for inspection of application source code, which will require\n collaboration with the application developers. It is recognized that in many\n cases, the database administrator (DBA) is organizationally separate from the\n application developers and may have limited, if any, access to source code.\n Nevertheless, protections of this type are so important to the secure operation\n of databases that they must not be ignored. At a minimum, the DBA must attempt\n to obtain assurances from the development organization that this issue has been\n addressed and must document what has been discovered.", "descriptions": { - "default": "The structure and content of error messages need to be carefully\n considered by the organization and development team. The extent to which the\n application is able to identify and handle error conditions is guided by\n organizational policy and operational requirements.\n\n Database logs can be monitored for specific security-related errors. Any\n error that can have a negative effect on database security should be quickly\n identified and forwarded to the appropriate personnel. If security-relevant\n error conditions are not identified by the DBMS, they may be overlooked by the\n personnel responsible for addressing them." + "default": "Any application providing too much information in error logs and in\n administrative messages to the screen risks compromising the data and security\n of the application and system. The structure and content of error messages\n needs to be carefully considered by the organization and development team.\n\n The extent to which the application is able to identify and handle error\n conditions is guided by organizational policy and operational requirements.\n Sensitive information includes account numbers, social security numbers, and\n credit card numbers.\n\n Databases can inadvertently provide a wealth of information to an attacker\n through improperly handled error messages. In addition to sensitive business or\n personal information, database errors can provide host names, IP addresses,\n user names, and other system information not required for troubleshooting but\n very useful to someone targeting the system.\n\n This calls for inspection of application source code, which will require\n collaboration with the application developers. It is recognized that in many\n cases, the database administrator (DBA) is organizationally separate from the\n application developers and may have limited, if any, access to source code.\n Nevertheless, protections of this type are so important to the secure operation\n of databases that they must not be ignored. At a minimum, the DBA must attempt\n to obtain assurances from the development organization that this issue has been\n addressed and must document what has been discovered." }, "impact": 0.5, "refs": [], "tags": { - "gtitle": "SRG-APP-000265-DB-000161", - "gid": "V-61789", - "rid": "SV-76279r1_rule", - "stig_id": "O121-C2-019800", - "fix_id": "F-67705r1_fix", + "gtitle": "SRG-APP-000266-DB-000162", + "gid": "V-61791", + "rid": "SV-76281r2_rule", + "stig_id": "O121-C2-019900", + "fix_id": "F-67707r1_fix", "cci": [ - "CCI-000366" + "CCI-001312" ], "nist": [ - "CM-6 b", + "SI-11 a", "Rev_4" ], "false_negatives": null, @@ -50,35 +50,39 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Check DBMS settings to determine whether security-related error\n conditions are monitored for, and whether appropriate personnel are notified.\n\n If security-related error conditions are not being monitored for, this is a\n finding.\n\n If appropriate personnel are not alerted when a security-related error\n condition is found, this is a finding.", - "fix": "Configure DBMS to monitor for security-related error conditions.\n\n Configure DBMS to alert appropriate personnel when security-related error\n conditions are found.\n\n This can be accomplished by using Oracle Audit Vault and/or Oracle Enterprise\n Manager. If neither of these products is deployed, then develop a site-specific\n solution.\n\n - - - - -\n Notes to assist in developing a site-specific solution:\n\n The AUD$ table has a column called RETURNCODE. That column provides the return\n code; so, for example, if the security-related condition is someone trying to\n select data from a table that is not there, it would show up in the AUD$ table\n as an ORA-00942 - table or view does not exist. Since the RETURNCODE column is\n only numeric, only the 00942 would be stored. If the query for the information\n returned a row, the process would then need to form and send an email message.\n\n Oracle recommends the use of Oracle Audit Vault to fill this requirement\n without creating a custom solution. It is possible to set up notifications\n and alerts in Enterprise Manager as well, and if either of these alternatives\n is not available, a custom solution will be necessary." + "check": "Check DBMS settings and custom database and application code to\n verify error messages do not contain information beyond what is needed for\n troubleshooting the issue.\n\n If database errors contain PII data, sensitive business data, or information\n useful for identifying the host system, this is a finding.\n\n Notes on Oracle's approach to this issue: Out of the box, Oracle covers this.\n For example, if a user does not have access to a table, the error is just that\n the table or view does not exist. The Oracle database is not going to display a\n Social Security Number in an error code unless an application is programmed to\n do so. Oracle applications will not expose the actual transactional data to a\n screen. The only way Oracle will capture this information is to enable\n specific logging levels. Custom code would require a review to ensure\n compliance.", + "fix": "Configure DBMS and custom database and application code not to\n divulge sensitive information or information useful for system identification\n in error information." }, - "code": "control 'V-61789' do\n title 'The DBMS must identify potentially security-relevant error conditions.'\n desc \"The structure and content of error messages need to be carefully\n considered by the organization and development team. The extent to which the\n application is able to identify and handle error conditions is guided by\n organizational policy and operational requirements.\n\n Database logs can be monitored for specific security-related errors. Any\n error that can have a negative effect on database security should be quickly\n identified and forwarded to the appropriate personnel. If security-relevant\n error conditions are not identified by the DBMS, they may be overlooked by the\n personnel responsible for addressing them.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000265-DB-000161'\n tag \"gid\": 'V-61789'\n tag \"rid\": 'SV-76279r1_rule'\n tag \"stig_id\": 'O121-C2-019800'\n tag \"fix_id\": 'F-67705r1_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\": \"Check DBMS settings to determine whether security-related error\n conditions are monitored for, and whether appropriate personnel are notified.\n\n If security-related error conditions are not being monitored for, this is a\n finding.\n\n If appropriate personnel are not alerted when a security-related error\n condition is found, this is a finding.\"\n tag \"fix\": \"Configure DBMS to monitor for security-related error conditions.\n\n Configure DBMS to alert appropriate personnel when security-related error\n conditions are found.\n\n This can be accomplished by using Oracle Audit Vault and/or Oracle Enterprise\n Manager. If neither of these products is deployed, then develop a site-specific\n solution.\n\n - - - - -\n Notes to assist in developing a site-specific solution:\n\n The AUD$ table has a column called RETURNCODE. That column provides the return\n code; so, for example, if the security-related condition is someone trying to\n select data from a table that is not there, it would show up in the AUD$ table\n as an ORA-00942 - table or view does not exist. Since the RETURNCODE column is\n only numeric, only the 00942 would be stored. If the query for the information\n returned a row, the process would then need to form and send an email message.\n\n Oracle recommends the use of Oracle Audit Vault to fill this requirement\n without creating a custom solution. It is possible to set up notifications\n and alerts in Enterprise Manager as well, and if either of these alternatives\n is not available, a custom solution will be necessary.\"\n describe 'A manual review is required to ensure the DBMS must identifies potentially security-relevant error conditions' do\n skip 'A manual review is required to ensure the DBMS must identifies potentially security-relevant error conditions'\n end\nend\n", + "code": "control 'V-61791' do\n title \"The DBMS must only generate error messages that provide information\n necessary for corrective actions without revealing organization-defined\n sensitive or potentially harmful information in error logs and administrative\n messages that could be exploited.\"\n desc \"Any application providing too much information in error logs and in\n administrative messages to the screen risks compromising the data and security\n of the application and system. The structure and content of error messages\n needs to be carefully considered by the organization and development team.\n\n The extent to which the application is able to identify and handle error\n conditions is guided by organizational policy and operational requirements.\n Sensitive information includes account numbers, social security numbers, and\n credit card numbers.\n\n Databases can inadvertently provide a wealth of information to an attacker\n through improperly handled error messages. In addition to sensitive business or\n personal information, database errors can provide host names, IP addresses,\n user names, and other system information not required for troubleshooting but\n very useful to someone targeting the system.\n\n This calls for inspection of application source code, which will require\n collaboration with the application developers. It is recognized that in many\n cases, the database administrator (DBA) is organizationally separate from the\n application developers and may have limited, if any, access to source code.\n Nevertheless, protections of this type are so important to the secure operation\n of databases that they must not be ignored. At a minimum, the DBA must attempt\n to obtain assurances from the development organization that this issue has been\n addressed and must document what has been discovered.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000266-DB-000162'\n tag \"gid\": 'V-61791'\n tag \"rid\": 'SV-76281r2_rule'\n tag \"stig_id\": 'O121-C2-019900'\n tag \"fix_id\": 'F-67707r1_fix'\n tag \"cci\": ['CCI-001312']\n tag \"nist\": ['SI-11 a', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Check DBMS settings and custom database and application code to\n verify error messages do not contain information beyond what is needed for\n troubleshooting the issue.\n\n If database errors contain PII data, sensitive business data, or information\n useful for identifying the host system, this is a finding.\n\n Notes on Oracle's approach to this issue: Out of the box, Oracle covers this.\n For example, if a user does not have access to a table, the error is just that\n the table or view does not exist. The Oracle database is not going to display a\n Social Security Number in an error code unless an application is programmed to\n do so. Oracle applications will not expose the actual transactional data to a\n screen. The only way Oracle will capture this information is to enable\n specific logging levels. Custom code would require a review to ensure\n compliance.\"\n tag \"fix\": \"Configure DBMS and custom database and application code not to\n divulge sensitive information or information useful for system identification\n in error information.\"\n describe 'A manual review is required to ensure the DBMS only generates error messages that provide information\n necessary for corrective actions without revealing organization-defined\n sensitive or potentially harmful information in error logs and administrative\n messages that could be exploited.' do\n skip 'A manual review is required to ensure the DBMS only generates error messages that provide information\n necessary for corrective actions without revealing organization-defined\n sensitive or potentially harmful information in error logs and administrative\n messages that could be exploited.'\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61789.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61791.rb", "line": 1 }, - "id": "V-61789" + "id": "V-61791" }, { - "title": "The DBMS must have its auditing configured to reduce the likelihood of\n storage capacity being exceeded.", - "desc": "Applications need to be cognizant of potential audit log storage\n capacity issues. During the installation and/or configuration process,\n applications should detect and determine if adequate storage capacity has been\n allocated for audit logs.\n\n During the installation process, a notification may be provided to the\n installer indicating, based on the auditing configuration chosen and the amount\n of storage space allocated for audit logs, the amount of storage capacity\n available is not sufficient to meet storage requirements.\n\n Logging must be configured appropriately. If the logs generated outstrip\n the amount of space reserved for those logs, the system may shut down or take\n other measures to stop processing in order to protect transactions from\n continuing unlogged.", + "title": "The DBMS must support organizational requirements to enforce password\n complexity by the number of special characters used.", + "desc": "Password complexity or strength is a measure of the effectiveness of a\n password in resisting attempts at guessing and brute-force attacks.\n\n Password complexity is one factor of several that determine how long it\n takes to crack a password. The more complex the password is, the greater the\n number of possible combinations that need to be tested before the password is\n compromised.\n\n Use of a complex password helps to increase the time and resources required\n to compromise the password.\n\n Note that user authentication and account management must be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP This requirement applies to cases where it is necessary to\n have accounts directly managed by Oracle.", "descriptions": { - "default": "Applications need to be cognizant of potential audit log storage\n capacity issues. During the installation and/or configuration process,\n applications should detect and determine if adequate storage capacity has been\n allocated for audit logs.\n\n During the installation process, a notification may be provided to the\n installer indicating, based on the auditing configuration chosen and the amount\n of storage space allocated for audit logs, the amount of storage capacity\n available is not sufficient to meet storage requirements.\n\n Logging must be configured appropriately. If the logs generated outstrip\n the amount of space reserved for those logs, the system may shut down or take\n other measures to stop processing in order to protect transactions from\n continuing unlogged." + "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." }, "impact": 0.5, - "refs": [], + "refs": [ + { + "ref": [] + } + ], "tags": { - "gtitle": "SRG-APP-000071-DB-000047", - "gid": "V-61613", - "rid": "SV-76103r1_rule", - "stig_id": "O121-C2-005600", - "fix_id": "F-67529r1_fix", + "gtitle": "SRG-APP-000169-DB-000176", + "gid": "V-61729", + "rid": "SV-76219r1_rule", + "stig_id": "O121-C2-014400", + "fix_id": "F-67645r1_fix", "cci": [ - "CCI-001849" + "CCI-001619" ], "nist": [ - "AU-4", + "IA-5 (1) (a)", "Rev_4" ], "false_negatives": null, @@ -91,30 +95,30 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Review the DBMS settings to determine whether audit logging is\n configured to produce logs consistent with the amount of space allocated for\n logging. If auditing will generate excessive logs so that they may outgrow the\n space reserved for logging, this is a finding.\n\n If file-based auditing is in use, check that sufficient space is available to\n support the file(s). If not, this is a finding\n\n If standard, table-based auditing is used: The audit logs are written to a\n table called AUD$, and if a Virtual Private Database is deployed, we also\n create a table called FGA_LOG$. First check the current location of the audit\n trail tables.\n\n CONN / AS SYSDBA\n\n SELECT table_name, tablespace_name\n FROM dba_tables\n WHERE table_name IN ('AUD$', 'FGA_LOG$')\n ORDER BY table_name;\n\n TABLE_NAME TABLESPACE_NAME\n -------------- ------------------\n AUD$ SYSTEM\n FGA_LOG$ SYSTEM\n\n If the tablespace_name is SYSTEM, the table needs to be relocated to its own\n tablespace. Ensure that adequate space is allocated to that tablespace.\n\n If Unified Auditing is used:\n Audit logs are written to tables in the AUDSYS schema. The default tablespace\n for AUDSYS is USERS. A separate tablespace should be created to contain audit\n data. Ensure that adequate space is allocated to that tablespace.", - "fix": "Allocate sufficient disk space for file-based audit.\n\n Ensure that audit tables are in their own tablespaces and that the tablespaces\n have enough room for the volume of log data that will be produced." + "check": "If all user accounts are managed and authenticated by the OS or\n an enterprise-level authentication/access mechanism, and not by Oracle, this is\n not a finding.\n\n For each profile that can be applied to accounts where authentication is under\n Oracle's control, determine the password verification function, if any, that is\n in use:\n\n SELECT * FROM SYS.DBA_PROFILES\n WHERE RESOURCE_NAME = 'PASSWORD_VERIFY_FUNCTION'\n [AND PROFILE NOT IN ()]\n ORDER BY PROFILE;\n Bearing in mind that a profile can inherit from another profile, and the root\n profile is called DEFAULT, determine the name of the password verification\n function effective for each profile.\n\n If, for any profile, the function name is null, this is a finding.\n\n For each password verification function, examine its source code.\n\n If it does not enforce the organization-defined minimum number of special\n characters (1 unless otherwise specified), this is a finding.", + "fix": "If all user accounts are authenticated by the OS or an\n enterprise-level authentication/access mechanism, and not by Oracle, no fix to\n the DBMS is required.\n\n If any user accounts are managed by Oracle: Develop, test and implement a\n password verification function that enforces DoD requirements.\n\n (Oracle supplies a sample function called ORA12C_STRONG_VERIFY_FUNCTION, in the\n script file\n /RDBMS/ADMIN/utlpwdmg.sql. This can be used as the starting point\n for a customized function.)" }, - "code": "control 'V-61613' do\n title \"The DBMS must have its auditing configured to reduce the likelihood of\n storage capacity being exceeded.\"\n desc \"Applications need to be cognizant of potential audit log storage\n capacity issues. During the installation and/or configuration process,\n applications should detect and determine if adequate storage capacity has been\n allocated for audit logs.\n\n During the installation process, a notification may be provided to the\n installer indicating, based on the auditing configuration chosen and the amount\n of storage space allocated for audit logs, the amount of storage capacity\n available is not sufficient to meet storage requirements.\n\n Logging must be configured appropriately. If the logs generated outstrip\n the amount of space reserved for those logs, the system may shut down or take\n other measures to stop processing in order to protect transactions from\n continuing unlogged.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000071-DB-000047'\n tag \"gid\": 'V-61613'\n tag \"rid\": 'SV-76103r1_rule'\n tag \"stig_id\": 'O121-C2-005600'\n tag \"fix_id\": 'F-67529r1_fix'\n tag \"cci\": ['CCI-001849']\n tag \"nist\": ['AU-4', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Review the DBMS settings to determine whether audit logging is\n configured to produce logs consistent with the amount of space allocated for\n logging. If auditing will generate excessive logs so that they may outgrow the\n space reserved for logging, this is a finding.\n\n If file-based auditing is in use, check that sufficient space is available to\n support the file(s). If not, this is a finding\n\n If standard, table-based auditing is used: The audit logs are written to a\n table called AUD$, and if a Virtual Private Database is deployed, we also\n create a table called FGA_LOG$. First check the current location of the audit\n trail tables.\n\n CONN / AS SYSDBA\n\n SELECT table_name, tablespace_name\n FROM dba_tables\n WHERE table_name IN ('AUD$', 'FGA_LOG$')\n ORDER BY table_name;\n\n TABLE_NAME TABLESPACE_NAME\n -------------- ------------------\n AUD$ SYSTEM\n FGA_LOG$ SYSTEM\n\n If the tablespace_name is SYSTEM, the table needs to be relocated to its own\n tablespace. Ensure that adequate space is allocated to that tablespace.\n\n If Unified Auditing is used:\n Audit logs are written to tables in the AUDSYS schema. The default tablespace\n for AUDSYS is USERS. A separate tablespace should be created to contain audit\n data. Ensure that adequate space is allocated to that tablespace.\"\n tag \"fix\": \"Allocate sufficient disk space for file-based audit.\n\n Ensure that audit tables are in their own tablespaces and that the tablespaces\n have enough room for the volume of log data that will be produced.\"\n describe 'A manual review is required to ensure the DBMS has its auditing configured to reduce the likelihood of\n storage capacity being exceeded' do\n skip 'A manual review is required to ensure the DBMS has its auditing configured to reduce the likelihood of\n storage capacity being exceeded'\n end\nend\n", + "code": "control 'V-61729' do\n title \"The DBMS must support organizational requirements to enforce password\n complexity by the number of special characters used.\"\n desc \"Password complexity or strength is a measure of the effectiveness of a\n password in resisting attempts at guessing and brute-force attacks.\n\n Password complexity is one factor of several that determine how long it\n takes to crack a password. The more complex the password is, the greater the\n number of possible combinations that need to be tested before the password is\n compromised.\n\n Use of a complex password helps to increase the time and resources required\n to compromise the password.\n\n Note that user authentication and account management must be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP This requirement applies to cases where it is necessary to\n have accounts directly managed by Oracle.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000169-DB-000176'\n tag \"gid\": 'V-61729'\n tag \"rid\": 'SV-76219r1_rule'\n tag \"stig_id\": 'O121-C2-014400'\n tag \"fix_id\": 'F-67645r1_fix'\n tag \"cci\": ['CCI-001619']\n tag \"nist\": ['IA-5 (1) (a)', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"If all user accounts are managed and authenticated by the OS or\n an enterprise-level authentication/access mechanism, and not by Oracle, this is\n not a finding.\n\n For each profile that can be applied to accounts where authentication is under\n Oracle's control, determine the password verification function, if any, that is\n in use:\n\n SELECT * FROM SYS.DBA_PROFILES\n WHERE RESOURCE_NAME = 'PASSWORD_VERIFY_FUNCTION'\n [AND PROFILE NOT IN ()]\n ORDER BY PROFILE;\n Bearing in mind that a profile can inherit from another profile, and the root\n profile is called DEFAULT, determine the name of the password verification\n function effective for each profile.\n\n If, for any profile, the function name is null, this is a finding.\n\n For each password verification function, examine its source code.\n\n If it does not enforce the organization-defined minimum number of special\n characters (1 unless otherwise specified), this is a finding.\"\n tag \"fix\": \"If all user accounts are authenticated by the OS or an\n enterprise-level authentication/access mechanism, and not by Oracle, no fix to\n the DBMS is required.\n\n If any user accounts are managed by Oracle: Develop, test and implement a\n password verification function that enforces DoD requirements.\n\n (Oracle supplies a sample function called ORA12C_STRONG_VERIFY_FUNCTION, in the\n script file\n /RDBMS/ADMIN/utlpwdmg.sql. This can be used as the starting point\n for a customized function.)\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n query = %{\n SELECT PROFILE, RESOURCE_NAME, LIMIT FROM DBA_PROFILES WHERE PROFILE =\n '%s' AND RESOURCE_NAME = 'PASSWORD_VERIFY_FUNCTION'\n }\n\n user_profiles = sql.query('SELECT profile FROM dba_users;').column('profile').uniq\n\n user_profiles.each do |profile|\n next if profile == \"RDSADMIN\"\n password_verify_function = sql.query(format(query, profile: profile)).column('limit')\n\n describe \"The oracle database account password verify function for profile: #{profile}\" do\n subject { password_verify_function }\n it { should_not eq ['NULL'] }\n end\n end\n if user_profiles.empty?\n describe 'There are no user profiles, therefore this control is NA' do\n skip 'There are no user profiles, therefore this control is NA'\n end\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61613.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61729.rb", "line": 1 }, - "id": "V-61613" + "id": "V-61729" }, { - "title": "Remote database or other external access must use fully-qualified\n names.", - "desc": "The Oracle GLOBAL_NAMES parameter is used to set the requirement for\n database link names to be the same name as the remote database whose connection\n they define. By using the same name for both, ambiguity is avoided and\n unauthorized or unintended connections to remote databases are less likely.", + "title": "A minimum of two Oracle control files must be defined and configured\n to be stored on separate, archived disks (physical or virtual) or archived\n partitions on a RAID device.", + "desc": "Oracle control files are used to store information critical to Oracle\ndatabase integrity. Oracle uses these files to maintain time synchronization of\ndatabase files as well as at system startup to verify the validity of system\ndata and log files. Loss of access to the control files can affect database\navailability, integrity and recovery.", "descriptions": { - "default": "The Oracle GLOBAL_NAMES parameter is used to set the requirement for\n database link names to be the same name as the remote database whose connection\n they define. By using the same name for both, ambiguity is avoided and\n unauthorized or unintended connections to remote databases are less likely." + "default": "Oracle control files are used to store information critical to Oracle\ndatabase integrity. Oracle uses these files to maintain time synchronization of\ndatabase files as well as at system startup to verify the validity of system\ndata and log files. Loss of access to the control files can affect database\navailability, integrity and recovery." }, - "impact": 0.5, + "impact": 0.3, "refs": [], "tags": { "gtitle": "SRG-APP-000516-DB-999900", - "gid": "V-61529", - "rid": "SV-76019r1_rule", - "stig_id": "O121-BP-026300", - "fix_id": "F-67445r1_fix", + "gid": "V-61417", + "rid": "SV-75907r3_rule", + "stig_id": "O121-BP-021500", + "fix_id": "F-67333r1_fix", "cci": [ "CCI-000366" ], @@ -132,34 +136,30 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "From SQL*Plus:\n\n select value from v$parameter where name = 'global_names';\n\n If the value returned is FALSE, this is a finding.", - "fix": "From SQL*Plus:\n\n alter system set global_names = TRUE scope = spfile;\n\n Note: This parameter, if changed, will affect all currently defined Oracle\n database links.\n\n The above SQL*Plus command will set the parameter to take effect at next system\n startup." + "check": "From SQL*Plus:\n\n select name from v$controlfile;\n\n DoD guidance recommends:\n\n 2a. Each control file is to be located on separate, archived physical or\n virtual storage devices.\n\n OR\n\n 2b. Each control file is to be located on separate, archived directories within\n one or more RAID devices.\n\n 3. The Logical Paths for each control file should differ at the highest level\n supported by the configuration, for example:\n\n UNIX\n /ora03/app/oracle/{SID}/control/control01.ctl\n /ora04/app/oracle/{SID}/control/control02.ctl\n\n Windows\n D:/oracle/{SID}/control/control01.ctl\n E:/oracle/{SID}/control/control02.ctl\n\n If the minimum listed above is not met, this is a finding.\n\n Consult with the SA or DBA to determine that the mount points or partitions\n referenced in the file paths indicate separate physical disks or directories on\n RAID devices.\n\n Note: Distinct does not equal dedicated. May share directory space with other\n Oracle database instances if present.", + "fix": "To prevent loss of service during disk failure, multiple copies\n of Oracle control files must be maintained on separate disks in archived\n directories or on separate, archived directories within one or more RAID\n devices.\n\n Adding or moving a control file requires careful planning and execution.\n\n Consult and follow the instructions for creating control files in the Oracle\n Database Administrator's Guide, under Steps for Creating New Control Files." }, - "code": "control 'V-61529' do\n title \"Remote database or other external access must use fully-qualified\n names.\"\n desc \"The Oracle GLOBAL_NAMES parameter is used to set the requirement for\n database link names to be the same name as the remote database whose connection\n they define. By using the same name for both, ambiguity is avoided and\n unauthorized or unintended connections to remote databases are less likely.\"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000516-DB-999900'\n tag \"gid\": 'V-61529'\n tag \"rid\": 'SV-76019r1_rule'\n tag \"stig_id\": 'O121-BP-026300'\n tag \"fix_id\": 'F-67445r1_fix'\n tag \"cci\": ['CCI-000366']\n tag \"nist\": ['CM-6 b', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"From SQL*Plus:\n\n select value from v$parameter where name = 'global_names';\n\n If the value returned is FALSE, this is a finding.\"\n tag \"fix\": \"From SQL*Plus:\n\n alter system set global_names = TRUE scope = spfile;\n\n Note: This parameter, if changed, will affect all currently defined Oracle\n database links.\n\n The above SQL*Plus command will set the parameter to take effect at next system\n startup.\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n parameter = sql.query(\"select value from v$parameter where name = 'global_names';\").column('value')\n\n describe 'The oracle database GLOBAL_NAMES parameter' do\n subject { parameter }\n it { should_not cmp 'FALSE' }\n end\nend\n", + "code": "control 'V-61417' do\n title \"A minimum of two Oracle control files must be defined and configured\n to be stored on separate, archived disks (physical or virtual) or archived\n partitions on a RAID device.\"\n desc \"Oracle control files are used to store information critical to Oracle\ndatabase integrity. Oracle uses these files to maintain time synchronization of\ndatabase files as well as at system startup to verify the validity of system\ndata and log files. Loss of access to the control files can affect database\navailability, integrity and recovery.\"\n impact 0.3\n tag \"gtitle\": 'SRG-APP-000516-DB-999900'\n tag \"gid\": 'V-61417'\n tag \"rid\": 'SV-75907r3_rule'\n tag \"stig_id\": 'O121-BP-021500'\n tag \"fix_id\": 'F-67333r1_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 name from v$controlfile;\n\n DoD guidance recommends:\n\n 2a. Each control file is to be located on separate, archived physical or\n virtual storage devices.\n\n OR\n\n 2b. Each control file is to be located on separate, archived directories within\n one or more RAID devices.\n\n 3. The Logical Paths for each control file should differ at the highest level\n supported by the configuration, for example:\n\n UNIX\n /ora03/app/oracle/{SID}/control/control01.ctl\n /ora04/app/oracle/{SID}/control/control02.ctl\n\n Windows\n D:/oracle/{SID}/control/control01.ctl\n E:/oracle/{SID}/control/control02.ctl\n\n If the minimum listed above is not met, this is a finding.\n\n Consult with the SA or DBA to determine that the mount points or partitions\n referenced in the file paths indicate separate physical disks or directories on\n RAID devices.\n\n Note: Distinct does not equal dedicated. May share directory space with other\n Oracle database instances if present.\"\n tag \"fix\": \"To prevent loss of service during disk failure, multiple copies\n of Oracle control files must be maintained on separate disks in archived\n directories or on separate, archived directories within one or more RAID\n devices.\n\n Adding or moving a control file requires careful planning and execution.\n\n Consult and follow the instructions for creating control files in the Oracle\n Database Administrator's Guide, under Steps for Creating New Control Files.\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n controlfiles = sql.query('select name from v$controlfile;').column('name')\n partitions = []\n\n controlfiles.each do |files|\n file = files[1..-1]\n get_pos_slash = file.index('/')\n partition = file[0..get_pos_slash]\n partitions.push(partition)\n end\n\n control_file1_partition = partitions[0]\n control_file2_partition = partitions[1]\n\n describe \"The oracable control file permission: #{control_file1_partition}\" do\n subject { control_file1_partition }\n it { should_not cmp control_file2_partition }\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61529.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61417.rb", "line": 1 }, - "id": "V-61529" + "id": "V-61417" }, { - "title": "DBMS processes or services must run under custom, dedicated OS\n accounts.", - "desc": "Separation of duties is a prevalent Information Technology control\n that is implemented at different layers of the information system, including\n the operating system and in applications. It serves to eliminate or reduce the\n possibility that a single user may carry out a prohibited action. Separation of\n duties requires that the person accountable for approving an action is not the\n same person who is tasked with implementing or carrying out that action.\n\n The DBMS must run under a custom dedicated OS account. When the DBMS is\n running under a shared account, users with access to that account could\n inadvertently or maliciously make changes to the DBMS's settings, files, or\n permissions.", + "title": "The DBMS must restrict grants to sensitive information to authorized\n user roles.", + "desc": "Applications employ the concept of least privilege for specific duties\n and information systems (including specific functions, ports, protocols, and\n services). The concept of least privilege is also applied to information system\n processes, ensuring that the processes operate at privilege levels no higher\n than necessary to accomplish required organizational missions and/or functions.\n Organizations consider the creation of additional processes, roles, and\n information system accounts as necessary to achieve least privilege.\n Organizations also apply least privilege concepts to the design, development,\n implementation, and operations of information systems.\n\n Unauthorized access to sensitive data may compromise the confidentiality of\n personnel privacy, threaten national security, or compromise a variety of other\n sensitive operations. Access controls are best managed by defining requirements\n based on distinct job functions and assigning access based on the job function\n assigned to the individual user.", "descriptions": { - "default": "Separation of duties is a prevalent Information Technology control\n that is implemented at different layers of the information system, including\n the operating system and in applications. It serves to eliminate or reduce the\n possibility that a single user may carry out a prohibited action. Separation of\n duties requires that the person accountable for approving an action is not the\n same person who is tasked with implementing or carrying out that action.\n\n The DBMS must run under a custom dedicated OS account. When the DBMS is\n running under a shared account, users with access to that account could\n inadvertently or maliciously make changes to the DBMS's settings, files, or\n permissions." + "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 Unauthorized access to sensitive data may compromise the confidentiality of\n personnel privacy, threaten national security, or compromise a variety of other\n sensitive operations. Access controls are best managed by defining requirements\n based on distinct job functions and assigning access based on the job function\n assigned to the individual user." }, - "impact": 0, - "refs": [ - { - "ref": [] - } - ], + "impact": 0.5, + "refs": [], "tags": { - "gtitle": "SRG-APP-000062-DB-000010", - "gid": "V-61579", - "rid": "SV-76069r1_rule", - "stig_id": "O121-C2-003400", - "fix_id": "F-67495r1_fix", + "gtitle": "SRG-APP-000062-DB-000011", + "gid": "V-61581", + "rid": "SV-76071r1_rule", + "stig_id": "O121-C2-003500", + "fix_id": "F-67497r1_fix", "cci": [ "CCI-000366", "CCI-002220" @@ -178,35 +178,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Check OS settings to determine whether DBMS processes are\n running under a dedicated OS account. If the DBMS processes are running under\n shared accounts, this is a finding.\n\n This is done by the default installation. The installation documentation\n recommends that a user account named ORACLE is created and is identified as the\n software owner.\n\n Log on to the system as the software owner, typically ORACLE, the $ORACLE_HOME\n environment variable will point to the Oracle software. Enter the following\n commands to see if ORACLE is the software owner:\n\n $ cd $ORACLE_HOME\n $ ls -l (shows the directories - oracle is the owner and oinstall is the group.\n The example list below has been truncated)\n drwxr-xr-x 2 oracle oinstall 4096 Nov 21 08:42 addnode\n drwxr-xr-x 8 oracle oinstall 4096 Nov 21 08:41 apex\n drwxr-xr-x 9 oracle oinstall 4096 Nov 21 08:39 assistants\n drwxr-xr-x 2 oracle oinstall 4096 Nov 21 09:17 bin\n drwxr-xr-x 7 oracle oinstall 4096 Nov 21 08:42 ccr\n drwxr-xr-x 3 oracle oinstall 4096 Nov 21 08:42 cdata\n drwxr-xr-x 5 oracle oinstall 4096 Nov 21 09:04 cfgtoollogs\n drwxr-xr-x 4 oracle oinstall 4096 Nov 21 08:42 clone\n drwxr-xr-x 6 oracle oinstall 4096 Nov 21 08:39 crs\n drwxr-xr-x 6 oracle oinstall 4096 Nov 21 08:42 css\n drwxr-xr-x 11 oracle oinstall 4096 Nov 21 08:42 ctx\n drwxr-xr-x 7 oracle oinstall 4096 Nov 21 08:39 cv\n drwxr-xr-x 2 oracle oinstall 4096 Dec 16 13:11 dbs\n drwxr-xr-x 2 oracle oinstall 4096 Nov 21 08:42 dc_ocm\n drwxr-xr-x 5 oracle oinstall 4096 Nov 21 08:45 deinstall\n drwxr-xr-x 3 oracle oinstall 4096 Nov 21 08:39 demo\n drwxr-xr-x 3 oracle oinstall 4096 Nov 21 08:39 diagnostics\n\n $ ps -ef | grep ora_ (shows all of the oracle processes owned by the oracle\n user. The example list below has been truncated)\n\n oracle 1786 1 0 13:11 ? 00:00:00 ora_pmon_stig\n oracle 1788 1 0 13:11 ? 00:00:00 ora_psp0_stig\n oracle 1790 1 1 13:11 ? 00:00:08 ora_vktm_stig\n oracle 1794 1 0 13:11 ? 00:00:00 ora_gen0_stig\n oracle 1796 1 0 13:11 ? 00:00:00 ora_mman_stig\n oracle 1800 1 0 13:11 ? 00:00:00 ora_diag_stig\n oracle 1802 1 0 13:11 ? 00:00:00 ora_dbrm_stig\n oracle 1804 1 0 13:11 ? 00:00:00 ora_vkrm_stig\n oracle 1806 1 0 13:11 ? 00:00:00 ora_dia0_stig\n oracle 1808 1 0 13:11 ? 00:00:00 ora_dbw0_stig\n oracle 1810 1 0 13:11 ? 00:00:00 ora_lgwr_stig\n oracle 1812 1 0 13:11 ? 00:00:00 ora_ckpt_stig\n oracle 1814 1 0 13:11 ? 00:00:00 ora_lg00_stig\n oracle 1816 1 0 13:11 ? 00:00:00 ora_smon_stig\n oracle 1818 1 0 13:11 ? 00:00:00 ora_lg01_stig\n oracle 1820 1 0 13:11 ? 00:00:00 ora_reco_stig\n oracle 1822 1 0 13:11 ? 00:00:00 ora_lreg_stig\n oracle 1824 1 0 13:11 ? 00:00:00 ora_pxmn_stig\n oracle 2137 2125 0 13:25 pts/1 00:00:00 grep ora_", - "fix": "Create an OS account dedicated to Oracle DBMS processes, and\n allow only Oracle DBMS processes to run under the account." + "check": "Obtain a list of privileges assigned to user accounts. If\n access to sensitive information is granted to roles not authorized to access\n sensitive information, this is a finding.\n\n If access to sensitive information is granted to individual accounts rather\n than to a role, this is a finding.", + "fix": "Define application user roles based on privilege and job function\n requirements.\n\n Assign the required privileges to the role and assign the role to authorized\n application user accounts.\n\n Revoke any privileges to sensitive information directly assigned to application\n user accounts." }, - "code": " control 'V-61579' do\n impact 0.0\n describe 'This control is not applicable on oracle within aws rds, as aws manages the operating system in which the oracle database is running on' do\n skip 'This control is not applicable on oracle within aws rds, as aws manages the operating system in which the oracle database is running on'\n end\n end\n", + "code": "control 'V-61581' do\n title \"The DBMS must restrict grants to sensitive information to authorized\n user roles.\"\n desc \"Applications employ the concept of least privilege for specific duties\n and information systems (including specific functions, ports, protocols, and\n services). The concept of least privilege is also applied to information system\n processes, ensuring that the processes operate at privilege levels no higher\n than necessary to accomplish required organizational missions and/or functions.\n Organizations consider the creation of additional processes, roles, and\n information system accounts as necessary to achieve least privilege.\n Organizations also apply least privilege concepts to the design, development,\n implementation, and operations of information systems.\n\n Unauthorized access to sensitive data may compromise the confidentiality of\n personnel privacy, threaten national security, or compromise a variety of other\n sensitive operations. Access controls are best managed by defining requirements\n based on distinct job functions and assigning access based on the job function\n assigned to the individual user.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000062-DB-000011'\n tag \"gid\": 'V-61581'\n tag \"rid\": 'SV-76071r1_rule'\n tag \"stig_id\": 'O121-C2-003500'\n tag \"fix_id\": 'F-67497r1_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\": \"Obtain a list of privileges assigned to user accounts. If\n access to sensitive information is granted to roles not authorized to access\n sensitive information, this is a finding.\n\n If access to sensitive information is granted to individual accounts rather\n than to a role, this is a finding.\"\n tag \"fix\": \"Define application user roles based on privilege and job function\n requirements.\n\n Assign the required privileges to the role and assign the role to authorized\n application user accounts.\n\n Revoke any privileges to sensitive information directly assigned to application\n user accounts.\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n database_roles = sql.query('select * from dba_roles;').column('role')\n\n describe \"A manual review is required to ensure the DBMS estricts grants to sensitive information to authorized user roles. The database roles to review are: #{database_roles}\" do\n skip \"A manual review is required to ensure the DBMS estricts grants to sensitive information to authorized user roles. The database roles to review are: #{database_roles}\"\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61579.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61581.rb", "line": 1 }, - "id": "V-61579" + "id": "V-61581" }, { - "title": "Sensitive information from production database exports must be\n modified before import to a development database.", - "desc": "Data export from production databases may include sensitive data.\n Application developers do not have a need to know to sensitive data. Any access\n they may have to production data would be considered unauthorized access and\n subject the sensitive data to unlawful or unauthorized disclosure. See DODD\n 8500.1 for a definition of Sensitive Information.", + "title": "The DBMS must have allocated audit record storage capacity.", + "desc": "Applications need to be cognizant of potential audit log storage\n capacity issues. During the installation and/or configuration process,\n applications should detect and determine if adequate storage capacity has been\n allocated for audit logs.\n\n During the installation process, a notification may be provided to the\n installer indicating, based on the auditing configuration chosen and the amount\n of storage space allocated for audit logs, the amount of storage capacity\n available is not sufficient to meet storage requirements.\n\n When insufficient space in directories is allocated for audit records,\n database audit logs can fill up and begin to overwrite earlier logs, database\n activity can stop altogether, or auditing could fail and crucial tracking data\n could be lost.", "descriptions": { - "default": "Data export from production databases may include sensitive data.\n Application developers do not have a need to know to sensitive data. Any access\n they may have to production data would be considered unauthorized access and\n subject the sensitive data to unlawful or unauthorized disclosure. See DODD\n 8500.1 for a definition of Sensitive Information." + "default": "Applications need to be cognizant of potential audit log storage\n capacity issues. During the installation and/or configuration process,\n applications should detect and determine if adequate storage capacity has been\n allocated for audit logs.\n\n During the installation process, a notification may be provided to the\n installer indicating, based on the auditing configuration chosen and the amount\n of storage space allocated for audit logs, the amount of storage capacity\n available is not sufficient to meet storage requirements.\n\n When insufficient space in directories is allocated for audit records,\n database audit logs can fill up and begin to overwrite earlier logs, database\n activity can stop altogether, or auditing could fail and crucial tracking data\n could be lost." }, "impact": 0.5, "refs": [], "tags": { - "gtitle": "SRG-APP-000516-DB-999900", - "gid": "V-61453", - "rid": "SV-75943r2_rule", - "stig_id": "O121-BP-023300", - "fix_id": "F-67369r1_fix", + "gtitle": "SRG-APP-000072-DB-000046", + "gid": "V-61615", + "rid": "SV-76105r1_rule", + "stig_id": "O121-C2-005700", + "fix_id": "F-67531r1_fix", "cci": [ - "CCI-000366" + "CCI-001849" ], "nist": [ - "CM-6 b", + "AU-4", "Rev_4" ], "false_negatives": null, @@ -219,30 +219,34 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "If the database being reviewed is a production database, this\n check is not a finding.\n\n Review policy, procedures and restrictions for data imports of production data\n containing sensitive information into development databases.\n\n If data imports of production data are allowed, review procedures for\n protecting any sensitive data included in production exports.\n\n If sensitive data is included in the exports and no procedures are in place to\n remove or modify the data to render it not sensitive prior to import into a\n development database or policy and procedures are not in place to ensure\n authorization of development personnel to access sensitive information\n contained in production data, this is a finding.", - "fix": "Develop, document and implement policy, procedures and\n restrictions for production data import.\n\n Require any users assigned privileges that allow the export of production data\n from the database to acknowledge understanding of import policies, procedures\n and restrictions.\n\n Restrict permissions of development personnel requiring use or access to\n production data imported into development databases containing sensitive\n information to authorized users.\n\n Implement policy and procedures to modify or remove sensitive information in\n production exports prior to import into development databases." + "check": "Review the DBMS settings to determine whether audit logging is\n configured to produce logs consistent with the amount of space allocated for\n logging. If auditing will generate excessive logs so that they may outgrow the\n space reserved for logging, this is a finding.\n\n If file-based auditing is in use, check that sufficient space is available to\n support the file(s). If not, this is a finding\n\n If standard, table-based auditing is used: The audit logs are written to a\n table called AUD$, and if a Virtual Private Database is deployed, we also\n create a table called FGA_LOG$. First check the current location of the audit\n trail tables.\n\n CONN / AS SYSDBA\n\n SELECT table_name, tablespace_name\n FROM dba_tables\n WHERE table_name IN ('AUD$', 'FGA_LOG$')\n ORDER BY table_name;\n\n TABLE_NAME TABLESPACE_NAME\n ------------------------------ ------------------------------\n AUD$ SYSTEM\n FGA_LOG$ SYSTEM\n\n If the tablespace name is SYSTEM, the table needs to be relocated to its own\n tablespace. Ensure that adequate space is allocated to that tablespace.\n\n If Unified Auditing is used:\n Audit logs are written to tables in the AUDSYS schema. The default tablespace\n for AUDSYS is USERS. A separate tablespace should be created to contain audit\n data. Ensure that adequate space is allocated to that tablespace.", + "fix": "Allocate sufficient disk space for file-based audit.\n\n Ensure that audit tables are in their own tablespaces and that the tablespaces\n have enough room for the volume of log data that will be produced." }, - "code": "control 'V-61453' do\n title \"Sensitive information from production database exports must be\n modified before import to a development database.\"\n desc \"Data export from production databases may include sensitive data.\n Application developers do not have a need to know to sensitive data. Any access\n they may have to production data would be considered unauthorized access and\n subject the sensitive data to unlawful or unauthorized disclosure. See DODD\n 8500.1 for a definition of Sensitive Information.\"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000516-DB-999900'\n tag \"gid\": 'V-61453'\n tag \"rid\": 'SV-75943r2_rule'\n tag \"stig_id\": 'O121-BP-023300'\n tag \"fix_id\": 'F-67369r1_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 database being reviewed is a production database, this\n check is not a finding.\n\n Review policy, procedures and restrictions for data imports of production data\n containing sensitive information into development databases.\n\n If data imports of production data are allowed, review procedures for\n protecting any sensitive data included in production exports.\n\n If sensitive data is included in the exports and no procedures are in place to\n remove or modify the data to render it not sensitive prior to import into a\n development database or policy and procedures are not in place to ensure\n authorization of development personnel to access sensitive information\n contained in production data, this is a finding.\"\n tag \"fix\": \"Develop, document and implement policy, procedures and\n restrictions for production data import.\n\n Require any users assigned privileges that allow the export of production data\n from the database to acknowledge understanding of import policies, procedures\n and restrictions.\n\n Restrict permissions of development personnel requiring use or access to\n production data imported into development databases containing sensitive\n information to authorized users.\n\n Implement policy and procedures to modify or remove sensitive information in\n production exports prior to import into development databases.\"\n describe 'A manual review is required to ensure sensitive information from production database exports are\n modified before import to a development database' do\n skip 'A manual review is required to ensure sensitive information from production database exports are\n modified before import to a development database'\n end\nend\n", + "code": "control 'V-61615' do\n title 'The DBMS must have allocated audit record storage capacity.'\n desc \"Applications need to be cognizant of potential audit log storage\n capacity issues. During the installation and/or configuration process,\n applications should detect and determine if adequate storage capacity has been\n allocated for audit logs.\n\n During the installation process, a notification may be provided to the\n installer indicating, based on the auditing configuration chosen and the amount\n of storage space allocated for audit logs, the amount of storage capacity\n available is not sufficient to meet storage requirements.\n\n When insufficient space in directories is allocated for audit records,\n database audit logs can fill up and begin to overwrite earlier logs, database\n activity can stop altogether, or auditing could fail and crucial tracking data\n could be lost.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000072-DB-000046'\n tag \"gid\": 'V-61615'\n tag \"rid\": 'SV-76105r1_rule'\n tag \"stig_id\": 'O121-C2-005700'\n tag \"fix_id\": 'F-67531r1_fix'\n tag \"cci\": ['CCI-001849']\n tag \"nist\": ['AU-4', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Review the DBMS settings to determine whether audit logging is\n configured to produce logs consistent with the amount of space allocated for\n logging. If auditing will generate excessive logs so that they may outgrow the\n space reserved for logging, this is a finding.\n\n If file-based auditing is in use, check that sufficient space is available to\n support the file(s). If not, this is a finding\n\n If standard, table-based auditing is used: The audit logs are written to a\n table called AUD$, and if a Virtual Private Database is deployed, we also\n create a table called FGA_LOG$. First check the current location of the audit\n trail tables.\n\n CONN / AS SYSDBA\n\n SELECT table_name, tablespace_name\n FROM dba_tables\n WHERE table_name IN ('AUD$', 'FGA_LOG$')\n ORDER BY table_name;\n\n TABLE_NAME TABLESPACE_NAME\n ------------------------------ ------------------------------\n AUD$ SYSTEM\n FGA_LOG$ SYSTEM\n\n If the tablespace name is SYSTEM, the table needs to be relocated to its own\n tablespace. Ensure that adequate space is allocated to that tablespace.\n\n If Unified Auditing is used:\n Audit logs are written to tables in the AUDSYS schema. The default tablespace\n for AUDSYS is USERS. A separate tablespace should be created to contain audit\n data. Ensure that adequate space is allocated to that tablespace.\"\n tag \"fix\": \"Allocate sufficient disk space for file-based audit.\n\n Ensure that audit tables are in their own tablespaces and that the tablespaces\n have enough room for the volume of log data that will be produced.\"\n describe 'A manual review is required to ensure the DBMS has allocated audit record storage capacity' do\n skip 'A manual review is required to ensure the DBMS has allocated audit record storage capacity'\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61453.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61615.rb", "line": 1 }, - "id": "V-61453" + "id": "V-61615" }, { - "title": "The DBMS must support the disabling of network protocols deemed by the\n organization to be nonsecure.", - "desc": "This requirement is related to remote access, but more specifically to\n the networking protocols allowing systems to communicate. Remote access is any\n access to an organizational information system by a user (or an information\n system) communicating through an external, non-organization controlled network\n (e.g., the Internet). Examples of remote access methods include dial-up,\n broadband, and wireless.\n\n Some networking protocols allowing remote access may not meet security\n requirements to protect data and components. Bluetooth and peer-to-peer\n networking are examples of less than secure networking protocols.\n\n The DoD Ports, Protocols, and Services Management (PPSM) program provides\n implementation guidance on the use of IP protocols and application and data\n services traversing the DoD Networks in a manner supporting net-centric\n operations.\n\n Applications implementing or utilizing remote access network protocols need\n to ensure the application is developed and implemented in accordance with the\n PPSM requirements. In situations where it has been determined that specific\n operational requirements outweigh the risks of enabling an insecure network\n protocol, the organization may pursue a risk acceptance.\n\n Using protocols deemed nonsecure would compromise the ability of the DBMS\n to operate in a secure fashion. The database must be able to disable network\n protocols deemed nonsecure.", + "title": "The directory assigned to the AUDIT_FILE_DEST parameter must be\n protected from unauthorized access and must be stored in a dedicated directory\n or disk partition separate from software or other application files.", + "desc": "The AUDIT_FILE_DEST parameter specifies the directory where the\n database audit trail file is stored (when AUDIT_TRAIL parameter is set to ‘OS’,\n ‘xml’ or ‘xml, extended’ where supported by the DBMS). Unauthorized access or\n loss of integrity of the audit trail could result in loss of accountability or\n the ability to detect suspicious\n activity. This directory also contains the audit trail of the SYS and\n SYSTEM accounts that captures privileged database events when the database is\n not running (when AUDIT_SYS_OPERATIONS parameter is set to TRUE).", "descriptions": { - "default": "This requirement is related to remote access, but more specifically to\n the networking protocols allowing systems to communicate. Remote access is any\n access to an organizational information system by a user (or an information\n system) communicating through an external, non-organization controlled network\n (e.g., the Internet). Examples of remote access methods include dial-up,\n broadband, and wireless.\n\n Some networking protocols allowing remote access may not meet security\n requirements to protect data and components. Bluetooth and peer-to-peer\n networking are examples of less than secure networking protocols.\n\n The DoD Ports, Protocols, and Services Management (PPSM) program provides\n implementation guidance on the use of IP protocols and application and data\n services traversing the DoD Networks in a manner supporting net-centric\n operations.\n\n Applications implementing or utilizing remote access network protocols need\n to ensure the application is developed and implemented in accordance with the\n PPSM requirements. In situations where it has been determined that specific\n operational requirements outweigh the risks of enabling an insecure network\n protocol, the organization may pursue a risk acceptance.\n\n Using protocols deemed nonsecure would compromise the ability of the DBMS\n to operate in a secure fashion. The database must be able to disable network\n protocols deemed nonsecure." + "default": "The AUDIT_FILE_DEST parameter specifies the directory where the\n database audit trail file is stored (when AUDIT_TRAIL parameter is set to ‘OS’,\n ‘xml’ or ‘xml, extended’ where supported by the DBMS). Unauthorized access or\n loss of integrity of the audit trail could result in loss of accountability or\n the ability to detect suspicious\n activity. This directory also contains the audit trail of the SYS and\n SYSTEM accounts that captures privileged database events when the database is\n not running (when AUDIT_SYS_OPERATIONS parameter is set to TRUE)." }, - "impact": 0.5, - "refs": [], + "impact": 0, + "refs": [ + { + "ref": [] + } + ], "tags": { - "gtitle": "SRG-APP-000020-DB-000194", - "gid": "V-61555", - "rid": "SV-76045r1_rule", - "stig_id": "O121-C2-001700", - "fix_id": "F-67471r1_fix", + "gtitle": "SRG-APP-000516-DB-999900", + "gid": "V-61965", + "rid": "SV-76455r3_rule", + "stig_id": "O121-BP-025101", + "fix_id": "F-67885r1_fix", "cci": [ "CCI-000366" ], @@ -260,39 +264,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Review the PPSM Technical Assurance List to acquire an\n up-to-date list of network protocols deemed nonsecure.\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 Review DBMS settings to determine if the database is utilizing any network\n protocols deemed nonsecure. If the DBMS is not using any network protocols\n deemed nonsecure, this is not a finding.\n\n If the database is utilizing protocols specified as nonsecure in the PPSM,\n verify the protocols are explicitly identified in the System Security Plan and\n that they are in support of specific operational requirements. If they are not\n identified in the SSP or are not supporting specific operational requirements,\n this is a finding.\n\n If nonsecure network protocols are not being used but are not disabled in the\n DBMS's configuration, this is a finding.\n\n After determining the site-specific operational requirements and which\n protocols are explicitly defined in the System Security Plan, check the\n $TNS_ADMIN setting for the location of the Oracle listener.ora file. The\n listener.ora file is a configuration file for Oracle Net Listener that\n identifies the following:\n\n A unique name for the listener, typically LISTENER\n A protocol address that it is accepting connection requests on, and\n A service it is listening for.\n\n If the listener.ora file shows a PROTOCOL= statement and the PROTOCOL is deemed\n nonsecure, that is a finding.\n\n LISTENER=\n (DESCRIPTION=\n (ADDRESS_LIST=\n (ADDRESS=(PROTOCOL=tcp)(HOST=sale-server)(PORT=1521))\n (ADDRESS=(PROTOCOL=ipc)(KEY=extproc))))\n SID_LIST_LISTENER=\n (SID_LIST=\n (SID_DESC=\n (GLOBAL_DBNAME=sales.us.example.com)\n (ORACLE_HOME=/oracle12c)\n (SID_NAME=sales))\n (SID_DESC=\n (SID_NAME=plsextproc)\n (ORACLE_HOME=/oracle12c)\n (PROGRAM=extproc)))\n\n Protocol Parameters\n\n The Oracle Listener and the Oracle Connection Manager are identified by\n protocol addresses. The information below contains the \"Protocol-Specific\n Parameters\" used by the Oracle protocol support.\n\n Protocol-Specific Parameters\n\n Protocol: IPC Parameter: PROTOCOL Notes: Specify ipc as the value.\n Protocol: IPC Parameter: KEY Notes: Specify a unique name for the\n service. Oracle recommends using the service name or SID of the service.\n Example: (PROTOCOL=ipc)(KEY=sales)\n\n Protocol: Named Pipes Parameter: PROTOCOL Notes: Specify nmp as the value.\n Protocol: Named Pipes Parameter: SERVER Notes: Specify the name of the\n Oracle server.\n Protocol: Named Pipes Parameter: PIPE Notes: Specify the pipe name used\n to connect to the database server.\n This is the same PIPE keyword specified on the server with Named Pipes. This\n name can be any name.\n Example: (Protocol=nmp) (SERVER=USDOD) (PIPE=dbpipe01)\n\n Protocol: SDP Parameter: PROTOCOL Notes: Specify sdp as the value.\n Protocol: SDP Parameter: HOST Notes: Specify the host name or IP\n address of the computer.\n Protocol: SDP Parameter: PORT Notes: Specify the listening port number.\n Example: (PROTOCOL=sdp)(HOST=sales-server)(PORT=1521)\n (PROTOCOL=sdp)(HOST=192.168.2.204)(PORT=1521)\n\n Protocol: TCP/IP Parameter: PROTOCOL Notes: Specify TCP as the value.\n Protocol: TCP/IP Parameter: HOST Notes: Specify the host name or IP\n address of the computer.\n Protocol: TCP/IP Parameter: PORT Notes: Specify the listening port number.\n Example: (PROTOCOL=tcp)(HOST=sales-server)(PORT=1521)\n (PROTOCOL=tcp)(HOST=192.168.2.204)(PORT=1521)\n\n Protocol: TCP/IP with TLS Parameter: PROTOCOL Notes: Specify tcps as the\n value.\n Protocol: TCP/IP with TLS Parameter: HOST Notes: Specify the host name or\n IP address of the computer.\n Protocol: TCP/IP with TLS Parameter: PORT Notes: Specify the listening\n port number.\n\n Example:(PROTOCOL=tcps)(HOST=sales-server) (PORT=2484)\n (PROTOCOL=tcps)(HOST=192.168.2.204)(PORT=2484)", - "fix": "Disable any network protocol listed as nonsecure in the PPSM\n documentation.\n\n To disable the protocol deemed not secure, stop the listener by issuing the\n following command as the Oracle Software owner, typically Oracle.\n $ lsnrctl stop\n This will stop the listener. Edit the LISTENER.ORA file and remove the\n protocols deemed not secure and restart the listener.\n\n For example, if TCP was deemed as not secure, the listener.ora would need to be\n changed and the tcp entry would need to be removed. That would only allow the\n listener to listen for an IPC connection.\n\n LISTENER=\n (DESCRIPTION=\n (ADDRESS_LIST=\n (ADDRESS=(PROTOCOL=tcp)(HOST=sale-server)(PORT=1521)) - remove this line\n and properly balance the parentheses -\n (ADDRESS=(PROTOCOL=ipc)(KEY=extproc))))\n SID_LIST_LISTENER=\n (SID_LIST=\n (SID_DESC=\n (GLOBAL_DBNAME=sales.us.example.com)\n (ORACLE_HOME=/oracle12c)\n (SID_NAME=sales))\n (SID_DESC=\n (SID_NAME=plsextproc)\n (ORACLE_HOME=/oracle12c)\n (PROGRAM=extproc)))\n\n Revise the client side TNSNAMES.ORA to align the PROTOCOL value in the PROTOCOL\n portion of the connect string. For example, if TCP was deemed as not secure\n and the listener.ora was changed to listen for an IPC connection the code below\n would be required:\n\n net_service_name=\n (DESCRIPTION=\n (ADDRESS=(PROTOCOL=tcp)(HOST=sales1-svr)(PORT=1521))\n (ADDRESS=(PROTOCOL=tcp)(HOST=sales2-svr)(PORT=1521))\n (CONNECT_DATA=\n (SERVICE_NAME=sales.us.example.com)))" + "check": "If Standard Auditing is used:\n\n From SQL*Plus:\n\n select value from v$parameter where name = 'audit_trail';\n select value from v$parameter where name = 'audit_file_dest';\n\n If audit_trail is NOT set to OS, XML or XML EXTENDED, this is not applicable\n (NA).\n\n If audit_trail is set to OS, but the audit records are routed directly to a\n separate log server without writing to the local file system, this is not a\n finding.\n\n On UNIX Systems:\n\n ls -ld [pathname]\n\n Replace [pathname] with the directory path listed from the above SQL command\n for audit_file_dest.\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 Compare path to $ORACLE_HOME. If audit_file_dest is a subdirectory of\n $ORACLE_HOME, this is a finding.\n\n On Windows Systems (From Windows Explorer):\n\n Browse to the directory specified. Select and right-click on the directory,\n select Properties, select the Security tab. On Windows hosts, records are also\n written to the Windows application event log. The location of the application\n event log is listed under Properties for the log under the Windows console. The\n default location is C:\\WINDOWS\\system32\\config\\EventLogs\\AppEvent.Evt.\n\n If permissions are granted to everyone, this is a finding. If any accounts\n other than the Administrators, DBAs, System group, auditors or backup operators\n are listed, this is a finding.\n\n Compare path to %ORACLE_HOME%. If audit_file_dest is a subdirectory of\n %ORACLE_HOME%, this is a finding.\n\n If Unified Auditing is used:\n AUDIT_FILE_DEST parameter is not used in Unified Auditing", + "fix": "For file-based auditing, establish an audit file directory\n separate from the Oracle Home.\n\n Alter host system permissions to the AUDIT_FILE_DEST directory to the Oracle\n process and software owner accounts, DBAs, backup accounts, SAs (if required),\n and auditors.\n\n Authorize and document user access requirements to the directory outside of the\n Oracle, DBA, and SA account list in the System Security Plan." }, - "code": "control 'V-61555' do\n title \"The DBMS must support the disabling of network protocols deemed by the\n organization to be nonsecure.\"\n desc \"This requirement is related to remote access, but more specifically to\n the networking protocols allowing systems to communicate. Remote access is any\n access to an organizational information system by a user (or an information\n system) communicating through an external, non-organization controlled network\n (e.g., the Internet). Examples of remote access methods include dial-up,\n broadband, and wireless.\n\n Some networking protocols allowing remote access may not meet security\n requirements to protect data and components. Bluetooth and peer-to-peer\n networking are examples of less than secure networking protocols.\n\n The DoD Ports, Protocols, and Services Management (PPSM) program provides\n implementation guidance on the use of IP protocols and application and data\n services traversing the DoD Networks in a manner supporting net-centric\n operations.\n\n Applications implementing or utilizing remote access network protocols need\n to ensure the application is developed and implemented in accordance with the\n PPSM requirements. In situations where it has been determined that specific\n operational requirements outweigh the risks of enabling an insecure network\n protocol, the organization may pursue a risk acceptance.\n\n Using protocols deemed nonsecure would compromise the ability of the DBMS\n to operate in a secure fashion. The database must be able to disable network\n protocols deemed nonsecure.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000020-DB-000194'\n tag \"gid\": 'V-61555'\n tag \"rid\": 'SV-76045r1_rule'\n tag \"stig_id\": 'O121-C2-001700'\n tag \"fix_id\": 'F-67471r1_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 PPSM Technical Assurance List to acquire an\n up-to-date list of network protocols deemed nonsecure.\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 Review DBMS settings to determine if the database is utilizing any network\n protocols deemed nonsecure. If the DBMS is not using any network protocols\n deemed nonsecure, this is not a finding.\n\n If the database is utilizing protocols specified as nonsecure in the PPSM,\n verify the protocols are explicitly identified in the System Security Plan and\n that they are in support of specific operational requirements. If they are not\n identified in the SSP or are not supporting specific operational requirements,\n this is a finding.\n\n If nonsecure network protocols are not being used but are not disabled in the\n DBMS's configuration, this is a finding.\n\n After determining the site-specific operational requirements and which\n protocols are explicitly defined in the System Security Plan, check the\n $TNS_ADMIN setting for the location of the Oracle listener.ora file. The\n listener.ora file is a configuration file for Oracle Net Listener that\n identifies the following:\n\n A unique name for the listener, typically LISTENER\n A protocol address that it is accepting connection requests on, and\n A service it is listening for.\n\n If the listener.ora file shows a PROTOCOL= statement and the PROTOCOL is deemed\n nonsecure, that is a finding.\n\n LISTENER=\n (DESCRIPTION=\n (ADDRESS_LIST=\n (ADDRESS=(PROTOCOL=tcp)(HOST=sale-server)(PORT=1521))\n (ADDRESS=(PROTOCOL=ipc)(KEY=extproc))))\n SID_LIST_LISTENER=\n (SID_LIST=\n (SID_DESC=\n (GLOBAL_DBNAME=sales.us.example.com)\n (ORACLE_HOME=/oracle12c)\n (SID_NAME=sales))\n (SID_DESC=\n (SID_NAME=plsextproc)\n (ORACLE_HOME=/oracle12c)\n (PROGRAM=extproc)))\n\n Protocol Parameters\n\n The Oracle Listener and the Oracle Connection Manager are identified by\n protocol addresses. The information below contains the \\\"Protocol-Specific\n Parameters\\\" used by the Oracle protocol support.\n\n Protocol-Specific Parameters\n\n Protocol: IPC Parameter: PROTOCOL Notes: Specify ipc as the value.\n Protocol: IPC Parameter: KEY Notes: Specify a unique name for the\n service. Oracle recommends using the service name or SID of the service.\n Example: (PROTOCOL=ipc)(KEY=sales)\n\n Protocol: Named Pipes Parameter: PROTOCOL Notes: Specify nmp as the value.\n Protocol: Named Pipes Parameter: SERVER Notes: Specify the name of the\n Oracle server.\n Protocol: Named Pipes Parameter: PIPE Notes: Specify the pipe name used\n to connect to the database server.\n This is the same PIPE keyword specified on the server with Named Pipes. This\n name can be any name.\n Example: (Protocol=nmp) (SERVER=USDOD) (PIPE=dbpipe01)\n\n Protocol: SDP Parameter: PROTOCOL Notes: Specify sdp as the value.\n Protocol: SDP Parameter: HOST Notes: Specify the host name or IP\n address of the computer.\n Protocol: SDP Parameter: PORT Notes: Specify the listening port number.\n Example: (PROTOCOL=sdp)(HOST=sales-server)(PORT=1521)\n (PROTOCOL=sdp)(HOST=192.168.2.204)(PORT=1521)\n\n Protocol: TCP/IP Parameter: PROTOCOL Notes: Specify TCP as the value.\n Protocol: TCP/IP Parameter: HOST Notes: Specify the host name or IP\n address of the computer.\n Protocol: TCP/IP Parameter: PORT Notes: Specify the listening port number.\n Example: (PROTOCOL=tcp)(HOST=sales-server)(PORT=1521)\n (PROTOCOL=tcp)(HOST=192.168.2.204)(PORT=1521)\n\n Protocol: TCP/IP with TLS Parameter: PROTOCOL Notes: Specify tcps as the\n value.\n Protocol: TCP/IP with TLS Parameter: HOST Notes: Specify the host name or\n IP address of the computer.\n Protocol: TCP/IP with TLS Parameter: PORT Notes: Specify the listening\n port number.\n\n Example:(PROTOCOL=tcps)(HOST=sales-server) (PORT=2484)\n (PROTOCOL=tcps)(HOST=192.168.2.204)(PORT=2484)\"\n tag \"fix\": \"Disable any network protocol listed as nonsecure in the PPSM\n documentation.\n\n To disable the protocol deemed not secure, stop the listener by issuing the\n following command as the Oracle Software owner, typically Oracle.\n $ lsnrctl stop\n This will stop the listener. Edit the LISTENER.ORA file and remove the\n protocols deemed not secure and restart the listener.\n\n For example, if TCP was deemed as not secure, the listener.ora would need to be\n changed and the tcp entry would need to be removed. That would only allow the\n listener to listen for an IPC connection.\n\n LISTENER=\n (DESCRIPTION=\n (ADDRESS_LIST=\n (ADDRESS=(PROTOCOL=tcp)(HOST=sale-server)(PORT=1521)) - remove this line\n and properly balance the parentheses -\n (ADDRESS=(PROTOCOL=ipc)(KEY=extproc))))\n SID_LIST_LISTENER=\n (SID_LIST=\n (SID_DESC=\n (GLOBAL_DBNAME=sales.us.example.com)\n (ORACLE_HOME=/oracle12c)\n (SID_NAME=sales))\n (SID_DESC=\n (SID_NAME=plsextproc)\n (ORACLE_HOME=/oracle12c)\n (PROGRAM=extproc)))\n\n Revise the client side TNSNAMES.ORA to align the PROTOCOL value in the PROTOCOL\n portion of the connect string. For example, if TCP was deemed as not secure\n and the listener.ora was changed to listen for an IPC connection the code below\n would be required:\n\n net_service_name=\n (DESCRIPTION=\n (ADDRESS=(PROTOCOL=tcp)(HOST=sales1-svr)(PORT=1521))\n (ADDRESS=(PROTOCOL=tcp)(HOST=sales2-svr)(PORT=1521))\n (CONNECT_DATA=\n (SERVICE_NAME=sales.us.example.com)))\"\n describe 'A manual review is required to ensure the DBMS supports the disabling of network protocols deemed by the\n organization to be nonsecure' do\n skip 'A manual review is required to ensure the DBMS supports the disabling of network protocols deemed by the\n organization to be nonsecure'\n end\nend\n", + "code": " control 'V-61965' 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-61555.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61965.rb", "line": 1 }, - "id": "V-61555" + "id": "V-61965" }, { - "title": "The DBMS must use multifactor authentication for local access to\n non-privileged accounts.", - "desc": "Multifactor authentication is defined as using two or more factors to\n achieve authentication.\n\n Factors include:\n (i) Something a user knows (e.g., password/PIN);\n (ii) Something a user has (e.g., cryptographic identification device,\n token); or\n (iii) Something a user is (e.g., biometric).\n\n A non-privileged account is defined as an information system account with\n authorizations of a regular or non-privileged user.\n\n Local Access is defined as access to an organizational information system\n by a user (or process acting on behalf of a user) communicating through a\n direct connection without the use of a network.\n\n The lack of multifactor authentication makes it much easier for an attacker\n to gain unauthorized access to a system.\n\n Transport Layer Security (TLS) is the successor protocol to Secure Sockets\n Layer (SSL). Although the Oracle configuration parameters have names including\n 'SSL', such as SSL_VERSION and SSL_CIPHER_SUITES, they refer to TLS.", + "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.", "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 non-privileged account is defined as an information system account with\n authorizations of a regular or non-privileged user.\n\n Local Access is defined as access to an organizational information system\n by a user (or process acting on behalf of a user) communicating through a\n direct connection without the use of a network.\n\n The lack of multifactor authentication makes it much easier for an attacker\n to gain unauthorized access to a system.\n\n Transport Layer Security (TLS) is the successor protocol to Secure Sockets\n Layer (SSL). Although the Oracle configuration parameters have names including\n 'SSL', such as SSL_VERSION and SSL_CIPHER_SUITES, they refer to TLS." + "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." }, - "impact": 0, - "refs": [ - { - "ref": [] - } - ], + "impact": 0.5, + "refs": [], "tags": { - "gtitle": "SRG-APP-000152-DB-000107", - "gid": "V-61709", - "rid": "SV-76199r2_rule", - "stig_id": "O121-C2-013200", - "fix_id": "F-67625r1_fix", + "gtitle": "SRG-APP-000201-DB-000145", + "gid": "V-61763", + "rid": "SV-76253r1_rule", + "stig_id": "O121-C2-017100", + "fix_id": "F-67679r1_fix", "cci": [ - "CCI-000768" + "CCI-000366" ], "nist": [ - "IA-2 (4)", + "CM-6 b", "Rev_4" ], "false_negatives": null, @@ -305,35 +305,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 non-privileged accounts locally are required to use multifactor\n authentication.\n\n If users logging on to privileged accounts locally are not required to use\n multifactor authentication, this is a finding.\n\n Use authentication to prove the identities of users who are attempting to log\n on to the database. Authenticating user identity is imperative in distributed\n environments, without which there can be little confidence in network security.\n Passwords are the most common means of authentication. Oracle Database enables\n strong authentication with Oracle authentication adapters that support various\n third-party authentication services, including TLS with digital certificates.\n\n If the $ORACLE_HOME/network/admin/sqlnet.ora contains entries similar to the\n following, TLS is enabled.\n (Note: This assumes that a single sqlnet.ora file, in the default location, is\n in use. Please see the supplemental file \"Non-default sqlnet.ora\n configurations.pdf\" for how to find multiple and/or differently located\n sqlnet.ora files.)\n\n SQLNET.AUTHENTICATION_SERVICES= (BEQ, TCPS)\n SSL_VERSION = 1.2 or 1.1\n SSL_CLIENT_AUTHENTICATION = TRUE\n WALLET_LOCATION =\n (SOURCE =\n (METHOD = FILE)\n (METHOD_DATA =\n (DIRECTORY = /u01/app/oracle/product/12.1.0/dbhome_1/owm/wallets)\n )\n )\n SSL_CIPHER_SUITES= (SSL_RSA_WITH_AES_256_CBC_SHA384)\n ADR_BASE = /u01/app/oracle\n\n Note: \"SSL_VERSION = 1.2 or 1.1\" is the actual value, not a suggestion to\n use one or the other.", - "fix": "Configure DBMS, OS and/or enterprise-level authentication/access\n mechanism to require multifactor authentication for local users logging on to\n non-privileged accounts.\n\n If appropriate, enable support for Transport Layer Security (TLS) protocols and\n multifactor authentication through the use of Smart Cards (CAC/PIV)." + "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." }, - "code": " control 'V-61709' do\n impact 0.0\n describe 'This control is not applicable on oracle within aws rds, as aws manages the operating system in which the oracle database is running on' do\n skip 'This control is not applicable on oracle within aws rds, as aws manages the operating system in which the oracle database is running on'\n end\n end\n", + "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", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61709.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61763.rb", "line": 1 }, - "id": "V-61709" + "id": "V-61763" }, { - "title": "The DBMS must support organizational requirements to encrypt\n information stored in the database and information extracted or derived from\n the database and stored on digital media.", - "desc": "When data is written to digital media, such as hard drives, mobile\n computers, external/removable hard drives, personal digital assistants,\n flash/thumb drives, etc., there is risk of data loss and/or compromise.\n\n An organizational assessment of risk guides the selection of media and\n associated information contained on that media requiring restricted access.\n Organizations need to document in policy and procedures the media requiring\n restricted access, individuals authorized to access the media, and the specific\n measures taken to restrict access.\n\n Fewer protection measures are needed for media containing information\n determined by the organization to be in the public domain, to be publicly\n releasable, or to have limited or no adverse impact if accessed by other than\n authorized personnel. In these situations, it is assumed the physical access\n controls where the media resides provide adequate protection.\n\n As part of a defense-in-depth strategy, the organization considers\n routinely encrypting information at rest on selected secondary storage devices.\n The decision whether to employ cryptography is the responsibility of the\n information owner/steward, who exercises discretion within the framework of\n applicable rules, policies, and law. The selection of the cryptographic\n mechanisms used is based upon maintaining the confidentiality and integrity of\n the information.\n\n The strength of mechanisms is commensurate with the classification and\n sensitivity of the information.\n\n Information at rest, when not encrypted, is open to compromise from\n attackers who have gained unauthorized access to the data files.", + "title": "The system must provide a report generation capability for audit\n reduction data.", + "desc": "In support of Audit Review, Analysis, and Reporting requirements,\n audit reduction is a technique used to reduce the volume of audit records in\n order to facilitate a manual review.\n\n Before a security review is conducted, information systems and/or\n applications with an audit reduction capability may remove many audit records\n known to have little security significance. This is generally accomplished by\n removing records generated by specified classes of events, such as records\n generated by nightly backups.\n\n In order to identify and report on what (repetitive) data has been removed\n via the use of audit reduction, the application must provide a capability to\n generate reports containing what values were removed by the audit reduction.\n\n Audit reduction does not alter original audit records. An audit reduction\n capability provides support for near real-time audit review and analysis based\n on policy-based requirements and after-the-fact investigations of security\n incidents.\n\n Reporting tools employing audit reduction methods must not alter the\n original audit data. An example of a tool employing audit reduction methods is\n the Windows Event Viewer tool which is used to view and analyze audit logs on\n Windows systems.\n\n The lack of reporting tools for audit reduction can require the DBA, or\n others responsible for reviewing audit logs, to sort through large amounts of\n data in order to find relevant records. This can cause important audit records\n to be missed.", "descriptions": { - "default": "When data is written to digital media, such as hard drives, mobile\n computers, external/removable hard drives, personal digital assistants,\n flash/thumb drives, etc., there is risk of data loss and/or compromise.\n\n An organizational assessment of risk guides the selection of media and\n associated information contained on that media requiring restricted access.\n Organizations need to document in policy and procedures the media requiring\n restricted access, individuals authorized to access the media, and the specific\n measures taken to restrict access.\n\n Fewer protection measures are needed for media containing information\n determined by the organization to be in the public domain, to be publicly\n releasable, or to have limited or no adverse impact if accessed by other than\n authorized personnel. In these situations, it is assumed the physical access\n controls where the media resides provide adequate protection.\n\n As part of a defense-in-depth strategy, the organization considers\n routinely encrypting information at rest on selected secondary storage devices.\n The decision whether to employ cryptography is the responsibility of the\n information owner/steward, who exercises discretion within the framework of\n applicable rules, policies, and law. The selection of the cryptographic\n mechanisms used is based upon maintaining the confidentiality and integrity of\n the information.\n\n The strength of mechanisms is commensurate with the classification and\n sensitivity of the information.\n\n Information at rest, when not encrypted, is open to compromise from\n attackers who have gained unauthorized access to the data files." + "default": "In support of Audit Review, Analysis, and Reporting requirements,\n audit reduction is a technique used to reduce the volume of audit records in\n order to facilitate a manual review.\n\n Before a security review is conducted, information systems and/or\n applications with an audit reduction capability may remove many audit records\n known to have little security significance. This is generally accomplished by\n removing records generated by specified classes of events, such as records\n generated by nightly backups.\n\n In order to identify and report on what (repetitive) data has been removed\n via the use of audit reduction, the application must provide a capability to\n generate reports containing what values were removed by the audit reduction.\n\n Audit reduction does not alter original audit records. An audit reduction\n capability provides support for near real-time audit review and analysis based\n on policy-based requirements and after-the-fact investigations of security\n incidents.\n\n Reporting tools employing audit reduction methods must not alter the\n original audit data. An example of a tool employing audit reduction methods is\n the Windows Event Viewer tool which is used to view and analyze audit logs on\n Windows systems.\n\n The lack of reporting tools for audit reduction can require the DBA, or\n others responsible for reviewing audit logs, to sort through large amounts of\n data in order to find relevant records. This can cause important audit records\n to be missed." }, - "impact": 0.5, + "impact": 0.3, "refs": [], "tags": { - "gtitle": "SRG-APP-000188-DB-000121", - "gid": "V-61755", - "rid": "SV-76245r2_rule", - "stig_id": "O121-C2-016400", - "fix_id": "F-67671r1_fix", + "gtitle": "SRG-APP-000114-DB-000054", + "gid": "V-61969", + "rid": "SV-76459r1_rule", + "stig_id": "O121-C3-008800", + "fix_id": "F-67889r1_fix", "cci": [ - "CCI-002262" + "CCI-001878" ], "nist": [ - "AC-16 a", + "AU-7 a", "Rev_4" ], "false_negatives": null, @@ -346,35 +346,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "If encryption is not required for the database and data derived\n from it, this is not a finding.\n\n Review DBMS settings to determine whether data stored on the database is\n encrypted according to organizational requirements.\n\n If not, this is a finding.\n\n Check the following settings to see if FIPS 140-2 encryption is configured. If\n encryption is not configured, check with the DBA and SYSTEM Administrator to\n see if other mechanisms or third-party products are deployed to encrypt data\n stored in the database.\n\n To see if Oracle is configured for FIPS 140-2 Transparent Data Encryption\n and/or DBMS_CRYPTO, enter the following SQL*Plus command:\n SHOW PARAMETER DBFIPS_140\n or the following SQL query:\n SELECT * FROM SYS.V$PARAMETER WHERE NAME = 'DBFIPS_140';\n 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 SELECT * FROM V$ENCRYPTED_TABLESPACES;\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 SELECT * FROM DBA_ENCRYPTED_COLUMNS;\n If no rows are returned, then there are no encrypted columns within existing\n tables.\n\n Note: For the Solaris platform, when DBFIPS_140 is FALSE, TDE (but not\n DBMS_CRYPTO) can still operate\n in a FIPS 140-compliant manner if FIPS 140 operation is enabled for the Solaris\n Cryptographic Framework.", - "fix": "Configure cryptographic functions to use FIPS 140-2-compliant\n algorithms and hashing functions.\n\n Configure the DBMS and/or the OS to encrypt data at rest according to the\n requirements of the organization.\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" + "check": "Verify that audit reduction capabilities are in place for the\n Oracle audit data. Since Oracle has no reduction capability per se, a\n third-party tool or in-house-developed software must be in place to provide\n this functionality. This must include the ability to report on the excluded\n audit data.\n\n If this capability has not been implemented, this is a finding.", + "fix": "Deploy software capable of performing audit data reduction and of\n reporting on the excluded audit data." }, - "code": "control 'V-61755' do\n title \"The DBMS must support organizational requirements to encrypt\n information stored in the database and information extracted or derived from\n the database and stored on digital media.\"\n desc \"When data is written to digital media, such as hard drives, mobile\n computers, external/removable hard drives, personal digital assistants,\n flash/thumb drives, etc., there is risk of data loss and/or compromise.\n\n An organizational assessment of risk guides the selection of media and\n associated information contained on that media requiring restricted access.\n Organizations need to document in policy and procedures the media requiring\n restricted access, individuals authorized to access the media, and the specific\n measures taken to restrict access.\n\n Fewer protection measures are needed for media containing information\n determined by the organization to be in the public domain, to be publicly\n releasable, or to have limited or no adverse impact if accessed by other than\n authorized personnel. In these situations, it is assumed the physical access\n controls where the media resides provide adequate protection.\n\n As part of a defense-in-depth strategy, the organization considers\n routinely encrypting information at rest on selected secondary storage devices.\n The decision whether to employ cryptography is the responsibility of the\n information owner/steward, who exercises discretion within the framework of\n applicable rules, policies, and law. The selection of the cryptographic\n mechanisms used is based upon maintaining the confidentiality and integrity of\n the information.\n\n The strength of mechanisms is commensurate with the classification and\n sensitivity of the information.\n\n Information at rest, when not encrypted, is open to compromise from\n attackers who have gained unauthorized access to the data files.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000188-DB-000121'\n tag \"gid\": 'V-61755'\n tag \"rid\": 'SV-76245r2_rule'\n tag \"stig_id\": 'O121-C2-016400'\n tag \"fix_id\": 'F-67671r1_fix'\n tag \"cci\": ['CCI-002262']\n tag \"nist\": ['AC-16 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 encryption is not required for the database and data derived\n from it, this is not a finding.\n\n Review DBMS settings to determine whether data stored on the database is\n encrypted according to organizational requirements.\n\n If not, this is a finding.\n\n Check the following settings to see if FIPS 140-2 encryption is configured. If\n encryption is not configured, check with the DBA and SYSTEM Administrator to\n see if other mechanisms or third-party products are deployed to encrypt data\n stored in the database.\n\n To see if Oracle is configured for FIPS 140-2 Transparent Data Encryption\n and/or DBMS_CRYPTO, enter the following SQL*Plus command:\n SHOW PARAMETER DBFIPS_140\n or the following SQL query:\n SELECT * FROM SYS.V$PARAMETER WHERE NAME = 'DBFIPS_140';\n 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 SELECT * FROM V$ENCRYPTED_TABLESPACES;\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 SELECT * FROM DBA_ENCRYPTED_COLUMNS;\n If no rows are returned, then there are no encrypted columns within existing\n tables.\n\n Note: For the Solaris platform, when DBFIPS_140 is FALSE, TDE (but not\n DBMS_CRYPTO) can still operate\n in a FIPS 140-compliant manner if FIPS 140 operation is enabled for the Solaris\n Cryptographic Framework.\"\n tag \"fix\": \"Configure cryptographic functions to use FIPS 140-2-compliant\n algorithms and hashing functions.\n\n Configure the DBMS and/or the OS to encrypt data at rest according to the\n requirements of the organization.\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\"\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-61969' do\n title \"The system must provide a report generation capability for audit\n reduction data.\"\n desc \"In support of Audit Review, Analysis, and Reporting requirements,\n audit reduction is a technique used to reduce the volume of audit records in\n order to facilitate a manual review.\n\n Before a security review is conducted, information systems and/or\n applications with an audit reduction capability may remove many audit records\n known to have little security significance. This is generally accomplished by\n removing records generated by specified classes of events, such as records\n generated by nightly backups.\n\n In order to identify and report on what (repetitive) data has been removed\n via the use of audit reduction, the application must provide a capability to\n generate reports containing what values were removed by the audit reduction.\n\n Audit reduction does not alter original audit records. An audit reduction\n capability provides support for near real-time audit review and analysis based\n on policy-based requirements and after-the-fact investigations of security\n incidents.\n\n Reporting tools employing audit reduction methods must not alter the\n original audit data. An example of a tool employing audit reduction methods is\n the Windows Event Viewer tool which is used to view and analyze audit logs on\n Windows systems.\n\n The lack of reporting tools for audit reduction can require the DBA, or\n others responsible for reviewing audit logs, to sort through large amounts of\n data in order to find relevant records. This can cause important audit records\n to be missed.\n \"\n impact 0.3\n tag \"gtitle\": 'SRG-APP-000114-DB-000054'\n tag \"gid\": 'V-61969'\n tag \"rid\": 'SV-76459r1_rule'\n tag \"stig_id\": 'O121-C3-008800'\n tag \"fix_id\": 'F-67889r1_fix'\n tag \"cci\": ['CCI-001878']\n tag \"nist\": ['AU-7 a', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Verify that audit reduction capabilities are in place for the\n Oracle audit data. Since Oracle has no reduction capability per se, a\n third-party tool or in-house-developed software must be in place to provide\n this functionality. This must include the ability to report on the excluded\n audit data.\n\n If this capability has not been implemented, this is a finding.\"\n tag \"fix\": \"Deploy software capable of performing audit data reduction and of\n reporting on the excluded audit data.\"\n describe 'A manual review is required to ensure the system provides a report generation capability for audit\n reduction data' do\n skip 'A manual review is required to ensure the system provides a report generation capability for audit\n reduction data'\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61755.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61969.rb", "line": 1 }, - "id": "V-61755" + "id": "V-61969" }, { - "title": "Application owner accounts must have a dedicated application\n tablespace.", - "desc": "Separation of tablespaces by application helps to protect the\n application from resource contention and unauthorized access that could result\n from storage space reuses or host system access controls. Application data must\n be stored separately from system and custom user-defined objects to facilitate\n administration and management of its data storage. The SYSTEM tablespace must\n never be used for application data storage in order to prevent resource\n contention and performance degradation.", + "title": "The DBMS must allow designated organizational personnel to select\n which auditable events are to be audited by the database.", + "desc": "The list of audited events is the set of events for which audits are\n to be generated. This set of events is typically a subset of the list of all\n events for which the system is capable of generating audit records (i.e.,\n auditable events, timestamps, source and destination addresses, user/process\n identifiers, event descriptions, success/fail indications, file names involved,\n and access control or flow control rules invoked).\n\n If the list of auditable events is not configurable, events that should be\n caught by auditing may be missed. This may allow malicious activity to be\n overlooked.", "descriptions": { - "default": "Separation of tablespaces by application helps to protect the\n application from resource contention and unauthorized access that could result\n from storage space reuses or host system access controls. Application data must\n be stored separately from system and custom user-defined objects to facilitate\n administration and management of its data storage. The SYSTEM tablespace must\n never be used for application data storage in order to prevent resource\n contention and performance degradation." + "default": "The list of audited events is the set of events for which audits are\n to be generated. This set of events is typically a subset of the list of all\n events for which the system is capable of generating audit records (i.e.,\n auditable events, timestamps, source and destination addresses, user/process\n identifiers, event descriptions, success/fail indications, file names involved,\n and access control or flow control rules invoked).\n\n If the list of auditable events is not configurable, events that should be\n caught by auditing may be missed. This may allow malicious activity to be\n overlooked." }, - "impact": 0, + "impact": 0.5, "refs": [], "tags": { - "gtitle": "SRG-APP-000516-DB-999900", - "gid": "V-61461", - "rid": "SV-75951r3_rule", - "stig_id": "O121-BP-023700", - "fix_id": "F-67377r1_fix", + "gtitle": "SRG-APP-000090-DB-000065", + "gid": "V-61623", + "rid": "SV-76113r1_rule", + "stig_id": "O121-C2-006900", + "fix_id": "F-67539r2_fix", "cci": [ - "CCI-000366" + "CCI-000171" ], "nist": [ - "CM-6 b", + "AU-12 b", "Rev_4" ], "false_negatives": null, @@ -387,35 +387,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Run the SQL query:\n\n select distinct owner, tablespace_name\n from dba_SEGMENTS\n where owner not in\n ()\n order by tablespace_name;\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 returned table owners with the tablespace used.\n\n If any of the owners listed are not default Oracle accounts and use the SYSTEM\n or any other tablespace not dedicated for the application’s use, this is a\n finding.\n\n Look for multiple applications that may share a tablespace.\n\n If no records were returned, ask the DBA if any applications use this database.\n\n If no applications use the database, this is not a finding.\n\n If there are applications that do use the database or if the application uses\n the SYS or other default account and SYSTEM tablespace to store its objects,\n this is a finding.", - "fix": "Create and assign dedicated tablespaces for the storage of data\n by each application using the CREATE TABLESPACE command." + "check": "Check DBMS settings and documentation to determine whether\n designated personnel are able to select which auditable events are being\n audited. If designated personnel are not able to configure auditable events,\n this is a finding.", + "fix": "Configure the DBMS's settings to allow designated personnel to\n select which auditable events are audited.\n\n Note the following:\n In Oracle, any user can configure auditing for the objects in his or her own\n schema by using the AUDIT statement. To undo the audit configuration for an\n object, the user can use the NOAUDIT statement. No additional privileges are\n needed to perform this task.\n\n To audit objects in another schema, the user must have the AUDIT ANY system\n privilege.\n To audit system privileges, the user must have the AUDIT SYSTEM privilege.\n\n For more information on the configuration of auditing, refer to the following\n documents:\n \"Auditing Database Activity\" in the Oracle Database 2 Day + Security Guide:\n http://docs.oracle.com/database/121/TDPSG/tdpsg_auditing.htm#TDPSG50000\n \"Monitoring Database Activity with Auditing\" in the Oracle Database Security\n Guide:\n http://docs.oracle.com/database/121/DBSEG/part_6.htm#CCHEHCGI\n \"DBMS_AUDIT_MGMT\" in the Oracle Database PL/SQL Packages and Types Reference:\n http://docs.oracle.com/database/121/ARPLS/d_audit_mgmt.htm#ARPLS241" }, - "code": "control 'V-61461' do\n title \"Application owner accounts must have a dedicated application\n tablespace.\"\n desc \"Separation of tablespaces by application helps to protect the\n application from resource contention and unauthorized access that could result\n from storage space reuses or host system access controls. Application data must\n be stored separately from system and custom user-defined objects to facilitate\n administration and management of its data storage. The SYSTEM tablespace must\n never be used for application data storage in order to prevent resource\n contention and performance degradation.\"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000516-DB-999900'\n tag \"gid\": 'V-61461'\n tag \"rid\": 'SV-75951r3_rule'\n tag \"stig_id\": 'O121-BP-023700'\n tag \"fix_id\": 'F-67377r1_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 distinct owner, tablespace_name\n from dba_SEGMENTS\n where owner not in\n ()\n order by tablespace_name;\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 returned table owners with the tablespace used.\n\n If any of the owners listed are not default Oracle accounts and use the SYSTEM\n or any other tablespace not dedicated for the application’s use, this is a\n finding.\n\n Look for multiple applications that may share a tablespace.\n\n If no records were returned, ask the DBA if any applications use this database.\n\n If no applications use the database, this is not a finding.\n\n If there are applications that do use the database or if the application uses\n the SYS or other default account and SYSTEM tablespace to store its objects,\n this is a finding.\"\n tag \"fix\": \"Create and assign dedicated tablespaces for the storage of data\n by each application using the CREATE TABLESPACE command.\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n application_owners = sql.query(\"select distinct owner\n from dba_SEGMENTS;\").column('owner').uniq\n if application_owners.empty?\n impact 0.0\n describe 'There are no oracle db application owners, therefore control N/A' do\n skip 'There are no oracle db application owners, therefore control N/A'\n end\n else\n application_owners.each do |user|\n describe \"oracle db application owners: #{user}\" do\n subject { user }\n it { should be_in input('allowed_application_owners') }\n end\n end\n end\nend\n", + "code": "control 'V-61623' do\n title \"The DBMS must allow designated organizational personnel to select\n which auditable events are to be audited by the database.\"\n desc \"The list of audited events is the set of events for which audits are\n to be generated. This set of events is typically a subset of the list of all\n events for which the system is capable of generating audit records (i.e.,\n auditable events, timestamps, source and destination addresses, user/process\n identifiers, event descriptions, success/fail indications, file names involved,\n and access control or flow control rules invoked).\n\n If the list of auditable events is not configurable, events that should be\n caught by auditing may be missed. This may allow malicious activity to be\n overlooked.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000090-DB-000065'\n tag \"gid\": 'V-61623'\n tag \"rid\": 'SV-76113r1_rule'\n tag \"stig_id\": 'O121-C2-006900'\n tag \"fix_id\": 'F-67539r2_fix'\n tag \"cci\": ['CCI-000171']\n tag \"nist\": ['AU-12 b', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Check DBMS settings and documentation to determine whether\n designated personnel are able to select which auditable events are being\n audited. If designated personnel are not able to configure auditable events,\n this is a finding.\"\n tag \"fix\": \"Configure the DBMS's settings to allow designated personnel to\n select which auditable events are audited.\n\n Note the following:\n In Oracle, any user can configure auditing for the objects in his or her own\n schema by using the AUDIT statement. To undo the audit configuration for an\n object, the user can use the NOAUDIT statement. No additional privileges are\n needed to perform this task.\n\n To audit objects in another schema, the user must have the AUDIT ANY system\n privilege.\n To audit system privileges, the user must have the AUDIT SYSTEM privilege.\n\n For more information on the configuration of auditing, refer to the following\n documents:\n \\\"Auditing Database Activity\\\" in the Oracle Database 2 Day + Security Guide:\n http://docs.oracle.com/database/121/TDPSG/tdpsg_auditing.htm#TDPSG50000\n \\\"Monitoring Database Activity with Auditing\\\" in the Oracle Database Security\n Guide:\n http://docs.oracle.com/database/121/DBSEG/part_6.htm#CCHEHCGI\n \\\"DBMS_AUDIT_MGMT\\\" in the Oracle Database PL/SQL Packages and Types Reference:\n http://docs.oracle.com/database/121/ARPLS/d_audit_mgmt.htm#ARPLS241\"\n describe 'A manual review is required to ensure the DBMS allows designated organizational personnel to select\n which auditable events are to be audited by the database' do\n skip 'A manual review is required to ensure the DBMS allows designated organizational personnel to select\n which auditable events are to be audited by the database'\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61461.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61623.rb", "line": 1 }, - "id": "V-61461" + "id": "V-61623" }, { - "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.", + "title": "The DBMS must produce audit records containing sufficient information\n to establish where the 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 Without sufficient information establishing where the audit events\n occurred, investigation into the cause of events is severely hindered.", "descriptions": { - "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." + "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 Without sufficient information establishing where the audit events\n occurred, investigation into the cause of events is severely hindered." }, "impact": 0.5, "refs": [], "tags": { - "gtitle": "SRG-APP-000115-DB-000055", - "gid": "V-61649", - "rid": "SV-76139r2_rule", - "stig_id": "O121-C2-008900", - "fix_id": "F-67563r2_fix", + "gtitle": "SRG-APP-000097-DB-000041", + "gid": "V-61633", + "rid": "SV-76123r2_rule", + "stig_id": "O121-C2-007600", + "fix_id": "F-67545r1_fix", "cci": [ - "CCI-000158" + "CCI-000132" ], "nist": [ - "AU-7 (1)", + "AU-3", "Rev_4" ], "false_negatives": null, @@ -428,21 +428,21 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "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." + "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 where events occurred, 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 no DB ID or Object Creator (standard audit) or Object Schema (unified audit)\n or Object Name, or the wrong values, are returned for the auditable actions\n just performed, this is a finding.\n\n If correct values for User Host and Terminal are not returned when applicable,\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 To confirm that Oracle audit is capturing sufficient information to establish\n where events occurred, 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 no DB ID or Object Creator (standard audit) or Object Schema (unified audit)\n or Object Name, or the wrong values,\n are returned for the auditable actions just performed, this is a finding.\n\n If correct values for User Host and Terminal are not returned when applicable,\n this is a finding.\n\n If Unified Auditing is used, the following view can be useful for reviewing its\n output:\n\n CREATE OR REPLACE FORCE VIEW SYS.UNIFIED_AUDIT_TRAIL\n (\n AUDIT_TYPE,\n SESSIONID,\n PROXY_SESSIONID,\n OS_USERNAME,\n USERHOST,\n TERMINAL,\n INSTANCE_ID,\n DBID,\n AUTHENTICATION_TYPE,\n DBUSERNAME,\n DBPROXY_USERNAME,\n EXTERNAL_USERID,\n GLOBAL_USERID,\n CLIENT_PROGRAM_NAME,\n DBLINK_INFO,\n XS_USER_NAME,\n XS_SESSIONID,\n ENTRY_ID,\n STATEMENT_ID,\n EVENT_TIMESTAMP,\n ACTION_NAME,\n RETURN_CODE,\n OS_PROCESS,\n TRANSACTION_ID,\n SCN,\n EXECUTION_ID,\n OBJECT_SCHEMA,\n OBJECT_NAME,\n SQL_TEXT,\n SQL_BINDS,\n APPLICATION_CONTEXTS,\n CLIENT_IDENTIFIER,\n NEW_SCHEMA,\n NEW_NAME,\n OBJECT_EDITION,\n SYSTEM_PRIVILEGE_USED,\n SYSTEM_PRIVILEGE,\n AUDIT_OPTION,\n OBJECT_PRIVILEGES,\n ROLE,\n TARGET_USER,\n EXCLUDED_USER,\n EXCLUDED_SCHEMA,\n EXCLUDED_OBJECT,\n ADDITIONAL_INFO,\n UNIFIED_AUDIT_POLICIES,\n FGA_POLICY_NAME,\n XS_INACTIVITY_TIMEOUT,\n XS_ENTITY_TYPE,\n XS_TARGET_PRINCIPAL_NAME,\n XS_PROXY_USER_NAME,\n XS_DATASEC_POLICY_NAME,\n XS_SCHEMA_NAME,\n XS_CALLBACK_EVENT_TYPE,\n XS_PACKAGE_NAME,\n XS_PROCEDURE_NAME,\n XS_ENABLED_ROLE,\n XS_COOKIE,\n XS_NS_NAME,\n XS_NS_ATTRIBUTE,\n XS_NS_ATTRIBUTE_OLD_VAL,\n XS_NS_ATTRIBUTE_NEW_VAL,\n DV_ACTION_CODE,\n DV_ACTION_NAME,\n DV_EXTENDED_ACTION_CODE,\n DV_GRANTEE,\n DV_RETURN_CODE,\n DV_ACTION_OBJECT_NAME,\n DV_RULE_SET_NAME,\n DV_COMMENT,\n DV_FACTOR_CONTEXT,\n DV_OBJECT_STATUS,\n OLS_POLICY_NAME,\n OLS_GRANTEE,\n OLS_MAX_READ_LABEL,\n OLS_MAX_WRITE_LABEL,\n OLS_MIN_WRITE_LABEL,\n OLS_PRIVILEGES_GRANTED,\n OLS_PROGRAM_UNIT_NAME,\n OLS_PRIVILEGES_USED,\n OLS_STRING_LABEL,\n OLS_LABEL_COMPONENT_TYPE,\n OLS_LABEL_COMPONENT_NAME,\n OLS_PARENT_GROUP_NAME,\n OLS_OLD_VALUE,\n OLS_NEW_VALUE,\n RMAN_SESSION_RECID,\n RMAN_SESSION_STAMP,\n RMAN_OPERATION,\n RMAN_OBJECT_TYPE,\n RMAN_DEVICE_TYPE,\n DP_TEXT_PARAMETERS1,\n DP_BOOLEAN_PARAMETERS1,\n DIRECT_PATH_NUM_COLUMNS_LOADED\n )\n AS\n SELECT act.component,\n sessionid,\n proxy_sessionid,\n os_user,\n host_name,\n terminal,\n instance_id,\n dbid,\n authentication_type,\n userid,\n proxy_userid,\n external_userid,\n global_userid,\n client_program_name,\n dblink_info,\n xs_user_name,\n xs_sessionid,\n entry_id,\n statement_id,\n CAST (event_timestamp AS TIMESTAMP WITH LOCAL TIME ZONE),\n act.name,\n return_code,\n os_process,\n transaction_id,\n scn,\n execution_id,\n obj_owner,\n obj_name,\n sql_text,\n sql_binds,\n application_contexts,\n client_identifier,\n new_owner,\n new_name,\n object_edition,\n system_privilege_used,\n spx.name,\n aom.name,\n object_privileges,\n role,\n target_user,\n excluded_user,\n excluded_schema,\n excluded_object,\n additional_info,\n unified_audit_policies,\n fga_policy_name,\n xs_inactivity_timeout,\n xs_entity_type,\n xs_target_principal_name,\n xs_proxy_user_name,\n xs_datasec_policy_name,\n xs_schema_name,\n xs_callback_event_type,\n xs_package_name,\n xs_procedure_name,\n xs_enabled_role,\n xs_cookie,\n xs_ns_name,\n xs_ns_attribute,\n xs_ns_attribute_old_val,\n xs_ns_attribute_new_val,\n dv_action_code,\n dv_action_name,\n dv_extended_action_code,\n dv_grantee,\n dv_return_code,\n dv_action_object_name,\n dv_rule_set_name,\n dv_comment,\n dv_factor_context,\n dv_object_status,\n ols_policy_name,\n ols_grantee,\n ols_max_read_label,\n ols_max_write_label,\n ols_min_write_label,\n ols_privileges_granted,\n ols_program_unit_name,\n ols_privileges_used,\n ols_string_label,\n ols_label_component_type,\n ols_label_component_name,\n ols_parent_group_name,\n ols_old_value,\n ols_new_value,\n rman_session_recid,\n rman_session_stamp,\n rman_operation,\n rman_object_type,\n rman_device_type,\n dp_text_parameters1,\n dp_boolean_parameters1,\n direct_path_num_columns_loaded\n FROM gv$unified_audit_trail uview,\n all_unified_audit_actions act,\n system_privilege_map spx,\n stmt_audit_option_map aom\n WHERE uview.action = act.action(+)\n AND -uview.system_privilege = spx.privilege(+)\n AND uview.audit_option = aom.option#(+)\n AND uview.audit_type = act.TYPE;", + "fix": "Configure the DBMS's auditing to audit standard and\n organization-defined auditable events, the audit record to include where the\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-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", + "code": "control 'V-61633' do\n title \"The DBMS must produce audit records containing sufficient information\n to establish where the 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 Without sufficient information establishing where the audit events\n occurred, investigation into the cause of events is severely hindered.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000097-DB-000041'\n tag \"gid\": 'V-61633'\n tag \"rid\": 'SV-76123r2_rule'\n tag \"stig_id\": 'O121-C2-007600'\n tag \"fix_id\": 'F-67545r1_fix'\n tag \"cci\": ['CCI-000132']\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 where events occurred, 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 no DB ID or Object Creator (standard audit) or Object Schema (unified audit)\n or Object Name, or the wrong values, are returned for the auditable actions\n just performed, this is a finding.\n\n If correct values for User Host and Terminal are not returned when applicable,\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 To confirm that Oracle audit is capturing sufficient information to establish\n where events occurred, 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 no DB ID or Object Creator (standard audit) or Object Schema (unified audit)\n or Object Name, or the wrong values,\n are returned for the auditable actions just performed, this is a finding.\n\n If correct values for User Host and Terminal are not returned when applicable,\n this is a finding.\n\n If Unified Auditing is used, the following view can be useful for reviewing its\n output:\n\n CREATE OR REPLACE FORCE VIEW SYS.UNIFIED_AUDIT_TRAIL\n (\n AUDIT_TYPE,\n SESSIONID,\n PROXY_SESSIONID,\n OS_USERNAME,\n USERHOST,\n TERMINAL,\n INSTANCE_ID,\n DBID,\n AUTHENTICATION_TYPE,\n DBUSERNAME,\n DBPROXY_USERNAME,\n EXTERNAL_USERID,\n GLOBAL_USERID,\n CLIENT_PROGRAM_NAME,\n DBLINK_INFO,\n XS_USER_NAME,\n XS_SESSIONID,\n ENTRY_ID,\n STATEMENT_ID,\n EVENT_TIMESTAMP,\n ACTION_NAME,\n RETURN_CODE,\n OS_PROCESS,\n TRANSACTION_ID,\n SCN,\n EXECUTION_ID,\n OBJECT_SCHEMA,\n OBJECT_NAME,\n SQL_TEXT,\n SQL_BINDS,\n APPLICATION_CONTEXTS,\n CLIENT_IDENTIFIER,\n NEW_SCHEMA,\n NEW_NAME,\n OBJECT_EDITION,\n SYSTEM_PRIVILEGE_USED,\n SYSTEM_PRIVILEGE,\n AUDIT_OPTION,\n OBJECT_PRIVILEGES,\n ROLE,\n TARGET_USER,\n EXCLUDED_USER,\n EXCLUDED_SCHEMA,\n EXCLUDED_OBJECT,\n ADDITIONAL_INFO,\n UNIFIED_AUDIT_POLICIES,\n FGA_POLICY_NAME,\n XS_INACTIVITY_TIMEOUT,\n XS_ENTITY_TYPE,\n XS_TARGET_PRINCIPAL_NAME,\n XS_PROXY_USER_NAME,\n XS_DATASEC_POLICY_NAME,\n XS_SCHEMA_NAME,\n XS_CALLBACK_EVENT_TYPE,\n XS_PACKAGE_NAME,\n XS_PROCEDURE_NAME,\n XS_ENABLED_ROLE,\n XS_COOKIE,\n XS_NS_NAME,\n XS_NS_ATTRIBUTE,\n XS_NS_ATTRIBUTE_OLD_VAL,\n XS_NS_ATTRIBUTE_NEW_VAL,\n DV_ACTION_CODE,\n DV_ACTION_NAME,\n DV_EXTENDED_ACTION_CODE,\n DV_GRANTEE,\n DV_RETURN_CODE,\n DV_ACTION_OBJECT_NAME,\n DV_RULE_SET_NAME,\n DV_COMMENT,\n DV_FACTOR_CONTEXT,\n DV_OBJECT_STATUS,\n OLS_POLICY_NAME,\n OLS_GRANTEE,\n OLS_MAX_READ_LABEL,\n OLS_MAX_WRITE_LABEL,\n OLS_MIN_WRITE_LABEL,\n OLS_PRIVILEGES_GRANTED,\n OLS_PROGRAM_UNIT_NAME,\n OLS_PRIVILEGES_USED,\n OLS_STRING_LABEL,\n OLS_LABEL_COMPONENT_TYPE,\n OLS_LABEL_COMPONENT_NAME,\n OLS_PARENT_GROUP_NAME,\n OLS_OLD_VALUE,\n OLS_NEW_VALUE,\n RMAN_SESSION_RECID,\n RMAN_SESSION_STAMP,\n RMAN_OPERATION,\n RMAN_OBJECT_TYPE,\n RMAN_DEVICE_TYPE,\n DP_TEXT_PARAMETERS1,\n DP_BOOLEAN_PARAMETERS1,\n DIRECT_PATH_NUM_COLUMNS_LOADED\n )\n AS\n SELECT act.component,\n sessionid,\n proxy_sessionid,\n os_user,\n host_name,\n terminal,\n instance_id,\n dbid,\n authentication_type,\n userid,\n proxy_userid,\n external_userid,\n global_userid,\n client_program_name,\n dblink_info,\n xs_user_name,\n xs_sessionid,\n entry_id,\n statement_id,\n CAST (event_timestamp AS TIMESTAMP WITH LOCAL TIME ZONE),\n act.name,\n return_code,\n os_process,\n transaction_id,\n scn,\n execution_id,\n obj_owner,\n obj_name,\n sql_text,\n sql_binds,\n application_contexts,\n client_identifier,\n new_owner,\n new_name,\n object_edition,\n system_privilege_used,\n spx.name,\n aom.name,\n object_privileges,\n role,\n target_user,\n excluded_user,\n excluded_schema,\n excluded_object,\n additional_info,\n unified_audit_policies,\n fga_policy_name,\n xs_inactivity_timeout,\n xs_entity_type,\n xs_target_principal_name,\n xs_proxy_user_name,\n xs_datasec_policy_name,\n xs_schema_name,\n xs_callback_event_type,\n xs_package_name,\n xs_procedure_name,\n xs_enabled_role,\n xs_cookie,\n xs_ns_name,\n xs_ns_attribute,\n xs_ns_attribute_old_val,\n xs_ns_attribute_new_val,\n dv_action_code,\n dv_action_name,\n dv_extended_action_code,\n dv_grantee,\n dv_return_code,\n dv_action_object_name,\n dv_rule_set_name,\n dv_comment,\n dv_factor_context,\n dv_object_status,\n ols_policy_name,\n ols_grantee,\n ols_max_read_label,\n ols_max_write_label,\n ols_min_write_label,\n ols_privileges_granted,\n ols_program_unit_name,\n ols_privileges_used,\n ols_string_label,\n ols_label_component_type,\n ols_label_component_name,\n ols_parent_group_name,\n ols_old_value,\n ols_new_value,\n rman_session_recid,\n rman_session_stamp,\n rman_operation,\n rman_object_type,\n rman_device_type,\n dp_text_parameters1,\n dp_boolean_parameters1,\n direct_path_num_columns_loaded\n FROM gv$unified_audit_trail uview,\n all_unified_audit_actions act,\n system_privilege_map spx,\n stmt_audit_option_map aom\n WHERE uview.action = act.action(+)\n AND -uview.system_privilege = spx.privilege(+)\n AND uview.audit_option = aom.option#(+)\n AND uview.audit_type = act.TYPE;\"\n tag \"fix\": \"Configure the DBMS's auditing to audit standard and\n organization-defined auditable events, the audit record to include where the\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-61649.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61633.rb", "line": 1 }, - "id": "V-61649" + "id": "V-61633" }, { - "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": "The Oracle Listener must be configured to require administration\n authentication.", + "desc": "Oracle listener authentication helps prevent unauthorized\n administration of the Oracle listener. Unauthorized administration of the\n listener could lead to DoS exploits; loss of connection audit data,\n unauthorized reconfiguration or other unauthorized access. This is a Category I\n finding because privileged access to the listener is not restricted to\n authorized users. Unauthorized access can result in stopping of the listener\n (DoS) and overwriting of listener audit logs.", "descriptions": { - "default": "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": "Oracle listener authentication helps prevent unauthorized\n administration of the Oracle listener. Unauthorized administration of the\n listener could lead to DoS exploits; loss of connection audit data,\n unauthorized reconfiguration or other unauthorized access. This is a Category I\n finding because privileged access to the listener is not restricted to\n authorized users. Unauthorized access can result in stopping of the listener\n (DoS) and overwriting of listener audit logs." }, "impact": 0, "refs": [ @@ -451,16 +451,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-61441", + "rid": "SV-75931r2_rule", + "stig_id": "O121-BP-022700", + "fix_id": "F-67357r1_fix", "cci": [ - "CCI-000765" + "CCI-000366" ], "nist": [ - "IA-2 (1)", + "CM-6 b", "Rev_4" ], "false_negatives": null, @@ -473,36 +473,39 @@ "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 a listener is not running on the local database host server,\n this check is not a finding.\n\n Note: This check needs to be done only once per host system and once per\n listener. Multiple listeners may be defined on a single host system. They must\n all be reviewed, but only once per database home review.\n\n For subsequent database home reviews on the same host system, this check is not\n a finding.\n\n Determine all Listeners running on the host.\n\n For Windows hosts, view all Windows services with TNSListener embedded in the\n service name\n - The service name format is:\n Oracle[ORACLE_HOME_NAME]TNSListener\n\n For UNIX hosts, the Oracle Listener process will indicate the TNSLSNR\n executable.\n\n At a command prompt, issue the command:\n ps -ef | grep tnslsnr | grep -v grep\n\n The alias for the listener follows tnslsnr in the command output.\n\n Must be logged on the host system using the account that owns the tnslsnr\n executable (UNIX). If the account is denied local logon, have the system SA\n assist in this task by adding 'su' to the listener account from the root\n account. On Windows platforms, log on using an account with administrator\n privileges to complete the check.\n\n From a system command prompt, execute the listener control utility:\n\n lsnrctl status [LISTENER NAME]\n\n Review the results for the value of Security.\n\n If \"Security = OFF\" is displayed, this is a finding.\n\n If \"Security = ON: Local OS Authentication\" is displayed, this is not a\n finding.\n\n If \"Security = ON: Password or Local OS Authentication\", this is a finding\n (do not set a password on Oracle versions 10.1 and higher. Instead, use Local\n OS Authentication).\n\n Repeat the execution of the lsnrctl utility for all active listeners.", + "fix": "By default, Oracle Net Listener permits only local administration\n for security reasons. As a policy, the listener can be administered only by the\n user who started it. This is enforced through local operating system\n authentication. For example, if user1 starts the listener, then only user1 can\n administer it. Any other user trying to administer the listener gets an error.\n The super user is the only exception.\n\n Remote administration of the listener must not be permitted. If listener\n administration from a remote system is required, granting secure remote access\n to the Oracle DBMS server and performing local administration is preferred.\n Authorize and document this requirement in the System Security Plan.\n\n Note: In Oracle Database 12c Release 1 (12.1), the listener password feature is\n no longer supported. This does not cause a loss of security because\n authentication is enforced through local operating system authentication. Refer\n to Oracle Database Net Services Reference for additional information." }, - "code": " control 'V-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-61441' do\n impact 0.0\n describe 'This control is not applicable on oracle within aws rds, as aws manages the operating system in which the oracle database is running on' do\n skip 'This control is not applicable on oracle within aws rds, as aws manages the operating system in which the oracle database is running on'\n end\n end\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61703.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61441.rb", "line": 1 }, - "id": "V-61703" + "id": "V-61441" }, { - "title": "The DBMS must implement separation of duties through assigned\n information access authorizations.", - "desc": "Separation of duties is a prevalent Information Technology control\n that is implemented at different layers of the information system, including\n the operating system and in applications. It serves to eliminate or reduce the\n possibility that a single user may carry out a prohibited action. Separation of\n duties requires that the person accountable for approving an action is not the\n same person who is tasked with implementing or carrying out that action.\n\n Additionally, the person or entity accountable for monitoring the activity\n must be separate as well. To meet this requirement, applications, when\n applicable, shall be divided where functionality is based on roles and duties.\n Examples of separation of duties include: (i) mission functions and distinct\n information system support functions are divided among different\n individuals/roles; (ii) different individuals perform information system\n support functions (e.g., system management, systems programming, configuration\n management, quality assurance and testing, network security); (iii) security\n personnel who administer access control functions do not administer audit\n functions; and (iv) different administrator accounts for different roles.\n\n Privileges granted outside the context of the application user job function\n are more likely to go unmanaged or without oversight for authorization.\n Maintenance of privileges using roles defined for discrete job functions offers\n improved oversight of application user privilege assignments and helps to\n protect against unauthorized privilege assignment.", + "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": "Separation of duties is a prevalent Information Technology control\n that is implemented at different layers of the information system, including\n the operating system and in applications. It serves to eliminate or reduce the\n possibility that a single user may carry out a prohibited action. Separation of\n duties requires that the person accountable for approving an action is not the\n same person who is tasked with implementing or carrying out that action.\n\n Additionally, the person or entity accountable for monitoring the activity\n must be separate as well. To meet this requirement, applications, when\n applicable, shall be divided where functionality is based on roles and duties.\n Examples of separation of duties include: (i) mission functions and distinct\n information system support functions are divided among different\n individuals/roles; (ii) different individuals perform information system\n support functions (e.g., system management, systems programming, configuration\n management, quality assurance and testing, network security); (iii) security\n personnel who administer access control functions do not administer audit\n functions; and (iv) different administrator accounts for different roles.\n\n Privileges granted outside the context of the application user job function\n are more likely to go unmanaged or without oversight for authorization.\n Maintenance of privileges using roles defined for discrete job functions offers\n improved oversight of application user privilege assignments and helps to\n protect against unauthorized privilege assignment." + "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.3, - "refs": [], + "impact": 0, + "refs": [ + { + "ref": [] + } + ], "tags": { - "gtitle": "SRG-APP-000062-DB-000009", - "gid": "V-61809", - "rid": "SV-76299r3_rule", - "stig_id": "O121-C3-003300", - "fix_id": "F-67725r1_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-000366", - "CCI-002220" + "CCI-000366" ], "nist": [ - "AC-5 c", + "CM-6 b", "Rev_4" ], "false_negatives": null, @@ -515,35 +518,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Obtain a list of privileges assigned to the DBMS user accounts.\n If any direct privilege assignments exist that can be assigned to a role, this\n is a finding.\n\n SELECT\n 'User '\n || grantee\n || ' is directly granted '\n || privilege\n || ' privilege on '\n || table_name value\n FROM dba_tab_privs\n WHERE grantee NOT IN (SELECT role FROM dba_roles)\n AND grantee NOT IN\n (\n 'XDB', 'SYSTEM', 'SYS', 'LBACSYS',\n 'DVSYS', 'DVF', 'SYSMAN_RO', 'SYSMAN_BIPLATFORM',\n 'SYSMAN_MDS', 'SYSMAN_OPSS', 'SYSMAN_STB', 'PUBLIC',\n 'DBSNMP', 'SYSMAN', 'APEX_040200', 'WMSYS',\n 'SYSDG', 'SYSBACKUP', 'SPATIAL_WFS_ADMIN_USR',\n 'SPATIAL_CSW_ADMIN_US',\n 'SI_INFORMTN_SCHEMA', 'OUTLN', 'ORDSYS', 'ORDDATA',\n 'OJVMSYS', 'ORACLE_OCM', 'MDSYS', 'ORDPLUGINS',\n 'GSMADMIN_INTERNAL', 'FLOWS_FILES', 'DIP', 'CTXSYS',\n 'AUDSYS', 'APPQOSSYS', 'APEX_PUBLIC_USER', 'ANONYMOUS',\n 'SPATIAL_CSW_ADMIN_USR', 'SYSKM', 'SYSMAN_TYPES',\n 'MGMT_VIEW', 'EUS_ENGINE_USER', 'GSMCATUSER', 'OLAPSYS',\n 'CLOUD_SWLIB_USER', 'GSMUSER', 'MDDATA', 'XS$NULL',\n 'CLOUD_ENGINE_USER'\n )\n UNION\n SELECT\n 'User '\n || grantee\n || ' is directly granted '\n || privilege\n || ' privilege ' value\n FROM dba_sys_privs\n WHERE grantee NOT IN (SELECT role FROM dba_roles)\n AND privilege NOT IN\n (\n 'CREATE SEQUENCE',\n 'CREATE TRIGGER',\n 'CREATE CLUSTER',\n 'CREATE INDEXTYPE',\n 'CREATE PROCEDURE',\n 'CREATE TYPE',\n 'CREATE SESSION',\n 'CREATE OPERATOR',\n 'CREATE TABLE',\n 'UNLIMITED TABLESPACE' )\n AND grantee NOT IN\n (\n 'XDB', 'SYSTEM', 'SYS', 'LBACSYS',\n 'DVSYS', 'DVF', 'SYSMAN_RO', 'SYSMAN_BIPLATFORM',\n 'SYSMAN_MDS', 'SYSMAN_OPSS', 'SYSMAN_STB', 'PUBLIC',\n 'DBSNMP', 'SYSMAN', 'APEX_040200', 'WMSYS',\n 'SYSDG', 'SYSBACKUP', 'SPATIAL_WFS_ADMIN_USR',\n 'SPATIAL_CSW_ADMIN_US',\n 'SI_INFORMTN_SCHEMA', 'OUTLN', 'ORDSYS', 'ORDDATA',\n 'OJVMSYS', 'ORACLE_OCM', 'MDSYS', 'ORDPLUGINS',\n 'GSMADMIN_INTERNAL', 'FLOWS_FILES', 'DIP', 'CTXSYS',\n 'AUDSYS', 'APPQOSSYS', 'APEX_PUBLIC_USER', 'ANONYMOUS',\n 'SPATIAL_CSW_ADMIN_USR', 'SYSKM', 'SYSMAN_TYPES',\n 'MGMT_VIEW', 'EUS_ENGINE_USER', 'GSMCATUSER', 'OLAPSYS',\n 'CLOUD_SWLIB_USER',\n 'GSMUSER', 'MDDATA', 'XS$NULL', 'CLOUD_ENGINE_USER'\n )\n UNION\n SELECT\n 'User '\n || username\n || ' is granted '\n || privilege\n || ' privilege via role '\n || rp.granted_role value\n FROM dba_users u,\n dba_role_privs rp,\n dba_sys_privs sp\n WHERE username = rp.grantee\n AND rp.granted_role = sp.grantee\n AND privilege NOT IN\n (\n 'CREATE SEQUENCE',\n 'CREATE TRIGGER',\n 'SET CONTAINER',\n 'CREATE CLUSTER',\n 'CREATE PROCEDURE',\n 'CREATE TYPE',\n 'CREATE SESSION',\n 'CREATE OPERATOR',\n 'CREATE TABLE',\n 'CREATE INDEXTYPE'\n )\n AND username NOT IN\n (\n 'XDB', 'SYSTEM', 'SYS', 'LBACSYS',\n 'DVSYS', 'DVF', 'SYSMAN_RO', 'SYSMAN_BIPLATFORM',\n 'SYSMAN_MDS', 'SYSMAN_OPSS', 'SYSMAN_STB', 'DBSNMP',\n 'SYSMAN', 'APEX_040200', 'WMSYS', 'SYSDG',\n 'SYSBACKUP', 'SPATIAL_WFS_ADMIN_USR',\n 'SPATIAL_CSW_ADMIN_US','GSMCATUSER',\n 'OLAPSYS', 'SI_INFORMTN_SCHEMA', 'OUTLN', 'ORDSYS',\n 'ORDDATA', 'OJVMSYS', 'ORACLE_OCM', 'MDSYS',\n 'ORDPLUGINS', 'GSMADMIN_INTERNAL', 'MDDATA',\n 'FLOWS_FILES', 'DIP', 'CTXSYS', 'AUDSYS', 'APPQOSSYS',\n 'APEX_PUBLIC_USER', 'ANONYMOUS',\n 'SPATIAL_CSW_ADMIN_USR','SYSKM',\n 'SYSMAN_TYPES', 'MGMT_VIEW', 'EUS_ENGINE_USER',\n 'EXFSYS','SYSMAN_APM' )\n AND rp.granted_role NOT IN\n (\n 'EXP_FULL_DATABASE','AQ_ADMINISTRATOR_ROLE','DV_REALM_RESOURCE',\n 'DBA','CDB_DBA','OEM_ADVISOR','RECOVERY_CATALOG_OWNER',\n 'EM_EXPRESS_ALL','SCHEDULER_ADMIN','OLAP_USER',\n 'RESOURCE','EM_EXPRESS_BASIC','IMP_FULL_DATABASE','CONNECT',\n 'AUDIT_ADMIN','DATAPUMP_EXP_FULL_DATABASE','GSMADMIN_ROLE',\n 'DV_REALM_OWNER','OLAP_DBA','JAVADEBUGPRIV',\n 'DATAPUMP_IMP_FULL_DATABASE','OEM_MONITOR',\n 'APEX_GRANTS_FOR_NEW_USERS_ROLE'\n )\n UNION\n\n SELECT\n 'User '\n ||grantee\n ||' is granted '\n ||privilege\n ||' on '\n ||owner\n ||'.'\n ||table_name\n ||'.'\n ||column_name\n ||' by '\n ||grantor\n FROM dba_col_privs\n WHERE grantee NOT IN\n (\n 'XDB', 'SYSTEM', 'SYS', 'LBACSYS',\n 'DVSYS', 'DVF', 'SYSMAN_RO', 'SYSMAN_BIPLATFORM',\n 'SYSMAN_MDS', 'SYSMAN_OPSS', 'SYSMAN_STB', 'DBSNMP',\n 'SYSMAN', 'APEX_040200', 'WMSYS', 'SYSDG',\n 'SYSBACKUP', 'SPATIAL_WFS_ADMIN_USR',\n 'SPATIAL_CSW_ADMIN_US','GSMCATUSER',\n 'OLAPSYS', 'SI_INFORMTN_SCHEMA', 'OUTLN', 'ORDSYS',\n 'ORDDATA', 'OJVMSYS', 'ORACLE_OCM', 'MDSYS',\n 'ORDPLUGINS', 'GSMADMIN_INTERNAL', 'MDDATA',\n 'FLOWS_FILES', 'IMP_FULL_DATABASE',\n 'DIP', 'CTXSYS', 'AUDSYS', 'APPQOSSYS',\n 'APEX_PUBLIC_USER', 'ANONYMOUS',\n 'SPATIAL_CSW_ADMIN_USR','SYSKM',\n 'SYSMAN_TYPES', 'MGMT_VIEW', 'EUS_ENGINE_USER',\n 'EXFSYS','SYSMAN_APM'\n )\n ;\n\n (The lists of special accounts that are excluded from this requirement may not\n be complete. It is expected that the DBA will edit the lists to suit local\n circumstances, adding other special accounts as necessary, and removing any\n that are not supposed to be in use in the Oracle deployment that is under\n review. Similarly, the lists of privileges and roles excluded from the\n subqueries may be modified according to circumstances.)", - "fix": "Define DBMS user roles based on privilege and job function\n requirements.\n\n Assign the required privileges to the role, and assign the role to authorized\n DBMS user accounts.\n\n Revoke any privileges directly assigned to DBMS user accounts, and assign them\n to a role the DBMS user already has assigned." + "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-61809' do\n title \"The DBMS must implement separation of duties through assigned\n information access authorizations.\"\n desc \"Separation of duties is a prevalent Information Technology control\n that is implemented at different layers of the information system, including\n the operating system and in applications. It serves to eliminate or reduce the\n possibility that a single user may carry out a prohibited action. Separation of\n duties requires that the person accountable for approving an action is not the\n same person who is tasked with implementing or carrying out that action.\n\n Additionally, the person or entity accountable for monitoring the activity\n must be separate as well. To meet this requirement, applications, when\n applicable, shall be divided where functionality is based on roles and duties.\n Examples of separation of duties include: (i) mission functions and distinct\n information system support functions are divided among different\n individuals/roles; (ii) different individuals perform information system\n support functions (e.g., system management, systems programming, configuration\n management, quality assurance and testing, network security); (iii) security\n personnel who administer access control functions do not administer audit\n functions; and (iv) different administrator accounts for different roles.\n\n Privileges granted outside the context of the application user job function\n are more likely to go unmanaged or without oversight for authorization.\n Maintenance of privileges using roles defined for discrete job functions offers\n improved oversight of application user privilege assignments and helps to\n protect against unauthorized privilege assignment.\n \"\n impact 0.3\n tag \"gtitle\": 'SRG-APP-000062-DB-000009'\n tag \"gid\": 'V-61809'\n tag \"rid\": 'SV-76299r3_rule'\n tag \"stig_id\": 'O121-C3-003300'\n tag \"fix_id\": 'F-67725r1_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\": \"Obtain a list of privileges assigned to the DBMS user accounts.\n If any direct privilege assignments exist that can be assigned to a role, this\n is a finding.\n\n SELECT\n 'User '\n || grantee\n || ' is directly granted '\n || privilege\n || ' privilege on '\n || table_name value\n FROM dba_tab_privs\n WHERE grantee NOT IN (SELECT role FROM dba_roles)\n AND grantee NOT IN\n (\n 'XDB', 'SYSTEM', 'SYS', 'LBACSYS',\n 'DVSYS', 'DVF', 'SYSMAN_RO', 'SYSMAN_BIPLATFORM',\n 'SYSMAN_MDS', 'SYSMAN_OPSS', 'SYSMAN_STB', 'PUBLIC',\n 'DBSNMP', 'SYSMAN', 'APEX_040200', 'WMSYS',\n 'SYSDG', 'SYSBACKUP', 'SPATIAL_WFS_ADMIN_USR',\n 'SPATIAL_CSW_ADMIN_US',\n 'SI_INFORMTN_SCHEMA', 'OUTLN', 'ORDSYS', 'ORDDATA',\n 'OJVMSYS', 'ORACLE_OCM', 'MDSYS', 'ORDPLUGINS',\n 'GSMADMIN_INTERNAL', 'FLOWS_FILES', 'DIP', 'CTXSYS',\n 'AUDSYS', 'APPQOSSYS', 'APEX_PUBLIC_USER', 'ANONYMOUS',\n 'SPATIAL_CSW_ADMIN_USR', 'SYSKM', 'SYSMAN_TYPES',\n 'MGMT_VIEW', 'EUS_ENGINE_USER', 'GSMCATUSER', 'OLAPSYS',\n 'CLOUD_SWLIB_USER', 'GSMUSER', 'MDDATA', 'XS$NULL',\n 'CLOUD_ENGINE_USER'\n )\n UNION\n SELECT\n 'User '\n || grantee\n || ' is directly granted '\n || privilege\n || ' privilege ' value\n FROM dba_sys_privs\n WHERE grantee NOT IN (SELECT role FROM dba_roles)\n AND privilege NOT IN\n (\n 'CREATE SEQUENCE',\n 'CREATE TRIGGER',\n 'CREATE CLUSTER',\n 'CREATE INDEXTYPE',\n 'CREATE PROCEDURE',\n 'CREATE TYPE',\n 'CREATE SESSION',\n 'CREATE OPERATOR',\n 'CREATE TABLE',\n 'UNLIMITED TABLESPACE' )\n AND grantee NOT IN\n (\n 'XDB', 'SYSTEM', 'SYS', 'LBACSYS',\n 'DVSYS', 'DVF', 'SYSMAN_RO', 'SYSMAN_BIPLATFORM',\n 'SYSMAN_MDS', 'SYSMAN_OPSS', 'SYSMAN_STB', 'PUBLIC',\n 'DBSNMP', 'SYSMAN', 'APEX_040200', 'WMSYS',\n 'SYSDG', 'SYSBACKUP', 'SPATIAL_WFS_ADMIN_USR',\n 'SPATIAL_CSW_ADMIN_US',\n 'SI_INFORMTN_SCHEMA', 'OUTLN', 'ORDSYS', 'ORDDATA',\n 'OJVMSYS', 'ORACLE_OCM', 'MDSYS', 'ORDPLUGINS',\n 'GSMADMIN_INTERNAL', 'FLOWS_FILES', 'DIP', 'CTXSYS',\n 'AUDSYS', 'APPQOSSYS', 'APEX_PUBLIC_USER', 'ANONYMOUS',\n 'SPATIAL_CSW_ADMIN_USR', 'SYSKM', 'SYSMAN_TYPES',\n 'MGMT_VIEW', 'EUS_ENGINE_USER', 'GSMCATUSER', 'OLAPSYS',\n 'CLOUD_SWLIB_USER',\n 'GSMUSER', 'MDDATA', 'XS$NULL', 'CLOUD_ENGINE_USER'\n )\n UNION\n SELECT\n 'User '\n || username\n || ' is granted '\n || privilege\n || ' privilege via role '\n || rp.granted_role value\n FROM dba_users u,\n dba_role_privs rp,\n dba_sys_privs sp\n WHERE username = rp.grantee\n AND rp.granted_role = sp.grantee\n AND privilege NOT IN\n (\n 'CREATE SEQUENCE',\n 'CREATE TRIGGER',\n 'SET CONTAINER',\n 'CREATE CLUSTER',\n 'CREATE PROCEDURE',\n 'CREATE TYPE',\n 'CREATE SESSION',\n 'CREATE OPERATOR',\n 'CREATE TABLE',\n 'CREATE INDEXTYPE'\n )\n AND username NOT IN\n (\n 'XDB', 'SYSTEM', 'SYS', 'LBACSYS',\n 'DVSYS', 'DVF', 'SYSMAN_RO', 'SYSMAN_BIPLATFORM',\n 'SYSMAN_MDS', 'SYSMAN_OPSS', 'SYSMAN_STB', 'DBSNMP',\n 'SYSMAN', 'APEX_040200', 'WMSYS', 'SYSDG',\n 'SYSBACKUP', 'SPATIAL_WFS_ADMIN_USR',\n 'SPATIAL_CSW_ADMIN_US','GSMCATUSER',\n 'OLAPSYS', 'SI_INFORMTN_SCHEMA', 'OUTLN', 'ORDSYS',\n 'ORDDATA', 'OJVMSYS', 'ORACLE_OCM', 'MDSYS',\n 'ORDPLUGINS', 'GSMADMIN_INTERNAL', 'MDDATA',\n 'FLOWS_FILES', 'DIP', 'CTXSYS', 'AUDSYS', 'APPQOSSYS',\n 'APEX_PUBLIC_USER', 'ANONYMOUS',\n 'SPATIAL_CSW_ADMIN_USR','SYSKM',\n 'SYSMAN_TYPES', 'MGMT_VIEW', 'EUS_ENGINE_USER',\n 'EXFSYS','SYSMAN_APM' )\n AND rp.granted_role NOT IN\n (\n 'EXP_FULL_DATABASE','AQ_ADMINISTRATOR_ROLE','DV_REALM_RESOURCE',\n 'DBA','CDB_DBA','OEM_ADVISOR','RECOVERY_CATALOG_OWNER',\n 'EM_EXPRESS_ALL','SCHEDULER_ADMIN','OLAP_USER',\n 'RESOURCE','EM_EXPRESS_BASIC','IMP_FULL_DATABASE','CONNECT',\n 'AUDIT_ADMIN','DATAPUMP_EXP_FULL_DATABASE','GSMADMIN_ROLE',\n 'DV_REALM_OWNER','OLAP_DBA','JAVADEBUGPRIV',\n 'DATAPUMP_IMP_FULL_DATABASE','OEM_MONITOR',\n 'APEX_GRANTS_FOR_NEW_USERS_ROLE'\n )\n UNION\n\n SELECT\n 'User '\n ||grantee\n ||' is granted '\n ||privilege\n ||' on '\n ||owner\n ||'.'\n ||table_name\n ||'.'\n ||column_name\n ||' by '\n ||grantor\n FROM dba_col_privs\n WHERE grantee NOT IN\n (\n 'XDB', 'SYSTEM', 'SYS', 'LBACSYS',\n 'DVSYS', 'DVF', 'SYSMAN_RO', 'SYSMAN_BIPLATFORM',\n 'SYSMAN_MDS', 'SYSMAN_OPSS', 'SYSMAN_STB', 'DBSNMP',\n 'SYSMAN', 'APEX_040200', 'WMSYS', 'SYSDG',\n 'SYSBACKUP', 'SPATIAL_WFS_ADMIN_USR',\n 'SPATIAL_CSW_ADMIN_US','GSMCATUSER',\n 'OLAPSYS', 'SI_INFORMTN_SCHEMA', 'OUTLN', 'ORDSYS',\n 'ORDDATA', 'OJVMSYS', 'ORACLE_OCM', 'MDSYS',\n 'ORDPLUGINS', 'GSMADMIN_INTERNAL', 'MDDATA',\n 'FLOWS_FILES', 'IMP_FULL_DATABASE',\n 'DIP', 'CTXSYS', 'AUDSYS', 'APPQOSSYS',\n 'APEX_PUBLIC_USER', 'ANONYMOUS',\n 'SPATIAL_CSW_ADMIN_USR','SYSKM',\n 'SYSMAN_TYPES', 'MGMT_VIEW', 'EUS_ENGINE_USER',\n 'EXFSYS','SYSMAN_APM'\n )\n ;\n\n (The lists of special accounts that are excluded from this requirement may not\n be complete. It is expected that the DBA will edit the lists to suit local\n circumstances, adding other special accounts as necessary, and removing any\n that are not supposed to be in use in the Oracle deployment that is under\n review. Similarly, the lists of privileges and roles excluded from the\n subqueries may be modified according to circumstances.)\"\n tag \"fix\": \"Define DBMS user roles based on privilege and job function\n requirements.\n\n Assign the required privileges to the role, and assign the role to authorized\n DBMS user accounts.\n\n Revoke any privileges directly assigned to DBMS user accounts, and assign them\n to a role the DBMS user already has assigned.\"\n describe 'A manual review is required to ensure the DBMS implements separation of duties through assigned\n information access authorizations' do\n skip 'A manual review is required to ensure the DBMS implements separation of duties through assigned\n information access authorizations'\n end\nend\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-61809.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61493.rb", "line": 1 }, - "id": "V-61809" + "id": "V-61493" }, { - "title": "The DBMS must ensure remote sessions that access an\n organization-defined list of security functions and security-relevant\n information are audited.", - "desc": "Remote access is any access to an organizational information system by\n a user (or an information system) communicating through an external,\n non-organization-controlled network (e.g., the Internet). Examples of remote\n access methods include dial-up, broadband, and wireless.\n\n Remote network and system access is accomplished by leveraging common\n communication protocols to establish a remote connection. These connections\n will typically originate over either the public Internet or the Public Switched\n Telephone Network (PSTN). Neither of these internetworking mechanisms is\n private or secure and they do not by default restrict access to networked\n resources once connectivity is established.\n\n Numerous best practices are employed to protect remote connections, such as\n utilizing encryption to protect data sessions and firewalls to restrict and\n control network connectivity. In addition to these protections, auditing must\n also be utilized in order to track system activity, assist in diagnosing system\n issues, and provide evidence needed for forensic investigations after a\n security incident.\n\n When organizations define security-related application functions or\n security-related application information, it is incumbent upon the application\n providing access to that data to ensure auditing of remote connectivity to\n those resources occurs in support of organizational requirements\n\n Remote access to security functions (e.g., user management, audit log\n management, etc.) and security-relevant information requires the activity be\n audited by the organization. Any application providing remote access must\n support organizational requirements to audit access or organization-defined\n security functions and security-relevant information.\n\n Database security features accessed through remote methods must be audited\n to ensure the access is authorized and appropriate.", + "title": "The system must employ automated mechanisms for supporting Oracle user\n account management.", + "desc": "A comprehensive application account management process that includes\n automation helps to ensure accounts designated as requiring attention are\n consistently and promptly addressed. Examples include, but are not limited to,\n using automation to take action on multiple accounts designated as inactive,\n suspended, or terminated, or by disabling accounts located in non-centralized\n account stores, such as multiple servers.\n\n Enterprise environments make application user account management\n challenging and complex. A user management process requiring administrators to\n manually address account management functions adds risk of potential oversight.\n\n Automated mechanisms may be comprised of differing technologies that when\n placed together contain an overall automated mechanism supporting an\n organization's automated account management requirements.\n\n Databases can have large numbers of users in disparate locations and job\n functions. Automatic account management can help mitigate the risk of human\n error found in manually managing database access.\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": "Remote access is any access to an organizational information system by\n a user (or an information system) communicating through an external,\n non-organization-controlled network (e.g., the Internet). Examples of remote\n access methods include dial-up, broadband, and wireless.\n\n Remote network and system access is accomplished by leveraging common\n communication protocols to establish a remote connection. These connections\n will typically originate over either the public Internet or the Public Switched\n Telephone Network (PSTN). Neither of these internetworking mechanisms is\n private or secure and they do not by default restrict access to networked\n resources once connectivity is established.\n\n Numerous best practices are employed to protect remote connections, such as\n utilizing encryption to protect data sessions and firewalls to restrict and\n control network connectivity. In addition to these protections, auditing must\n also be utilized in order to track system activity, assist in diagnosing system\n issues, and provide evidence needed for forensic investigations after a\n security incident.\n\n When organizations define security-related application functions or\n security-related application information, it is incumbent upon the application\n providing access to that data to ensure auditing of remote connectivity to\n those resources occurs in support of organizational requirements\n\n Remote access to security functions (e.g., user management, audit log\n management, etc.) and security-relevant information requires the activity be\n audited by the organization. Any application providing remote access must\n support organizational requirements to audit access or organization-defined\n security functions and security-relevant information.\n\n Database security features accessed through remote methods must be audited\n to ensure the access is authorized and appropriate." + "default": "A comprehensive application account management process that includes\n automation helps to ensure accounts designated as requiring attention are\n consistently and promptly addressed. Examples include, but are not limited to,\n using automation to take action on multiple accounts designated as inactive,\n suspended, or terminated, or by disabling accounts located in non-centralized\n account stores, such as multiple servers.\n\n Enterprise environments make application user account management\n challenging and complex. A user management process requiring administrators to\n manually address account management functions adds risk of potential oversight.\n\n Automated mechanisms may be comprised of differing technologies that when\n placed together contain an overall automated mechanism supporting an\n organization's automated account management requirements.\n\n Databases can have large numbers of users in disparate locations and job\n functions. Automatic account management can help mitigate the risk of human\n error found in manually managing database access.\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": [], "tags": { - "gtitle": "SRG-APP-000019-DB-000197", - "gid": "V-61553", - "rid": "SV-76043r1_rule", - "stig_id": "O121-C2-001600", - "fix_id": "F-67469r1_fix", + "gtitle": "SRG-APP-000023-DB-000001", + "gid": "V-61557", + "rid": "SV-76047r2_rule", + "stig_id": "O121-C2-001800", + "fix_id": "F-67473r2_fix", "cci": [ - "CCI-002186" + "CCI-000015" ], "nist": [ - "AC-3 (10)", + "AC-2 (1)", "Rev_4" ], "false_negatives": null, @@ -556,35 +559,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Verify, using vendor and system documentation if necessary,\n that the DBMS is configured to use Oracle's auditing features, or that a\n third-party product or custom code is deployed and configured to satisfy this\n requirement.\n\n If a third-party product or custom code is used, compare its current\n configuration with the audit requirements. If any of the requirements is not\n covered by the configuration, this is a finding.\n\n The remainder of this Check is applicable specifically where Oracle auditing is\n in use.\n\n If Standard Auditing is used:\n To see if Oracle is configured to capture audit data, enter the following\n SQL*Plus command:\n SHOW PARAMETER AUDIT_TRAIL\n or the following SQL query:\n SELECT * FROM SYS V$PARAMETER WHERE NAME = 'audit_trail';\n select value from v$parameter where name='audit_trail';\n If Oracle returns the value 'NONE', this is a finding.\n\n To confirm that Oracle audit is capturing information on the required events,\n review the contents of the SYS.AUD$ table or the audit file, whichever is in\n use. If auditable events are not listed, this is a finding.\n\n If Unified Auditing is used:\n To see if Oracle is configured to capture audit data, enter the following\n SQL*Plus command:\n SELECT * FROM V$OPTION WHERE PARAMETER = 'Unified Auditing';\n If Oracle returns the value 'TRUE', this is not a finding.\n\n To confirm that Oracle audit is capturing information on the required events,\n review the contents of the SYS.UNIFIED_AUDIT_TRAIL view. If auditable events\n are not listed, this is a finding.", - "fix": "Configure the DBMS's auditing to audit organization-defined\n auditable events. If preferred, use a third-party tool. The tool must provide\n the minimum capability to audit the required events.\n\n If using a third-party product, proceed in accordance with the product\n documentation. If using Oracle's capabilities, proceed as follows.\n\n If Standard Auditing is used:\n Use this process to ensure auditable events are captured:\n ALTER SYSTEM SET AUDIT_TRAIL= SCOPE=SPFILE;\n Audit trail type can be 'OS', 'DB', 'DB,EXTENDED', 'XML' or 'XML,EXTENDED'.\n After executing this statement, it may be necessary to shut down and restart\n the Oracle database.\n\n If the site-specific audit requirements are not covered by the default audit\n options, deploy and configure Fine-Grained Auditing. For details, refer to\n Oracle documentation at the locations below.\n\n If Unified Auditing is used:\n Use this process to ensure auditable events are captured:\n Link the oracle binary with uniaud_on, and then restart the database. Oracle\n Database Upgrade Guide describes how to enable unified auditing.\n\n For more information on the configuration of auditing, refer to the following\n documents:\n \"Auditing Database Activity\" in the Oracle Database 2 Day + Security Guide:\n http://docs.oracle.com/database/121/TDPSG/tdpsg_auditing.htm#TDPSG50000\n \"Monitoring Database Activity with Auditing\" in the Oracle Database Security\n Guide:\n http://docs.oracle.com/database/121/DBSEG/part_6.htm#CCHEHCGI\n \"DBMS_AUDIT_MGMT\" in the Oracle Database PL/SQL Packages and Types Reference:\n http://docs.oracle.com/database/121/ARPLS/d_audit_mgmt.htm#ARPLS241\n Oracle Database Upgrade Guide:\n http://docs.oracle.com/database/121/UPGRD/afterup.htm#UPGRD52810\n\n If the site-specific audit requirements are not covered by the default audit\n options, deploy and configure Fine-Grained Auditing. For details, refer to\n Oracle documentation at the locations above." + "check": "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 If an Oracle feature/product, an OS feature, a third-party product, or custom\n code is used to automate account management, this is not a finding.\n\n Determine what the site-defined definition of an acceptably small level of\n manual account-management activity is. If the site has established the\n definition, documented it, and obtained ISSO-ISSM-AO approval, use that\n definition. If not, use the following rule of thumb as the definition: no\n more than 12 such accounts exist or are expected to exist; no more than 100\n manual account-management actions (account creation, modification, locking,\n unlocking, removal and the like) are expected to occur in the course of a year.\n\n If the amount of account management activity is small, as defined in the\n preceding paragraph, this is not a finding.\n\n Otherwise, this is a finding.", + "fix": "Utilize an Oracle feature/product, an OS feature, a third-party\n product, or custom code to automate some or all account maintenance\n functionality.\n\n - - - - -\n\n Roles and Profiles are two Oracle features that should be employed in account\n management. (Indeed, other requirements mandate the use of Roles.) Following\n are some notes from Oracle on the use of Profiles.\n\n A profile is a named set of resource limits and password parameters that\n restrict database usage and instance resources for a user. You can assign a\n profile to each user, and a default profile to all others. Each user can have\n only one profile, and creating a new one supersedes any earlier one.\n\n Profile resource limits are enforced only when you enable resource limitation\n for the associated database. Enabling such limitation can occur either before\n starting up the database (the RESOURCE_LIMIT initialization parameter) or while\n it is open (using an ALTER SYSTEM statement).\n\n While password parameters reside in profiles, they are unaffected by\n RESOURCE_LIMIT or ALTER SYSTEM and password management is always enabled." }, - "code": "control 'V-61553' do\n title \"The DBMS must ensure remote sessions that access an\n organization-defined list of security functions and security-relevant\n information are audited.\"\n desc \"Remote access is any access to an organizational information system by\n a user (or an information system) communicating through an external,\n non-organization-controlled network (e.g., the Internet). Examples of remote\n access methods include dial-up, broadband, and wireless.\n\n Remote network and system access is accomplished by leveraging common\n communication protocols to establish a remote connection. These connections\n will typically originate over either the public Internet or the Public Switched\n Telephone Network (PSTN). Neither of these internetworking mechanisms is\n private or secure and they do not by default restrict access to networked\n resources once connectivity is established.\n\n Numerous best practices are employed to protect remote connections, such as\n utilizing encryption to protect data sessions and firewalls to restrict and\n control network connectivity. In addition to these protections, auditing must\n also be utilized in order to track system activity, assist in diagnosing system\n issues, and provide evidence needed for forensic investigations after a\n security incident.\n\n When organizations define security-related application functions or\n security-related application information, it is incumbent upon the application\n providing access to that data to ensure auditing of remote connectivity to\n those resources occurs in support of organizational requirements\n\n Remote access to security functions (e.g., user management, audit log\n management, etc.) and security-relevant information requires the activity be\n audited by the organization. Any application providing remote access must\n support organizational requirements to audit access or organization-defined\n security functions and security-relevant information.\n\n Database security features accessed through remote methods must be audited\n to ensure the access is authorized and appropriate.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000019-DB-000197'\n tag \"gid\": 'V-61553'\n tag \"rid\": 'SV-76043r1_rule'\n tag \"stig_id\": 'O121-C2-001600'\n tag \"fix_id\": 'F-67469r1_fix'\n tag \"cci\": ['CCI-002186']\n tag \"nist\": ['AC-3 (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\": \"Verify, using vendor and system documentation if necessary,\n that the DBMS is configured to use Oracle's auditing features, or that a\n third-party product or custom code is deployed and configured to satisfy this\n requirement.\n\n If a third-party product or custom code is used, compare its current\n configuration with the audit requirements. If any of the requirements is not\n covered by the configuration, this is a finding.\n\n The remainder of this Check is applicable specifically where Oracle auditing is\n in use.\n\n If Standard Auditing is used:\n To see if Oracle is configured to capture audit data, enter the following\n SQL*Plus command:\n SHOW PARAMETER AUDIT_TRAIL\n or the following SQL query:\n SELECT * FROM SYS V$PARAMETER WHERE NAME = 'audit_trail';\n select value from v$parameter where name='audit_trail';\n If Oracle returns the value 'NONE', this is a finding.\n\n To confirm that Oracle audit is capturing information on the required events,\n review the contents of the SYS.AUD$ table or the audit file, whichever is in\n use. If auditable events are not listed, this is a finding.\n\n If Unified Auditing is used:\n To see if Oracle is configured to capture audit data, enter the following\n SQL*Plus command:\n SELECT * FROM V$OPTION WHERE PARAMETER = 'Unified Auditing';\n If Oracle returns the value 'TRUE', this is not a finding.\n\n To confirm that Oracle audit is capturing information on the required events,\n review the contents of the SYS.UNIFIED_AUDIT_TRAIL view. If auditable events\n are not listed, this is a finding.\"\n tag \"fix\": \"Configure the DBMS's auditing to audit organization-defined\n auditable events. If preferred, use a third-party tool. The tool must provide\n the minimum capability to audit the required events.\n\n If using a third-party product, proceed in accordance with the product\n documentation. If using Oracle's capabilities, proceed as follows.\n\n If Standard Auditing is used:\n Use this process to ensure auditable events are captured:\n ALTER SYSTEM SET AUDIT_TRAIL= SCOPE=SPFILE;\n Audit trail type can be 'OS', 'DB', 'DB,EXTENDED', 'XML' or 'XML,EXTENDED'.\n After executing this statement, it may be necessary to shut down and restart\n the Oracle database.\n\n If the site-specific audit requirements are not covered by the default audit\n options, deploy and configure Fine-Grained Auditing. For details, refer to\n Oracle documentation at the locations below.\n\n If Unified Auditing is used:\n Use this process to ensure auditable events are captured:\n Link the oracle binary with uniaud_on, and then restart the database. Oracle\n Database Upgrade Guide describes how to enable unified auditing.\n\n For more information on the configuration of auditing, refer to the following\n documents:\n \\\"Auditing Database Activity\\\" in the Oracle Database 2 Day + Security Guide:\n http://docs.oracle.com/database/121/TDPSG/tdpsg_auditing.htm#TDPSG50000\n \\\"Monitoring Database Activity with Auditing\\\" in the Oracle Database Security\n Guide:\n http://docs.oracle.com/database/121/DBSEG/part_6.htm#CCHEHCGI\n \\\"DBMS_AUDIT_MGMT\\\" in the Oracle Database PL/SQL Packages and Types Reference:\n http://docs.oracle.com/database/121/ARPLS/d_audit_mgmt.htm#ARPLS241\n Oracle Database Upgrade Guide:\n http://docs.oracle.com/database/121/UPGRD/afterup.htm#UPGRD52810\n\n If the site-specific audit requirements are not covered by the default audit\n options, deploy and configure Fine-Grained Auditing. For details, refer to\n Oracle documentation at the locations above.\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n standard_auditing_used = input('standard_auditing_used')\n unified_auditing_used = input('unified_auditing_used')\n\n describe.one do\n describe 'Standard auditing is in use for audit purposes' do\n subject { standard_auditing_used }\n it { should be true }\n end\n\n describe 'Unified auditing is in use for audit purposes' do\n subject { unified_auditing_used }\n it { should be true }\n end\n end\n\n audit_trail = sql.query(\"select value from v$parameter where name = 'audit_trail';\").column('value')\n audit_info_captured = sql.query('SELECT EVENT_TIMESTAMP FROM UNIFIED_AUDIT_TRAIL ORDER BY EVENT_TIMESTAMP DESC FETCH FIRST 10 ROWS ONLY;').column('event_timestamp')\n\n if standard_auditing_used\n describe 'The oracle database audit_trail parameter' do\n subject { audit_trail }\n it { should_not cmp 'NONE' }\n end\n end\n\n unified_auditing = sql.query(\"SELECT value FROM V$OPTION WHERE PARAMETER = 'Unified Auditing';\").column('value')\n\n if unified_auditing_used\n describe 'The oracle database unified auditing parameter' do\n subject { unified_auditing }\n it { should_not cmp 'FALSE' }\n end\n\n describe 'The oracle database unified auditing events captured' do\n subject { audit_info_captured }\n it { should_not be_empty }\n end\n\n end\nend\n", + "code": "control 'V-61557' do\n title \"The system must employ automated mechanisms for supporting Oracle user\n account management.\"\n desc \"A comprehensive application account management process that includes\n automation helps to ensure accounts designated as requiring attention are\n consistently and promptly addressed. Examples include, but are not limited to,\n using automation to take action on multiple accounts designated as inactive,\n suspended, or terminated, or by disabling accounts located in non-centralized\n account stores, such as multiple servers.\n\n Enterprise environments make application user account management\n challenging and complex. A user management process requiring administrators to\n manually address account management functions adds risk of potential oversight.\n\n Automated mechanisms may be comprised of differing technologies that when\n placed together contain an overall automated mechanism supporting an\n organization's automated account management requirements.\n\n Databases can have large numbers of users in disparate locations and job\n functions. Automatic account management can help mitigate the risk of human\n error found in manually managing database access.\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-000023-DB-000001'\n tag \"gid\": 'V-61557'\n tag \"rid\": 'SV-76047r2_rule'\n tag \"stig_id\": 'O121-C2-001800'\n tag \"fix_id\": 'F-67473r2_fix'\n tag \"cci\": ['CCI-000015']\n tag \"nist\": ['AC-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\": \"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 If an Oracle feature/product, an OS feature, a third-party product, or custom\n code is used to automate account management, this is not a finding.\n\n Determine what the site-defined definition of an acceptably small level of\n manual account-management activity is. If the site has established the\n definition, documented it, and obtained ISSO-ISSM-AO approval, use that\n definition. If not, use the following rule of thumb as the definition: no\n more than 12 such accounts exist or are expected to exist; no more than 100\n manual account-management actions (account creation, modification, locking,\n unlocking, removal and the like) are expected to occur in the course of a year.\n\n If the amount of account management activity is small, as defined in the\n preceding paragraph, this is not a finding.\n\n Otherwise, this is a finding.\"\n tag \"fix\": \"Utilize an Oracle feature/product, an OS feature, a third-party\n product, or custom code to automate some or all account maintenance\n functionality.\n\n - - - - -\n\n Roles and Profiles are two Oracle features that should be employed in account\n management. (Indeed, other requirements mandate the use of Roles.) Following\n are some notes from Oracle on the use of Profiles.\n\n A profile is a named set of resource limits and password parameters that\n restrict database usage and instance resources for a user. You can assign a\n profile to each user, and a default profile to all others. Each user can have\n only one profile, and creating a new one supersedes any earlier one.\n\n Profile resource limits are enforced only when you enable resource limitation\n for the associated database. Enabling such limitation can occur either before\n starting up the database (the RESOURCE_LIMIT initialization parameter) or while\n it is open (using an ALTER SYSTEM statement).\n\n While password parameters reside in profiles, they are unaffected by\n RESOURCE_LIMIT or ALTER SYSTEM and password management is always enabled.\"\n describe 'A manual review is required to ensure the system must employs automated mechanisms for supporting Oracle user\n account management' do\n skip 'A manual review is required to ensure the system must employs automated mechanisms for supporting Oracle user\n account management'\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61553.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61557.rb", "line": 1 }, - "id": "V-61553" + "id": "V-61557" }, { - "title": "The system must provide an audit log reduction capability.", - "desc": "Audit reduction is used to reduce the volume of audit records in order\n to facilitate manual review. Before a security review, information systems\n and/or applications with an audit reduction capability may remove many audit\n records known to have 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. Audit\n reduction does not alter original audit records.\n\n An audit reduction capability provides support for near real-time audit\n review and analysis requirements and after-the-fact investigations of security\n incidents.\n\n The lack of audit reduction in a database can require the DBA, or others\n responsible for reviewing audit logs, to sort through large amounts of data in\n order to find relevant records. This can cause important audit records to be\n missed.", + "title": "Disk space used by audit trail(s) must be monitored; audit records\n must be regularly or continuously off-loaded to a centralized log management\n system.", + "desc": "It is critical when a system is at risk of failing to process audit\n logs as required; it detects and takes action to mitigate the failure. Audit\n processing failures include: software/hardware errors, failures in the audit\n capturing mechanisms, and audit storage capacity being reached or exceeded.\n Applications are required to be capable of either directly performing or\n calling system-level functionality performing defined actions upon detection of\n an application audit log processing failure.\n\n The Security Requirements Guide says, \"A failure of database auditing will\n result in either the database continuing to function without auditing or in a\n complete halt to database operations. The database must be capable of taking\n organization-defined actions to avoid either a complete halt to processing or\n processing transactions in an unaudited manner.\"\n\n This STIG requirement mandates the implementation of a method to mitigate\n Oracle's inability to automatically reuse audit trail space on a first-in,\n first-out basis.", "descriptions": { - "default": "Audit reduction is used to reduce the volume of audit records in order\n to facilitate manual review. Before a security review, information systems\n and/or applications with an audit reduction capability may remove many audit\n records known to have 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. Audit\n reduction does not alter original audit records.\n\n An audit reduction capability provides support for near real-time audit\n review and analysis requirements and after-the-fact investigations of security\n incidents.\n\n The lack of audit reduction in a database can require the DBA, or others\n responsible for reviewing audit logs, to sort through large amounts of data in\n order to find relevant records. This can cause important audit records to be\n missed." + "default": "It is critical when a system is at risk of failing to process audit\n logs as required; it detects and takes action to mitigate the failure. Audit\n processing failures include: software/hardware errors, failures in the audit\n capturing mechanisms, and audit storage capacity being reached or exceeded.\n Applications are required to be capable of either directly performing or\n calling system-level functionality performing defined actions upon detection of\n an application audit log processing failure.\n\n The Security Requirements Guide says, \"A failure of database auditing will\n result in either the database continuing to function without auditing or in a\n complete halt to database operations. The database must be capable of taking\n organization-defined actions to avoid either a complete halt to processing or\n processing transactions in an unaudited manner.\"\n\n This STIG requirement mandates the implementation of a method to mitigate\n Oracle's inability to automatically reuse audit trail space on a first-in,\n first-out basis." }, - "impact": 0.3, + "impact": 0.5, "refs": [], "tags": { - "gtitle": "SRG-APP-000113-DB-000053", - "gid": "V-61813", - "rid": "SV-76303r1_rule", - "stig_id": "O121-C3-008700", - "fix_id": "F-67729r1_fix", + "gtitle": "SRG-APP-000109-DB-000049", + "gid": "V-61853", + "rid": "SV-76343r1_rule", + "stig_id": "O121-N2-008601", + "fix_id": "F-67769r1_fix", "cci": [ - "CCI-001875" + "CCI-000366" ], "nist": [ - "AU-7 a", + "CM-6 b", "Rev_4" ], "false_negatives": null, @@ -597,39 +600,35 @@ "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.\n\n If this capability has not been implemented, this is a finding.", - "fix": "Deploy software capable of performing audit data reduction." + "check": "Review the procedures, manual and/or automated, for monitoring\n the space used by audit trail(s) and for off-loading audit records to a\n centralized log management system.\n\n If the procedures do not exist, this is a finding.\n\n If the procedures exist, request evidence that they are followed. If the\n evidence indicates that the procedures are not followed, this is a finding.\n\n If the procedures exist, inquire if the system has ever run out of audit trail\n space in the last two years or since the last system upgrade, whichever is more\n recent. If it has run out of space in this period, and the procedures have not\n been updated to compensate, this is a finding.", + "fix": "Modify DBMS, OS, or third-party logging application settings to\n alert appropriate personnel when a specific percentage of log storage capacity\n is reached.\n\n For ease of management, it is recommended that the audit tables be kept in a\n dedicated tablespace.\n\n If Oracle Enterprise Manager is in use, the capability to issue such an alert\n is built in and configurable via the console so an email can be sent to a\n designated administrator.\n\n If Enterprise Manager is unavailable, the following script can be used to\n monitor storage space; this can be combined with additional code to email the\n appropriate administrator so they can take action.\n\n sqlplus connect as sysdba\n\n set pagesize 300\n set linesize 120\n column sumb format 9,999,999,999,999\n column extents format 999999\n column bytes format 9,999,999,999,999\n column largest format 9,999,999,999,999\n column Tot_Size format 9,999,999,999,999\n column Tot_Free format 9,999,999,999,999\n column Pct_Free format 9,999,999,999,999\n column Chunks_Free format 9,999,999,999,999\n column Max_Free format 9,999,999,999,999\n set echo off\n spool TSINFO.txt\n PROMPT SPACE AVAILABLE IN TABLESPACES\n select a.tablespace_name,sum(a.tots) Tot_Size,\n sum(a.sumb) Tot_Free,\n sum(a.sumb)*100/sum(a.tots) Pct_Free,\n sum(a.largest) Max_Free,sum(a.chunks) Chunks_Free\n from\n (\n select tablespace_name,0 tots,sum(bytes) sumb,\n max(bytes) largest,count(*) chunks\n from dba_free_space a\n group by tablespace_name\n union\n select tablespace_name,sum(bytes) tots,0,0,0 from\n dba_data_files\n group by tablespace_name) a\n group by a.tablespace_name;\n\n Sample Output\n\n SPACE AVAILABLE IN TABLESPACES\n\n TABLESPACE_NAME TOT_SIZE TOT_FREE PCT_FREE\n MAX_FREE CHUNKS_FREE\n ------------------------------ ------------ ------------ ------------\n ------------ ------------\n DES2 41,943,040 30,935,040 74\n 30,935,040 1\n DES2_I 31,457,280 23,396,352 74\n 23,396,352 1\n RBS 60,817,408 57,085,952 94\n 52,426,752 16\n SYSTEM 94,371,840 5,386,240 6\n 5,013,504 3\n TEMP 563,200 561,152 100\n 133,120 5\n TOOLS 120,586,240 89,407,488 74\n 78,190,592 12\n USERS 1,048,576 26,624 3\n 26,624 1" }, - "code": "control 'V-61813' do\n title 'The system must provide an audit log reduction capability.'\n desc \"Audit reduction is used to reduce the volume of audit records in order\n to facilitate manual review. Before a security review, information systems\n and/or applications with an audit reduction capability may remove many audit\n records known to have 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. Audit\n reduction does not alter original audit records.\n\n An audit reduction capability provides support for near real-time audit\n review and analysis requirements and after-the-fact investigations of security\n incidents.\n\n The lack of audit reduction in a database can require the DBA, or others\n responsible for reviewing audit logs, to sort through large amounts of data in\n order to find relevant records. This can cause important audit records to be\n missed.\n \"\n impact 0.3\n tag \"gtitle\": 'SRG-APP-000113-DB-000053'\n tag \"gid\": 'V-61813'\n tag \"rid\": 'SV-76303r1_rule'\n tag \"stig_id\": 'O121-C3-008700'\n tag \"fix_id\": 'F-67729r1_fix'\n tag \"cci\": ['CCI-001875']\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.\n\n If this capability has not been implemented, this is a finding.\"\n tag \"fix\": 'Deploy software capable of performing audit data reduction.'\n describe 'A manual review is required to ensure the system provides an audit log reduction capability' do\n skip 'A manual review is required to ensure the system provides an audit log reduction capability'\n end\nend\n", + "code": "control 'V-61853' do\n title \"Disk space used by audit trail(s) must be monitored; audit records\n must be regularly or continuously off-loaded to a centralized log management\n system.\"\n desc \"It is critical when a system is at risk of failing to process audit\n logs as required; it detects and takes action to mitigate the failure. Audit\n processing failures include: software/hardware errors, failures in the audit\n capturing mechanisms, and audit storage capacity being reached or exceeded.\n Applications are required to be capable of either directly performing or\n calling system-level functionality performing defined actions upon detection of\n an application audit log processing failure.\n\n The Security Requirements Guide says, \\\"A failure of database auditing will\n result in either the database continuing to function without auditing or in a\n complete halt to database operations. The database must be capable of taking\n organization-defined actions to avoid either a complete halt to processing or\n processing transactions in an unaudited manner.\\\"\n\n This STIG requirement mandates the implementation of a method to mitigate\n Oracle's inability to automatically reuse audit trail space on a first-in,\n first-out basis.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000109-DB-000049'\n tag \"gid\": 'V-61853'\n tag \"rid\": 'SV-76343r1_rule'\n tag \"stig_id\": 'O121-N2-008601'\n tag \"fix_id\": 'F-67769r1_fix'\n tag \"cci\": ['CCI-000366']\n tag \"nist\": ['CM-6 b', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Review the procedures, manual and/or automated, for monitoring\n the space used by audit trail(s) and for off-loading audit records to a\n centralized log management system.\n\n If the procedures do not exist, this is a finding.\n\n If the procedures exist, request evidence that they are followed. If the\n evidence indicates that the procedures are not followed, this is a finding.\n\n If the procedures exist, inquire if the system has ever run out of audit trail\n space in the last two years or since the last system upgrade, whichever is more\n recent. If it has run out of space in this period, and the procedures have not\n been updated to compensate, this is a finding.\"\n tag \"fix\": \"Modify DBMS, OS, or third-party logging application settings to\n alert appropriate personnel when a specific percentage of log storage capacity\n is reached.\n\n For ease of management, it is recommended that the audit tables be kept in a\n dedicated tablespace.\n\n If Oracle Enterprise Manager is in use, the capability to issue such an alert\n is built in and configurable via the console so an email can be sent to a\n designated administrator.\n\n If Enterprise Manager is unavailable, the following script can be used to\n monitor storage space; this can be combined with additional code to email the\n appropriate administrator so they can take action.\n\n sqlplus connect as sysdba\n\n set pagesize 300\n set linesize 120\n column sumb format 9,999,999,999,999\n column extents format 999999\n column bytes format 9,999,999,999,999\n column largest format 9,999,999,999,999\n column Tot_Size format 9,999,999,999,999\n column Tot_Free format 9,999,999,999,999\n column Pct_Free format 9,999,999,999,999\n column Chunks_Free format 9,999,999,999,999\n column Max_Free format 9,999,999,999,999\n set echo off\n spool TSINFO.txt\n PROMPT SPACE AVAILABLE IN TABLESPACES\n select a.tablespace_name,sum(a.tots) Tot_Size,\n sum(a.sumb) Tot_Free,\n sum(a.sumb)*100/sum(a.tots) Pct_Free,\n sum(a.largest) Max_Free,sum(a.chunks) Chunks_Free\n from\n (\n select tablespace_name,0 tots,sum(bytes) sumb,\n max(bytes) largest,count(*) chunks\n from dba_free_space a\n group by tablespace_name\n union\n select tablespace_name,sum(bytes) tots,0,0,0 from\n dba_data_files\n group by tablespace_name) a\n group by a.tablespace_name;\n\n Sample Output\n\n SPACE AVAILABLE IN TABLESPACES\n\n TABLESPACE_NAME TOT_SIZE TOT_FREE PCT_FREE\n MAX_FREE CHUNKS_FREE\n ------------------------------ ------------ ------------ ------------\n ------------ ------------\n DES2 41,943,040 30,935,040 74\n 30,935,040 1\n DES2_I 31,457,280 23,396,352 74\n 23,396,352 1\n RBS 60,817,408 57,085,952 94\n 52,426,752 16\n SYSTEM 94,371,840 5,386,240 6\n 5,013,504 3\n TEMP 563,200 561,152 100\n 133,120 5\n TOOLS 120,586,240 89,407,488 74\n 78,190,592 12\n USERS 1,048,576 26,624 3\n 26,624 1\"\n describe 'A manual review is required to ensure the Disk space used by audit trail(s) is monitored, and that audit records\n are regularly or continuously off-loaded to a centralized log management system' do\n skip 'A manual review is required to ensure the Disk space used by audit trail(s) is monitored, and that audit records\n are regularly or continuously off-loaded to a centralized log management system'\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61813.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61853.rb", "line": 1 }, - "id": "V-61813" + "id": "V-61853" }, { - "title": "The DBMS must enforce requirements for remote connections to the\n information system.", - "desc": "Applications that provide remote access to information systems must be\n able to enforce remote access policy requirements or work in conjunction with\n enterprise tools designed to enforce policy requirements. Examples of policy\n requirements include, but are not limited to, authorizing remote access to the\n information system, limiting access based on authentication credentials, and\n monitoring for unauthorized access.\n\n If databases allowing remote connections do not enforce requirements for\n remote access, an attacker may gain access to the database and may, through the\n database, gain access to other components of the information system.", + "title": "The DBMS must check the validity of data inputs.", + "desc": "Invalid user input occurs when a user inserts data or characters into\n an application's data entry fields and the application is unprepared to process\n that data. This results in unanticipated application behavior, potentially\n leading to an application or information system compromise. Invalid user input\n is one of the primary methods employed when attempting to compromise an\n application.\n\n All applications need to validate the data users attempt to input to the\n application for processing. Rules for checking the valid syntax and semantics\n of information system inputs (e.g., character set, length, numerical range,\n acceptable values) are in place to verify inputs match specified definitions\n for format and content. Inputs passed to interpreters are prescreened to\n prevent the content from being unintentionally interpreted as commands.\n\n\n This calls for inspection of application source code, which will require\n collaboration with the application developers. It is recognized that in many\n cases, the database administrator (DBA) is organizationally separate from the\n application developers and may have limited, if any, access to source code.\n Nevertheless, protections of this type are so important to the secure operation\n of databases that they must not be ignored. At a minimum, the DBA must attempt\n to obtain assurances from the development organization that this issue has been\n addressed and must document what has been discovered.", "descriptions": { - "default": "Applications that provide remote access to information systems must be\n able to enforce remote access policy requirements or work in conjunction with\n enterprise tools designed to enforce policy requirements. Examples of policy\n requirements include, but are not limited to, authorizing remote access to the\n information system, limiting access based on authentication credentials, and\n monitoring for unauthorized access.\n\n If databases allowing remote connections do not enforce requirements for\n remote access, an attacker may gain access to the database and may, through the\n database, gain access to other components of the information system." + "default": "Invalid user input occurs when a user inserts data or characters into\n an application's data entry fields and the application is unprepared to process\n that data. This results in unanticipated application behavior, potentially\n leading to an application or information system compromise. Invalid user input\n is one of the primary methods employed when attempting to compromise an\n application.\n\n All applications need to validate the data users attempt to input to the\n application for processing. Rules for checking the valid syntax and semantics\n of information system inputs (e.g., character set, length, numerical range,\n acceptable values) are in place to verify inputs match specified definitions\n for format and content. Inputs passed to interpreters are prescreened to\n prevent the content from being unintentionally interpreted as commands.\n\n\n This calls for inspection of application source code, which will require\n collaboration with the application developers. It is recognized that in many\n cases, the database administrator (DBA) is organizationally separate from the\n application developers and may have limited, if any, access to source code.\n Nevertheless, protections of this type are so important to the secure operation\n of databases that they must not be ignored. At a minimum, the DBA must attempt\n to obtain assurances from the development organization that this issue has been\n addressed and must document what has been discovered." }, - "impact": 0, - "refs": [ - { - "ref": [] - } - ], + "impact": 0.5, + "refs": [], "tags": { - "gtitle": "SRG-APP-000140-DB-000033", - "gid": "V-61675", - "rid": "SV-76165r1_rule", - "stig_id": "O121-C2-011400", - "fix_id": "F-67589r1_fix", + "gtitle": "SRG-APP-000251-DB-000160", + "gid": "V-61785", + "rid": "SV-76275r2_rule", + "stig_id": "O121-C2-019500", + "fix_id": "F-67701r1_fix", "cci": [ - "CCI-000366" + "CCI-001310" ], "nist": [ - "CM-6 b", + "SI-10", "Rev_4" ], "false_negatives": null, @@ -642,35 +641,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Review organization's access control policies and procedures\n addressing remote access to the information system.\n\n If remote connections are not allowed by the organization, this is NA. (Note\n that \"remote\" means \"from outside the DoD Information Network (DoDIN)\" and\n that connections via approved Virtual Private Networks (VPNs) are considered to\n be inside the DoDIN.)\n\n Review the DBMS, OS, and/or enterprise account management settings to verify\n access controls and auditing settings exist and they enforce the requirements\n for remote access defined by the organization.\n\n If access controls and auditing do not exist or do not fully enforce the\n requirements defined in the organization's policies and procedures, this is a\n finding.", - "fix": "Configure DBMS settings to ensure access control and auditing\n requirements for remote connections are enforced by the DBMS." + "check": "Review DBMS code, settings, field definitions, constraints, and\n triggers to determine whether or not data being input into the database is\n validated.\n\n If code exists that allows invalid data to be acted upon or input into the\n database, this is a finding.\n\n If field definitions do not exist in the database, this is a finding.\n\n If fields do not contain enabled constraints where required, this is a finding.\n\n - - - - -\n Oracle provides built-in processes to keep data and its integrity intact by\n using constraints.\n\n Integrity Constraint States\n Can specify that a constraint is enabled (ENABLE) or disabled (DISABLE). If a\n constraint is enabled, data is checked as it is entered or updated in the\n database, and data that does not conform to the constraint is prevented from\n being entered. If a constraint is disabled, then data that does not conform can\n be allowed to enter the database.\n\n Additionally, can specify that existing data in the table must conform to the\n constraint (VALIDATE). Conversely, if specified NOVALIDATE, are not ensured\n that existing data conforms.\n\n An integrity constraint defined on a table can be in one of the following\n states:\n ENABLE, VALIDATE\n ENABLE, NOVALIDATE\n DISABLE, VALIDATE\n DISABLE, NOVALIDATE\n\n For details about the meaning of these states and an understanding of their\n consequences, see the Oracle Database SQL Language Reference. Some of these\n consequences are discussed here.\n\n Disabling Constraints\n To enforce the rules defined by integrity constraints, the constraints should\n always be enabled. However, consider temporarily disabling the integrity\n constraints of a table for the following performance reasons:\n\n - When loading large amounts of data into a table\n\n - When performing batch operations that make massive changes to a table (for\n example, changing every employee's number by adding 1000 to the existing number)\n\n - When importing or exporting one table at a time\n\n In all three cases, temporarily disabling integrity constraints can improve the\n performance of the operation, especially in data warehouse configurations.\n\n It is possible to enter data that violates a constraint while that constraint\n is disabled. Thus, always enable the constraint after completing any of the\n operations listed in the preceding bullet list.\n\n Enabling Constraints\n While a constraint is enabled, no row violating the constraint can be inserted\n into the table. However, while the constraint is disabled, such a row can be\n inserted. This row is known as an exception to the constraint. If the\n constraint is in the ENABLE, NOVALIDATE state, violations resulting from data\n entered while the constraint was disabled remain. The rows that violate the\n constraint must be either updated or deleted in order for the constraint to be\n put in the validated state.\n\n Can identify exceptions to a specific integrity constraint while attempting to\n enable the constraint. See \"Reporting Constraint Exceptions\". All rows\n violating constraints are noted in an EXCEPTIONS table, which can be examined.\n\n ENABLE, NOVALIDATE Constraint State\n When a constraint is in the ENABLE, NOVALIDATE state, all subsequent statements\n are checked for conformity to the constraint. However, any existing data in the\n table is not checked. A table with ENABLE, NOVALIDATE constraints can contain\n invalid data, but it is not possible to add new invalid data to it. Constraints\n in the ENABLE, NOVALIDATE state is most useful in data warehouse configurations\n that are uploading valid OLTP data.\n\n Enabling a constraint does not require validation. Enabling a constraint\n novalidate is much faster than enabling and validating a constraint. Also,\n validating a constraint that is already enabled does not require any DML locks\n during validation (unlike validating a previously disabled constraint).\n Enforcement guarantees that no violations are introduced during the validation.\n Hence, enabling without validating reduces the downtime typically associated\n with enabling a constraint.\n\n Efficient Use of Integrity Constraints: A Procedure\n\n Using integrity constraint states in the following order can ensure the best\n benefits:\n Disable state.\n Perform the operation (load, export, import).\n ENABLE, NOVALIDATE state.\n Enable state.\n\n Some benefits of using constraints in this order are:\n No locks are held.\n All constraints can go to enable state concurrently.\n Constraint enabling is done in parallel.\n Concurrent activity on table is permitted.\n\n Setting Integrity Constraints Upon Definition\n When an integrity constraint is defined in a CREATE TABLE or ALTER TABLE\n statement, it can be enabled, disabled, or validated or not validated as\n determined by the specification of the ENABLE/DISABLE clause. If the\n ENABLE/DISABLE clause is not specified in a constraint definition, the database\n automatically enables and validates the constraint.\n\n Disabling Constraints Upon Definition\n The following CREATE TABLE and ALTER TABLE statements both define and disable\n integrity constraints:\n\n CREATE TABLE emp (\n empno NUMBER(5) PRIMARY KEY DISABLE, . . . ;\n\n ALTER TABLE emp\n ADD PRIMARY KEY (empno) DISABLE;\n\n An ALTER TABLE statement that defines and disables an integrity constraint\n never fails because of rows in the table that violate the integrity constraint.\n The definition of the constraint is allowed because its rule is not enforced.\n\n Enabling Constraints Upon Definition\n\n The following CREATE TABLE and ALTER TABLE statements both define and enable\n integrity constraints:\n\n CREATE TABLE emp (\n empno NUMBER(5) CONSTRAINT emp.pk PRIMARY KEY, . . . ;\n\n ALTER TABLE emp\n ADD CONSTRAINT emp.pk PRIMARY KEY (empno);\n\n An ALTER TABLE statement that defines and attempts to enable an integrity\n constraint can fail because rows of the table violate the integrity constraint.\n If this case, the statement is rolled back, and the constraint definition is\n not stored and not enabled.\n\n When enabling a UNIQUE or PRIMARY KEY constraint, an associated index is\n created.", + "fix": "Modify database code to properly validate data before it is put\n into the database or acted upon by the database.\n\n Modify database to contain field definitions for each field in the database.\n\n Modify database to contain constraints on database columns and tables that\n require them for data validity.\n\n Review the application schemas implemented on the system. Check the DDL for\n the tables that are created for the applications to see if constraints have\n been enabled.\n\n - - - - -\n Enabling Constraints Upon Definition\n The following CREATE TABLE and ALTER TABLE statements both define and enable\n integrity constraints:\n CREATE TABLE emp (\n empno NUMBER(5) CONSTRAINT emp.pk PRIMARY KEY, . . . ) ;\n ALTER TABLE emp\n ADD CONSTRAINT emp.pk PRIMARY KEY (empno);\n\n An ALTER TABLE statement that defines and attempts to enable an integrity\n constraint can fail because existing rows of the table violate the integrity\n constraint. In this case, the statement is rolled back, and the constraint\n definition is not stored and not enabled.\n\n When enabling a UNIQUE or PRIMARY KEY constraint, an associated index is\n created." }, - "code": " control 'V-61675' 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-61785' do\n title 'The DBMS must check the validity of data inputs.'\n desc \"Invalid user input occurs when a user inserts data or characters into\n an application's data entry fields and the application is unprepared to process\n that data. This results in unanticipated application behavior, potentially\n leading to an application or information system compromise. Invalid user input\n is one of the primary methods employed when attempting to compromise an\n application.\n\n All applications need to validate the data users attempt to input to the\n application for processing. Rules for checking the valid syntax and semantics\n of information system inputs (e.g., character set, length, numerical range,\n acceptable values) are in place to verify inputs match specified definitions\n for format and content. Inputs passed to interpreters are prescreened to\n prevent the content from being unintentionally interpreted as commands.\n\n\n This calls for inspection of application source code, which will require\n collaboration with the application developers. It is recognized that in many\n cases, the database administrator (DBA) is organizationally separate from the\n application developers and may have limited, if any, access to source code.\n Nevertheless, protections of this type are so important to the secure operation\n of databases that they must not be ignored. At a minimum, the DBA must attempt\n to obtain assurances from the development organization that this issue has been\n addressed and must document what has been discovered.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000251-DB-000160'\n tag \"gid\": 'V-61785'\n tag \"rid\": 'SV-76275r2_rule'\n tag \"stig_id\": 'O121-C2-019500'\n tag \"fix_id\": 'F-67701r1_fix'\n tag \"cci\": ['CCI-001310']\n tag \"nist\": ['SI-10', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Review DBMS code, settings, field definitions, constraints, and\n triggers to determine whether or not data being input into the database is\n validated.\n\n If code exists that allows invalid data to be acted upon or input into the\n database, this is a finding.\n\n If field definitions do not exist in the database, this is a finding.\n\n If fields do not contain enabled constraints where required, this is a finding.\n\n - - - - -\n Oracle provides built-in processes to keep data and its integrity intact by\n using constraints.\n\n Integrity Constraint States\n Can specify that a constraint is enabled (ENABLE) or disabled (DISABLE). If a\n constraint is enabled, data is checked as it is entered or updated in the\n database, and data that does not conform to the constraint is prevented from\n being entered. If a constraint is disabled, then data that does not conform can\n be allowed to enter the database.\n\n Additionally, can specify that existing data in the table must conform to the\n constraint (VALIDATE). Conversely, if specified NOVALIDATE, are not ensured\n that existing data conforms.\n\n An integrity constraint defined on a table can be in one of the following\n states:\n ENABLE, VALIDATE\n ENABLE, NOVALIDATE\n DISABLE, VALIDATE\n DISABLE, NOVALIDATE\n\n For details about the meaning of these states and an understanding of their\n consequences, see the Oracle Database SQL Language Reference. Some of these\n consequences are discussed here.\n\n Disabling Constraints\n To enforce the rules defined by integrity constraints, the constraints should\n always be enabled. However, consider temporarily disabling the integrity\n constraints of a table for the following performance reasons:\n\n - When loading large amounts of data into a table\n\n - When performing batch operations that make massive changes to a table (for\n example, changing every employee's number by adding 1000 to the existing number)\n\n - When importing or exporting one table at a time\n\n In all three cases, temporarily disabling integrity constraints can improve the\n performance of the operation, especially in data warehouse configurations.\n\n It is possible to enter data that violates a constraint while that constraint\n is disabled. Thus, always enable the constraint after completing any of the\n operations listed in the preceding bullet list.\n\n Enabling Constraints\n While a constraint is enabled, no row violating the constraint can be inserted\n into the table. However, while the constraint is disabled, such a row can be\n inserted. This row is known as an exception to the constraint. If the\n constraint is in the ENABLE, NOVALIDATE state, violations resulting from data\n entered while the constraint was disabled remain. The rows that violate the\n constraint must be either updated or deleted in order for the constraint to be\n put in the validated state.\n\n Can identify exceptions to a specific integrity constraint while attempting to\n enable the constraint. See \\\"Reporting Constraint Exceptions\\\". All rows\n violating constraints are noted in an EXCEPTIONS table, which can be examined.\n\n ENABLE, NOVALIDATE Constraint State\n When a constraint is in the ENABLE, NOVALIDATE state, all subsequent statements\n are checked for conformity to the constraint. However, any existing data in the\n table is not checked. A table with ENABLE, NOVALIDATE constraints can contain\n invalid data, but it is not possible to add new invalid data to it. Constraints\n in the ENABLE, NOVALIDATE state is most useful in data warehouse configurations\n that are uploading valid OLTP data.\n\n Enabling a constraint does not require validation. Enabling a constraint\n novalidate is much faster than enabling and validating a constraint. Also,\n validating a constraint that is already enabled does not require any DML locks\n during validation (unlike validating a previously disabled constraint).\n Enforcement guarantees that no violations are introduced during the validation.\n Hence, enabling without validating reduces the downtime typically associated\n with enabling a constraint.\n\n Efficient Use of Integrity Constraints: A Procedure\n\n Using integrity constraint states in the following order can ensure the best\n benefits:\n Disable state.\n Perform the operation (load, export, import).\n ENABLE, NOVALIDATE state.\n Enable state.\n\n Some benefits of using constraints in this order are:\n No locks are held.\n All constraints can go to enable state concurrently.\n Constraint enabling is done in parallel.\n Concurrent activity on table is permitted.\n\n Setting Integrity Constraints Upon Definition\n When an integrity constraint is defined in a CREATE TABLE or ALTER TABLE\n statement, it can be enabled, disabled, or validated or not validated as\n determined by the specification of the ENABLE/DISABLE clause. If the\n ENABLE/DISABLE clause is not specified in a constraint definition, the database\n automatically enables and validates the constraint.\n\n Disabling Constraints Upon Definition\n The following CREATE TABLE and ALTER TABLE statements both define and disable\n integrity constraints:\n\n CREATE TABLE emp (\n empno NUMBER(5) PRIMARY KEY DISABLE, . . . ;\n\n ALTER TABLE emp\n ADD PRIMARY KEY (empno) DISABLE;\n\n An ALTER TABLE statement that defines and disables an integrity constraint\n never fails because of rows in the table that violate the integrity constraint.\n The definition of the constraint is allowed because its rule is not enforced.\n\n Enabling Constraints Upon Definition\n\n The following CREATE TABLE and ALTER TABLE statements both define and enable\n integrity constraints:\n\n CREATE TABLE emp (\n empno NUMBER(5) CONSTRAINT emp.pk PRIMARY KEY, . . . ;\n\n ALTER TABLE emp\n ADD CONSTRAINT emp.pk PRIMARY KEY (empno);\n\n An ALTER TABLE statement that defines and attempts to enable an integrity\n constraint can fail because rows of the table violate the integrity constraint.\n If this case, the statement is rolled back, and the constraint definition is\n not stored and not enabled.\n\n When enabling a UNIQUE or PRIMARY KEY constraint, an associated index is\n created.\"\n tag \"fix\": \"Modify database code to properly validate data before it is put\n into the database or acted upon by the database.\n\n Modify database to contain field definitions for each field in the database.\n\n Modify database to contain constraints on database columns and tables that\n require them for data validity.\n\n Review the application schemas implemented on the system. Check the DDL for\n the tables that are created for the applications to see if constraints have\n been enabled.\n\n - - - - -\n Enabling Constraints Upon Definition\n The following CREATE TABLE and ALTER TABLE statements both define and enable\n integrity constraints:\n CREATE TABLE emp (\n empno NUMBER(5) CONSTRAINT emp.pk PRIMARY KEY, . . . ) ;\n ALTER TABLE emp\n ADD CONSTRAINT emp.pk PRIMARY KEY (empno);\n\n An ALTER TABLE statement that defines and attempts to enable an integrity\n constraint can fail because existing rows of the table violate the integrity\n constraint. In this case, the statement is rolled back, and the constraint\n definition is not stored and not enabled.\n\n When enabling a UNIQUE or PRIMARY KEY constraint, an associated index is\n created.\"\n describe 'A manual review is required to ensure the DBMS checks the validity of data inputs' do\n skip 'A manual review is required to ensure the DBMS checks the validity of data inputs'\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61675.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61785.rb", "line": 1 }, - "id": "V-61675" + "id": "V-61785" }, { - "title": "Oracle must back up user-level information per a defined frequency.", - "desc": "Information system backup is a critical step in maintaining data\n assurance and availability.\n\n User-level information is data generated by information system and/or\n application users. In order to assure availability of this data in the event of\n a system failure, DoD organizations are required to ensure user-generated data\n is backed up at a defined frequency. This includes data stored on file systems,\n within databases or within any other storage media.\n\n Applications performing backups must be capable of backing up user-level\n information per the DoD-defined frequency.\n\n Databases that do not backup information regularly risk the loss of that\n information in the event of a system failure. Most databases contain\n functionality to allow regular backups; it is important that this functionality\n is enabled and configured correctly to prevent data loss.", + "title": "The DBMS must uniquely identify and authenticate non-organizational\n users (or processes acting on behalf of non-organizational users).", + "desc": "Non-organizational users include all information system users other\n than organizational users which include organizational employees or individuals\n the organization deems to have equivalent status of employees (e.g.,\n contractors, guest researchers, individuals from allied nations).\n\n Non-organizational users shall be uniquely identified and authenticated for\n all accesses other than those accesses explicitly identified and documented by\n the organization when related to the use of anonymous access, such as accessing\n a web server.\n\n Accordingly, a risk assessment is used in determining the authentication\n needs of the organization.\n\n Scalability, practicality, and security are simultaneously considered in\n balancing the need to ensure ease of use for access to federal information and\n information systems with the need to protect and adequately mitigate risk to\n organizational operations, organizational assets, individuals, other\n organizations, and the Nation.", "descriptions": { - "default": "Information system backup is a critical step in maintaining data\n assurance and availability.\n\n User-level information is data generated by information system and/or\n application users. In order to assure availability of this data in the event of\n a system failure, DoD organizations are required to ensure user-generated data\n is backed up at a defined frequency. This includes data stored on file systems,\n within databases or within any other storage media.\n\n Applications performing backups must be capable of backing up user-level\n information per the DoD-defined frequency.\n\n Databases that do not backup information regularly risk the loss of that\n information in the event of a system failure. Most databases contain\n functionality to allow regular backups; it is important that this functionality\n is enabled and configured correctly to prevent data loss." + "default": "Non-organizational users include all information system users other\n than organizational users which include organizational employees or individuals\n the organization deems to have equivalent status of employees (e.g.,\n contractors, guest researchers, individuals from allied nations).\n\n Non-organizational users shall be uniquely identified and authenticated for\n all accesses other than those accesses explicitly identified and documented by\n the organization when related to the use of anonymous access, such as accessing\n a web server.\n\n Accordingly, a risk assessment is used in determining the authentication\n needs of the organization.\n\n Scalability, practicality, and security are simultaneously considered in\n balancing the need to ensure ease of use for access to federal information and\n information systems with the need to protect and adequately mitigate risk to\n organizational operations, organizational assets, individuals, other\n organizations, and the Nation." }, "impact": 0.5, "refs": [], "tags": { - "gtitle": "SRG-APP-000145-DB-000095", - "gid": "V-61693", - "rid": "SV-76183r2_rule", - "stig_id": "O121-C2-012200", - "fix_id": "F-67609r1_fix", + "gtitle": "SRG-APP-000180-DB-000115", + "gid": "V-61881", + "rid": "SV-76371r1_rule", + "stig_id": "O121-P2-015800", + "fix_id": "F-67797r1_fix", "cci": [ - "CCI-000535" + "CCI-000804" ], "nist": [ - "CP-9 (a)", + "IA-8", "Rev_4" ], "false_negatives": null, @@ -683,21 +682,21 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Review DBMS settings and site documentation to determine\n whether Oracle is configured to back up user-level data according to a defined\n frequency.\n\n If it is not, this is a finding.\n\n (The V$RMAN_STATUS view displays the finished and on-going RMAN jobs. For\n on-going jobs, this view displays progress and status.)", - "fix": "Configure the Oracle DBMS to back up user-level data on a defined\n frequency." + "check": "Review DBMS settings to determine whether non-organizational\n users are uniquely identified and authenticated when logging onto the system.\n\n If non-organizational users are not uniquely identified and authenticated, this\n is a finding.", + "fix": "Configure DBMS settings to uniquely identify and authenticate all\n non-organizational users who log onto the system." }, - "code": "control 'V-61693' do\n title 'Oracle must back up user-level information per a defined frequency.'\n desc \"Information system backup is a critical step in maintaining data\n assurance and availability.\n\n User-level information is data generated by information system and/or\n application users. In order to assure availability of this data in the event of\n a system failure, DoD organizations are required to ensure user-generated data\n is backed up at a defined frequency. This includes data stored on file systems,\n within databases or within any other storage media.\n\n Applications performing backups must be capable of backing up user-level\n information per the DoD-defined frequency.\n\n Databases that do not backup information regularly risk the loss of that\n information in the event of a system failure. Most databases contain\n functionality to allow regular backups; it is important that this functionality\n is enabled and configured correctly to prevent data loss.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000145-DB-000095'\n tag \"gid\": 'V-61693'\n tag \"rid\": 'SV-76183r2_rule'\n tag \"stig_id\": 'O121-C2-012200'\n tag \"fix_id\": 'F-67609r1_fix'\n tag \"cci\": ['CCI-000535']\n tag \"nist\": ['CP-9 (a)', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Review DBMS settings and site documentation to determine\n whether Oracle is configured to back up user-level data according to a defined\n frequency.\n\n If it is not, this is a finding.\n\n (The V$RMAN_STATUS view displays the finished and on-going RMAN jobs. For\n on-going jobs, this view displays progress and status.)\"\n tag \"fix\": \"Configure the Oracle DBMS to back up user-level data on a defined\n frequency.\"\n describe 'A manual review is required to ensure Oracle backs up user-level information per a defined frequency' do\n skip 'A manual review is required to ensure Oracle backs up user-level information per a defined frequency'\n end\nend\n", + "code": "control 'V-61881' do\n title \"The DBMS must uniquely identify and authenticate non-organizational\n users (or processes acting on behalf of non-organizational users).\"\n desc \"Non-organizational users include all information system users other\n than organizational users which include organizational employees or individuals\n the organization deems to have equivalent status of employees (e.g.,\n contractors, guest researchers, individuals from allied nations).\n\n Non-organizational users shall be uniquely identified and authenticated for\n all accesses other than those accesses explicitly identified and documented by\n the organization when related to the use of anonymous access, such as accessing\n a web server.\n\n Accordingly, a risk assessment is used in determining the authentication\n needs of the organization.\n\n Scalability, practicality, and security are simultaneously considered in\n balancing the need to ensure ease of use for access to federal information and\n information systems with the need to protect and adequately mitigate risk to\n organizational operations, organizational assets, individuals, other\n organizations, and the Nation.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000180-DB-000115'\n tag \"gid\": 'V-61881'\n tag \"rid\": 'SV-76371r1_rule'\n tag \"stig_id\": 'O121-P2-015800'\n tag \"fix_id\": 'F-67797r1_fix'\n tag \"cci\": ['CCI-000804']\n tag \"nist\": ['IA-8', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Review DBMS settings to determine whether non-organizational\n users are uniquely identified and authenticated when logging onto the system.\n\n If non-organizational users are not uniquely identified and authenticated, this\n is a finding.\"\n tag \"fix\": \"Configure DBMS settings to uniquely identify and authenticate all\n non-organizational users who log onto the system.\"\n describe 'A manual review is required to ensure the DBMS uniquely identifies and authenticates non-organizational\n users (or processes acting on behalf of non-organizational users).' do\n skip 'A manual review is required to ensure the DBMS uniquely identifies and authenticates non-organizational\n users (or processes acting on behalf of non-organizational users).'\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61693.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61881.rb", "line": 1 }, - "id": "V-61693" + "id": "V-61881" }, { - "title": "The Oracle Listener must be configured to require administration\n authentication.", - "desc": "Oracle listener authentication helps prevent unauthorized\n administration of the Oracle listener. Unauthorized administration of the\n listener could lead to DoS exploits; loss of connection audit data,\n unauthorized reconfiguration or other unauthorized access. This is a Category I\n finding because privileged access to the listener is not restricted to\n authorized users. Unauthorized access can result in stopping of the listener\n (DoS) and overwriting of listener audit logs.", + "title": "DBMS processes or services must run under custom, dedicated OS\n accounts.", + "desc": "Separation of duties is a prevalent Information Technology control\n that is implemented at different layers of the information system, including\n the operating system and in applications. It serves to eliminate or reduce the\n possibility that a single user may carry out a prohibited action. Separation of\n duties requires that the person accountable for approving an action is not the\n same person who is tasked with implementing or carrying out that action.\n\n The DBMS must run under a custom dedicated OS account. When the DBMS is\n running under a shared account, users with access to that account could\n inadvertently or maliciously make changes to the DBMS's settings, files, or\n permissions.", "descriptions": { - "default": "Oracle listener authentication helps prevent unauthorized\n administration of the Oracle listener. Unauthorized administration of the\n listener could lead to DoS exploits; loss of connection audit data,\n unauthorized reconfiguration or other unauthorized access. This is a Category I\n finding because privileged access to the listener is not restricted to\n authorized users. Unauthorized access can result in stopping of the listener\n (DoS) and overwriting of listener audit logs." + "default": "Separation of duties is a prevalent Information Technology control\n that is implemented at different layers of the information system, including\n the operating system and in applications. It serves to eliminate or reduce the\n possibility that a single user may carry out a prohibited action. Separation of\n duties requires that the person accountable for approving an action is not the\n same person who is tasked with implementing or carrying out that action.\n\n The DBMS must run under a custom dedicated OS account. When the DBMS is\n running under a shared account, users with access to that account could\n inadvertently or maliciously make changes to the DBMS's settings, files, or\n permissions." }, "impact": 0, "refs": [ @@ -706,16 +705,17 @@ } ], "tags": { - "gtitle": "SRG-APP-000516-DB-999900", - "gid": "V-61441", - "rid": "SV-75931r2_rule", - "stig_id": "O121-BP-022700", - "fix_id": "F-67357r1_fix", + "gtitle": "SRG-APP-000062-DB-000010", + "gid": "V-61579", + "rid": "SV-76069r1_rule", + "stig_id": "O121-C2-003400", + "fix_id": "F-67495r1_fix", "cci": [ - "CCI-000366" + "CCI-000366", + "CCI-002220" ], "nist": [ - "CM-6 b", + "AC-5 c", "Rev_4" ], "false_negatives": null, @@ -728,35 +728,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "If a listener is not running on the local database host server,\n this check is not a finding.\n\n Note: This check needs to be done only once per host system and once per\n listener. Multiple listeners may be defined on a single host system. They must\n all be reviewed, but only once per database home review.\n\n For subsequent database home reviews on the same host system, this check is not\n a finding.\n\n Determine all Listeners running on the host.\n\n For Windows hosts, view all Windows services with TNSListener embedded in the\n service name\n - The service name format is:\n Oracle[ORACLE_HOME_NAME]TNSListener\n\n For UNIX hosts, the Oracle Listener process will indicate the TNSLSNR\n executable.\n\n At a command prompt, issue the command:\n ps -ef | grep tnslsnr | grep -v grep\n\n The alias for the listener follows tnslsnr in the command output.\n\n Must be logged on the host system using the account that owns the tnslsnr\n executable (UNIX). If the account is denied local logon, have the system SA\n assist in this task by adding 'su' to the listener account from the root\n account. On Windows platforms, log on using an account with administrator\n privileges to complete the check.\n\n From a system command prompt, execute the listener control utility:\n\n lsnrctl status [LISTENER NAME]\n\n Review the results for the value of Security.\n\n If \"Security = OFF\" is displayed, this is a finding.\n\n If \"Security = ON: Local OS Authentication\" is displayed, this is not a\n finding.\n\n If \"Security = ON: Password or Local OS Authentication\", this is a finding\n (do not set a password on Oracle versions 10.1 and higher. Instead, use Local\n OS Authentication).\n\n Repeat the execution of the lsnrctl utility for all active listeners.", - "fix": "By default, Oracle Net Listener permits only local administration\n for security reasons. As a policy, the listener can be administered only by the\n user who started it. This is enforced through local operating system\n authentication. For example, if user1 starts the listener, then only user1 can\n administer it. Any other user trying to administer the listener gets an error.\n The super user is the only exception.\n\n Remote administration of the listener must not be permitted. If listener\n administration from a remote system is required, granting secure remote access\n to the Oracle DBMS server and performing local administration is preferred.\n Authorize and document this requirement in the System Security Plan.\n\n Note: In Oracle Database 12c Release 1 (12.1), the listener password feature is\n no longer supported. This does not cause a loss of security because\n authentication is enforced through local operating system authentication. Refer\n to Oracle Database Net Services Reference for additional information." + "check": "Check OS settings to determine whether DBMS processes are\n running under a dedicated OS account. If the DBMS processes are running under\n shared accounts, this is a finding.\n\n This is done by the default installation. The installation documentation\n recommends that a user account named ORACLE is created and is identified as the\n software owner.\n\n Log on to the system as the software owner, typically ORACLE, the $ORACLE_HOME\n environment variable will point to the Oracle software. Enter the following\n commands to see if ORACLE is the software owner:\n\n $ cd $ORACLE_HOME\n $ ls -l (shows the directories - oracle is the owner and oinstall is the group.\n The example list below has been truncated)\n drwxr-xr-x 2 oracle oinstall 4096 Nov 21 08:42 addnode\n drwxr-xr-x 8 oracle oinstall 4096 Nov 21 08:41 apex\n drwxr-xr-x 9 oracle oinstall 4096 Nov 21 08:39 assistants\n drwxr-xr-x 2 oracle oinstall 4096 Nov 21 09:17 bin\n drwxr-xr-x 7 oracle oinstall 4096 Nov 21 08:42 ccr\n drwxr-xr-x 3 oracle oinstall 4096 Nov 21 08:42 cdata\n drwxr-xr-x 5 oracle oinstall 4096 Nov 21 09:04 cfgtoollogs\n drwxr-xr-x 4 oracle oinstall 4096 Nov 21 08:42 clone\n drwxr-xr-x 6 oracle oinstall 4096 Nov 21 08:39 crs\n drwxr-xr-x 6 oracle oinstall 4096 Nov 21 08:42 css\n drwxr-xr-x 11 oracle oinstall 4096 Nov 21 08:42 ctx\n drwxr-xr-x 7 oracle oinstall 4096 Nov 21 08:39 cv\n drwxr-xr-x 2 oracle oinstall 4096 Dec 16 13:11 dbs\n drwxr-xr-x 2 oracle oinstall 4096 Nov 21 08:42 dc_ocm\n drwxr-xr-x 5 oracle oinstall 4096 Nov 21 08:45 deinstall\n drwxr-xr-x 3 oracle oinstall 4096 Nov 21 08:39 demo\n drwxr-xr-x 3 oracle oinstall 4096 Nov 21 08:39 diagnostics\n\n $ ps -ef | grep ora_ (shows all of the oracle processes owned by the oracle\n user. The example list below has been truncated)\n\n oracle 1786 1 0 13:11 ? 00:00:00 ora_pmon_stig\n oracle 1788 1 0 13:11 ? 00:00:00 ora_psp0_stig\n oracle 1790 1 1 13:11 ? 00:00:08 ora_vktm_stig\n oracle 1794 1 0 13:11 ? 00:00:00 ora_gen0_stig\n oracle 1796 1 0 13:11 ? 00:00:00 ora_mman_stig\n oracle 1800 1 0 13:11 ? 00:00:00 ora_diag_stig\n oracle 1802 1 0 13:11 ? 00:00:00 ora_dbrm_stig\n oracle 1804 1 0 13:11 ? 00:00:00 ora_vkrm_stig\n oracle 1806 1 0 13:11 ? 00:00:00 ora_dia0_stig\n oracle 1808 1 0 13:11 ? 00:00:00 ora_dbw0_stig\n oracle 1810 1 0 13:11 ? 00:00:00 ora_lgwr_stig\n oracle 1812 1 0 13:11 ? 00:00:00 ora_ckpt_stig\n oracle 1814 1 0 13:11 ? 00:00:00 ora_lg00_stig\n oracle 1816 1 0 13:11 ? 00:00:00 ora_smon_stig\n oracle 1818 1 0 13:11 ? 00:00:00 ora_lg01_stig\n oracle 1820 1 0 13:11 ? 00:00:00 ora_reco_stig\n oracle 1822 1 0 13:11 ? 00:00:00 ora_lreg_stig\n oracle 1824 1 0 13:11 ? 00:00:00 ora_pxmn_stig\n oracle 2137 2125 0 13:25 pts/1 00:00:00 grep ora_", + "fix": "Create an OS account dedicated to Oracle DBMS processes, and\n allow only Oracle DBMS processes to run under the account." }, - "code": " control 'V-61441' do\n impact 0.0\n describe 'This control is not applicable on oracle within aws rds, as aws manages the operating system in which the oracle database is running on' do\n skip 'This control is not applicable on oracle within aws rds, as aws manages the operating system in which the oracle database is running on'\n end\n end\n", + "code": " control 'V-61579' do\n impact 0.0\n describe 'This control is not applicable on oracle within aws rds, as aws manages the operating system in which the oracle database is running on' do\n skip 'This control is not applicable on oracle within aws rds, as aws manages the operating system in which the oracle database is running on'\n end\n end\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61441.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61579.rb", "line": 1 }, - "id": "V-61441" + "id": "V-61579" }, { - "title": "The Oracle REMOTE_OS_AUTHENT parameter must be set to FALSE.", - "desc": "Setting this value to TRUE allows operating system authentication over\n an unsecured connection. Trusting remote operating systems can allow a user to\n impersonate another operating system user and connect to the database without\n having to supply a password. If REMOTE_OS_AUTHENT is set to true, the only\n information a remote user needs to connect to the database is the name of any\n user whose account is setup to be authenticated by the operating system.", + "title": "The DBMS must enforce Discretionary Access Control (DAC) policy\n allowing users to specify and control sharing by named individuals, groups of\n individuals, or by both, limiting propagation of access rights and including or\n excluding access to the granularity of a single user.", + "desc": "Access control policies (e.g., identity-based policies, role-based\n policies, attribute-based policies) and access enforcement mechanisms (e.g.,\n access control lists, access control matrices, cryptography) are employed by\n organizations to control access between users (or processes acting on behalf of\n users) and objects (e.g., devices, files, records, processes, programs,\n domains).\n\n DAC is a type of access control methodology serving as a means of\n restricting access to objects and data based on the identity of subjects and/or\n groups to which they belong. It is discretionary in the sense that application\n users with the appropriate permissions to access an application resource or\n data have the discretion to pass that permission on to another user either\n directly or indirectly.\n\n Data protection requirements may result in a DAC policy being specified as\n part of the application design. Discretionary access controls would be employed\n at the application level to restrict and control access to application objects\n and data thereby providing increased information security for the organization.\n\n When DAC controls are employed, those controls must limit sharing to named\n application users, groups of users, or both. The application DAC controls must\n also limit the propagation of access rights and have the ability to exclude\n access to data down to the granularity of a single user.\n\n Databases using DAC must have the ability for the owner of an object or\n information to assign or revoke rights to view or modify the object or\n information. If the owner of an object or information does not have rights to\n exclude access to an object or information at a user level, users may gain\n access to objects and information they are not authorized to view/modify.", "descriptions": { - "default": "Setting this value to TRUE allows operating system authentication over\n an unsecured connection. Trusting remote operating systems can allow a user to\n impersonate another operating system user and connect to the database without\n having to supply a password. If REMOTE_OS_AUTHENT is set to true, the only\n information a remote user needs to connect to the database is the name of any\n user whose account is setup to be authenticated by the operating system." + "default": "Access control policies (e.g., identity-based policies, role-based\n policies, attribute-based policies) and access enforcement mechanisms (e.g.,\n access control lists, access control matrices, cryptography) are employed by\n organizations to control access between users (or processes acting on behalf of\n users) and objects (e.g., devices, files, records, processes, programs,\n domains).\n\n DAC is a type of access control methodology serving as a means of\n restricting access to objects and data based on the identity of subjects and/or\n groups to which they belong. It is discretionary in the sense that application\n users with the appropriate permissions to access an application resource or\n data have the discretion to pass that permission on to another user either\n directly or indirectly.\n\n Data protection requirements may result in a DAC policy being specified as\n part of the application design. Discretionary access controls would be employed\n at the application level to restrict and control access to application objects\n and data thereby providing increased information security for the organization.\n\n When DAC controls are employed, those controls must limit sharing to named\n application users, groups of users, or both. The application DAC controls must\n also limit the propagation of access rights and have the ability to exclude\n access to data down to the granularity of a single user.\n\n Databases using DAC must have the ability for the owner of an object or\n information to assign or revoke rights to view or modify the object or\n information. If the owner of an object or information does not have rights to\n exclude access to an object or information at a user level, users may gain\n access to objects and information they are not authorized to view/modify." }, - "impact": 0.7, + "impact": 0.5, "refs": [], "tags": { - "gtitle": "SRG-APP-000516-DB-999900", - "gid": "V-61425", - "rid": "SV-75915r1_rule", - "stig_id": "O121-BP-021900", - "fix_id": "F-67341r1_fix", + "gtitle": "SRG-APP-000036-DB-000174", + "gid": "V-61577", + "rid": "SV-76067r1_rule", + "stig_id": "O121-C2-003000", + "fix_id": "F-67493r1_fix", "cci": [ - "CCI-000366" + "CCI-002165" ], "nist": [ - "CM-6 b", + "AC-3 (4)", "Rev_4" ], "false_negatives": null, @@ -769,21 +769,21 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "From SQL*Plus:\n\n select value from v$parameter where name = 'remote_os_authent';\n\n If the value returned does not equal FALSE, this is a finding.", - "fix": "Document remote OS authentication in the System Security Plan.\n\n If not required or not mitigated to an acceptable level, disable remote OS\n authentication.\n\n From SQL*Plus:\n\n alter system set remote_os_authent = FALSE scope = spfile;\n\n The above SQL*Plus command will set the parameter to take effect at next system\n startup." + "check": "Check DBMS settings to determine if users are able to assign\n and revoke rights to the objects and information that they own. If users cannot\n assign or revoke rights to the objects and information that they own to groups,\n roles, or individual users, this is a finding.", + "fix": "Modify DBMS settings to allow users to assign or revoke access\n rights to objects and information owned by the user. The ability to grant or\n revoke rights must include the ability to grant or revoke those rights down to\n the granularity of a single user.\n\n (Note: In most cases, no fix will be necessary. This is default functionality\n for Oracle.)" }, - "code": "control 'V-61425' do\n title 'The Oracle REMOTE_OS_AUTHENT parameter must be set to FALSE.'\n desc \"Setting this value to TRUE allows operating system authentication over\n an unsecured connection. Trusting remote operating systems can allow a user to\n impersonate another operating system user and connect to the database without\n having to supply a password. If REMOTE_OS_AUTHENT is set to true, the only\n information a remote user needs to connect to the database is the name of any\n user whose account is setup to be authenticated by the operating system.\"\n impact 0.7\n tag \"gtitle\": 'SRG-APP-000516-DB-999900'\n tag \"gid\": 'V-61425'\n tag \"rid\": 'SV-75915r1_rule'\n tag \"stig_id\": 'O121-BP-021900'\n tag \"fix_id\": 'F-67341r1_fix'\n tag \"cci\": ['CCI-000366']\n tag \"nist\": ['CM-6 b', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"From SQL*Plus:\n\n select value from v$parameter where name = 'remote_os_authent';\n\n If the value returned does not equal FALSE, this is a finding.\"\n tag \"fix\": \"Document remote OS authentication in the System Security Plan.\n\n If not required or not mitigated to an acceptable level, disable remote OS\n authentication.\n\n From SQL*Plus:\n\n alter system set remote_os_authent = FALSE scope = spfile;\n\n The above SQL*Plus command will set the parameter to take effect at next system\n startup.\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n parameter = sql.query(\"select value from v$parameter where name = 'remote_os_authent';\").column('value')\n\n describe 'The oracle database REMOTE_OS_AUTHENT parameter' do\n subject { parameter }\n it { should cmp 'FALSE' }\n end\nend\n", + "code": "control 'V-61577' do\n title \"The DBMS must enforce Discretionary Access Control (DAC) policy\n allowing users to specify and control sharing by named individuals, groups of\n individuals, or by both, limiting propagation of access rights and including or\n excluding access to the granularity of a single user.\"\n desc \"Access control policies (e.g., identity-based policies, role-based\n policies, attribute-based policies) and access enforcement mechanisms (e.g.,\n access control lists, access control matrices, cryptography) are employed by\n organizations to control access between users (or processes acting on behalf of\n users) and objects (e.g., devices, files, records, processes, programs,\n domains).\n\n DAC is a type of access control methodology serving as a means of\n restricting access to objects and data based on the identity of subjects and/or\n groups to which they belong. It is discretionary in the sense that application\n users with the appropriate permissions to access an application resource or\n data have the discretion to pass that permission on to another user either\n directly or indirectly.\n\n Data protection requirements may result in a DAC policy being specified as\n part of the application design. Discretionary access controls would be employed\n at the application level to restrict and control access to application objects\n and data thereby providing increased information security for the organization.\n\n When DAC controls are employed, those controls must limit sharing to named\n application users, groups of users, or both. The application DAC controls must\n also limit the propagation of access rights and have the ability to exclude\n access to data down to the granularity of a single user.\n\n Databases using DAC must have the ability for the owner of an object or\n information to assign or revoke rights to view or modify the object or\n information. If the owner of an object or information does not have rights to\n exclude access to an object or information at a user level, users may gain\n access to objects and information they are not authorized to view/modify.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000036-DB-000174'\n tag \"gid\": 'V-61577'\n tag \"rid\": 'SV-76067r1_rule'\n tag \"stig_id\": 'O121-C2-003000'\n tag \"fix_id\": 'F-67493r1_fix'\n tag \"cci\": ['CCI-002165']\n tag \"nist\": ['AC-3 (4)', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Check DBMS settings to determine if users are able to assign\n and revoke rights to the objects and information that they own. If users cannot\n assign or revoke rights to the objects and information that they own to groups,\n roles, or individual users, this is a finding.\"\n tag \"fix\": \"Modify DBMS settings to allow users to assign or revoke access\n rights to objects and information owned by the user. The ability to grant or\n revoke rights must include the ability to grant or revoke those rights down to\n the granularity of a single user.\n\n (Note: In most cases, no fix will be necessary. This is default functionality\n for Oracle.)\"\n describe 'A manual review is required to ensure the DBMS enforces Discretionary Access Control (DAC) policy\n allowing users to specify and control sharing by named individuals, groups of\n individuals, or by both, limiting propagation of access rights and including or\n excluding access to the granularity of a single user.' do\n skip 'A manual review is required to ensure the DBMS enforces Discretionary Access Control (DAC) policy\n allowing users to specify and control sharing by named individuals, groups of\n individuals, or by both, limiting propagation of access rights and including or\n excluding access to the granularity of a single user.'\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61425.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61577.rb", "line": 1 }, - "id": "V-61425" + "id": "V-61577" }, { - "title": "The DBMS must use multifactor authentication for network access to\n non-privileged accounts.", - "desc": "Multifactor authentication is defined as using two or more factors to\n achieve authentication.\n\n Factors include:\n (i) Something a user knows (e.g., password/PIN);\n (ii) Something a user has (e.g., cryptographic identification device,\n token); or\n (iii) Something a user is (e.g., biometric).\n\n A non-privileged account is defined as an information system account with\n authorizations of a regular or non-privileged user.\n\n Network access is defined as access to an information system by a user (or\n a process acting on behalf of a user) communicating through a network (e.g.,\n local area network, wide area network, Internet).\n\n The lack of multifactor authentication makes it much easier for an attacker\n to gain unauthorized access to a system.\n\n Transport Layer Security (TLS) is the successor protocol to Secure Sockets\n Layer (SSL). Although the Oracle configuration parameters have names including\n 'SSL', such as SSL_VERSION and SSL_CIPHER_SUITES, they refer to TLS.", + "title": "The system must verify there have not been unauthorized changes to the\n DBMS software and information.", + "desc": "Organizations are required to employ integrity verification\n applications on information systems to look for evidence of information\n tampering, errors, and omissions. The organization is also required to employ\n good software engineering practices with regard to commercial off-the-shelf\n integrity mechanisms (e.g., parity checks, cyclical redundancy checks, and\n cryptographic hashes), and to use tools to automatically monitor the integrity\n of the information system and the applications it hosts.\n\n The DBMS opens data files and reads configuration files at system startup,\n system shutdown, and during abort recovery efforts. If the DBMS does not verify\n the trustworthiness of these files, it is vulnerable to malicious alterations\n of its configuration or unauthorized replacement of data.", "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 non-privileged account is defined as an information system account with\n authorizations of a regular or non-privileged user.\n\n Network access is defined as access to an information system by a user (or\n a process acting on behalf of a user) communicating through a network (e.g.,\n local area network, wide area network, Internet).\n\n The lack of multifactor authentication makes it much easier for an attacker\n to gain unauthorized access to a system.\n\n Transport Layer Security (TLS) is the successor protocol to Secure Sockets\n Layer (SSL). Although the Oracle configuration parameters have names including\n 'SSL', such as SSL_VERSION and SSL_CIPHER_SUITES, they refer to TLS." + "default": "Organizations are required to employ integrity verification\n applications on information systems to look for evidence of information\n tampering, errors, and omissions. The organization is also required to employ\n good software engineering practices with regard to commercial off-the-shelf\n integrity mechanisms (e.g., parity checks, cyclical redundancy checks, and\n cryptographic hashes), and to use tools to automatically monitor the integrity\n of the information system and the applications it hosts.\n\n The DBMS opens data files and reads configuration files at system startup,\n system shutdown, and during abort recovery efforts. If the DBMS does not verify\n the trustworthiness of these files, it is vulnerable to malicious alterations\n of its configuration or unauthorized replacement of data." }, "impact": 0, "refs": [ @@ -792,16 +792,17 @@ } ], "tags": { - "gtitle": "SRG-APP-000150-DB-000105", - "gid": "V-61705", - "rid": "SV-76195r2_rule", - "stig_id": "O121-C2-013000", - "fix_id": "F-67621r1_fix", + "gtitle": "SRG-APP-000262-DB-000159", + "gid": "V-61787", + "rid": "SV-76277r1_rule", + "stig_id": "O121-C2-019600", + "fix_id": "F-67703r1_fix", "cci": [ - "CCI-000766" + "CCI-002716", + "CCI-002718" ], "nist": [ - "IA-2 (2)", + "SI-7 (6)", "Rev_4" ], "false_negatives": null, @@ -814,35 +815,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 non-privileged accounts via a network are required to use multifactor\n authentication.\n\n If users logging on to non-privileged accounts via a network are not required\n to use multifactor authentication, this is a finding.\n\n Use authentication to prove the identities of users who are attempting to log\n on to the database. Authenticating user identity is imperative in distributed\n environments, without which there can be little confidence in network security.\n Passwords are the most common means of authentication. Oracle Database enables\n strong authentication with Oracle authentication adapters that support various\n third-party authentication services, including TLS with digital certificates.\n\n If the $ORACLE_HOME/network/admin/sqlnet.ora contains entries similar to the\n following, TLS is enabled.\n (Note: This assumes that a single sqlnet.ora file, in the default location, is\n in use. Please see the supplemental file \"Non-default sqlnet.ora\n configurations.pdf\" for how to find multiple and/or differently located\n sqlnet.ora files.)\n\n SQLNET.AUTHENTICATION_SERVICES= (BEQ, TCPS)\n SSL_VERSION = 1.2 or 1.1\n SSL_CLIENT_AUTHENTICATION = TRUE\n WALLET_LOCATION =\n (SOURCE =\n (METHOD = FILE)\n (METHOD_DATA =\n (DIRECTORY = /u01/app/oracle/product/12.1.0/dbhome_1/owm/wallets)\n )\n )\n\n SSL_CIPHER_SUITES= (SSL_RSA_WITH_AES_256_CBC_SHA384)\n ADR_BASE = /u01/app/oracle\n\n Note: \"SSL_VERSION = 1.2 or 1.1\" is the actual value, not a suggestion to\n use one or the other.", - "fix": "Configure DBMS, OS and/or enterprise-level authentication/access\n mechanism to require multifactor authentication for network users logging on to\n non-privileged accounts.\n\n If appropriate, enable support for Transport Layer Security (TLS) protocols and\n multifactor authentication through the use of Smart Cards (CAC/PIV)." + "check": "Verify the DBMS system initialization/parameter files and\n software is included in the configuration of any third-party software or\n custom scripting at the OS level to perform integrity verification.\n\n If neither a third-party application nor the OS is performing integrity\n verification of DBMS system files, this is a finding.", + "fix": "Utilize the OS or a third-party product to perform file\n verification of DBMS system file integrity.\n\n (Using Oracle Configuration Manager with Enterprise Manager, configured to\n perform this verification, is one possible way of satisfying this requirement.)" }, - "code": " control 'V-61705' do\n impact 0.0\n describe 'This control is not applicable on oracle within aws rds, as aws manages the operating system in which the oracle database is running on' do\n skip 'This control is not applicable on oracle within aws rds, as aws manages the operating system in which the oracle database is running on'\n end\n end\n", + "code": " control 'V-61787' 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-61705.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61787.rb", "line": 1 }, - "id": "V-61705" + "id": "V-61787" }, { - "title": "The DBMS must notify appropriate individuals when accounts are\n created.", - "desc": "Once an attacker establishes initial access to a system, they often\n attempt to create a persistent method of re-establishing access. One way to\n accomplish this is for the attacker to simply create a new account.\n\n Notification of account creation is one method and best practice for\n mitigating this risk. A comprehensive account management process will ensure an\n audit trail which documents the creation of application user accounts and\n notifies administrators and/or application owners exist. Such a process greatly\n reduces the risk that accounts will be surreptitiously created and provides\n logging that can be used for forensic purposes.\n\n Note that user authentication and account management must be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP. This requirement applies to cases where accounts are\n directly managed by Oracle.\n\n Notwithstanding how accounts are normally managed, the DBMS must support\n the requirement to notify appropriate individuals upon account creation within\n Oracle. Indeed, in a configuration where accounts are managed externally, the\n creation of an account within Oracle may indicate hostile activity.", + "title": "Administrators must utilize a separate, distinct administrative\n account when performing administrative activities, accessing database security\n functions, or accessing security-relevant information.", + "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 When privileged activities are not separated from non-privileged\n activities, the database can be subject to unauthorized changes to settings and\n data that a standard user would not normally have access to, outside of an\n authorized maintenance session.", "descriptions": { - "default": "Once an attacker establishes initial access to a system, they often\n attempt to create a persistent method of re-establishing access. One way to\n accomplish this is for the attacker to simply create a new account.\n\n Notification of account creation is one method and best practice for\n mitigating this risk. A comprehensive account management process will ensure an\n audit trail which documents the creation of application user accounts and\n notifies administrators and/or application owners exist. Such a process greatly\n reduces the risk that accounts will be surreptitiously created and provides\n logging that can be used for forensic purposes.\n\n Note that user authentication and account management must be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP. This requirement applies to cases where accounts are\n directly managed by Oracle.\n\n Notwithstanding how accounts are normally managed, the DBMS must support\n the requirement to notify appropriate individuals upon account creation within\n Oracle. Indeed, in a configuration where accounts are managed externally, the\n creation of an account within Oracle may indicate hostile activity." + "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 When privileged activities are not separated from non-privileged\n activities, the database can be subject to unauthorized changes to settings and\n data that a standard user would not normally have access to, outside of an\n authorized maintenance session." }, "impact": 0.5, "refs": [], "tags": { - "gtitle": "SRG-APP-000291-DB-000139", - "gid": "V-61797", - "rid": "SV-76287r2_rule", - "stig_id": "O121-C2-020400", - "fix_id": "F-67713r1_fix", + "gtitle": "SRG-APP-000063-DB-000017", + "gid": "V-61593", + "rid": "SV-76083r2_rule", + "stig_id": "O121-C2-004100", + "fix_id": "F-67509r1_fix", "cci": [ - "CCI-001683" + "CCI-000366" ], "nist": [ - "AC-2 (4)", + "CM-6 b", "Rev_4" ], "false_negatives": null, @@ -855,35 +856,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Check DBMS settings to determine whether it will notify\n appropriate individuals when accounts are created.\n\n If the DBMS does not notify appropriate individuals when accounts are created,\n this is a finding.", - "fix": "Working with the DBA and site management, determine the\n appropriate individuals (by job role) to be notified.\n\n If Oracle Audit Vault is available, configure it to notify the appropriate\n individuals when accounts are created.\n\n If Oracle Audit Vault is not available, configure the Oracle DBMS's auditing\n feature to record account-creation activity.\n\n If Standard Auditing is used:\n Create and deploy a mechanism, such as a frequently-run job, to monitor the\n SYS.AUD$ table for these records and notify the appropriate individuals.\n\n If unified Auditing is used:\n Create and deploy a mechanism, such as a frequently-run job, to monitor the\n SYS.UNIFIED_AUDIT_TRAIL view for these records and notify the appropriate\n individuals." + "check": "Review permissions for objects owned by DBA or other\n administrative accounts.\n\n If any objects owned by administrative accounts can be accessed by\n non-DBA/non-administrative users, either directly or indirectly, this is a\n finding.\n\n Verify DBAs have separate administrative accounts.\n\n If DBAs do not have a separate account for database administration purposes,\n this is a finding.\n\n To list all objects owned by an administrative account that have had access\n granted to another account, run the query:\n\n SELECT grantee, table_name, grantor, privilege, type from dba_tab_privs where\n owner= '';\n ", + "fix": "Revoke DBA privileges, and privileges to administer DBA-owned\n objects, from non-DBA accounts.\n\n Provide separate accounts to DBA for database administration." }, - "code": "control 'V-61797' do\n title \"The DBMS must notify appropriate individuals when accounts are\n created.\"\n desc \"Once an attacker establishes initial access to a system, they often\n attempt to create a persistent method of re-establishing access. One way to\n accomplish this is for the attacker to simply create a new account.\n\n Notification of account creation is one method and best practice for\n mitigating this risk. A comprehensive account management process will ensure an\n audit trail which documents the creation of application user accounts and\n notifies administrators and/or application owners exist. Such a process greatly\n reduces the risk that accounts will be surreptitiously created and provides\n logging that can be used for forensic purposes.\n\n Note that user authentication and account management must be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP. This requirement applies to cases where accounts are\n directly managed by Oracle.\n\n Notwithstanding how accounts are normally managed, the DBMS must support\n the requirement to notify appropriate individuals upon account creation within\n Oracle. Indeed, in a configuration where accounts are managed externally, the\n creation of an account within Oracle may indicate hostile activity.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000291-DB-000139'\n tag \"gid\": 'V-61797'\n tag \"rid\": 'SV-76287r2_rule'\n tag \"stig_id\": 'O121-C2-020400'\n tag \"fix_id\": 'F-67713r1_fix'\n tag \"cci\": ['CCI-001683']\n tag \"nist\": ['AC-2 (4)', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Check DBMS settings to determine whether it will notify\n appropriate individuals when accounts are created.\n\n If the DBMS does not notify appropriate individuals when accounts are created,\n this is a finding.\"\n tag \"fix\": \"Working with the DBA and site management, determine the\n appropriate individuals (by job role) to be notified.\n\n If Oracle Audit Vault is available, configure it to notify the appropriate\n individuals when accounts are created.\n\n If Oracle Audit Vault is not available, configure the Oracle DBMS's auditing\n feature to record account-creation activity.\n\n If Standard Auditing is used:\n Create and deploy a mechanism, such as a frequently-run job, to monitor the\n SYS.AUD$ table for these records and notify the appropriate individuals.\n\n If unified Auditing is used:\n Create and deploy a mechanism, such as a frequently-run job, to monitor the\n SYS.UNIFIED_AUDIT_TRAIL view for these records and notify the appropriate\n individuals.\"\n describe 'A manual review is required to ensure the DBMS notifies the appropriate individuals when accounts are\n created' do\n skip 'A manual review is required to ensure the DBMS notifies the appropriate individuals when accounts are\n created'\n end\nend\n", + "code": "control 'V-61593' do\n title \"Administrators must utilize a separate, distinct administrative\n account when performing administrative activities, accessing database security\n functions, or accessing security-relevant information.\"\n desc \"This requirement is intended to limit exposure due to operating from\n within a privileged account or role. The inclusion of role is intended to\n address those situations where an access control policy, such as Role Based\n Access Control (RBAC), is being implemented and where a change of role provides\n the same degree of assurance in the change of access authorizations for both\n the user and all processes acting on behalf of the user as would be provided by\n a change between a privileged and non-privileged account.\n\n To limit exposure when operating from within a privileged account or role,\n the application must support organizational requirements that users of\n information system accounts, or roles, with access to organization-defined\n lists of security functions or security-relevant information, use\n non-privileged accounts, or roles, when accessing other (non-security) system\n functions.\n\n When privileged activities are not separated from non-privileged\n activities, the database can be subject to unauthorized changes to settings and\n data that a standard user would not normally have access to, outside of an\n authorized maintenance session.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000063-DB-000017'\n tag \"gid\": 'V-61593'\n tag \"rid\": 'SV-76083r2_rule'\n tag \"stig_id\": 'O121-C2-004100'\n tag \"fix_id\": 'F-67509r1_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 permissions for objects owned by DBA or other\n administrative accounts.\n\n If any objects owned by administrative accounts can be accessed by\n non-DBA/non-administrative users, either directly or indirectly, this is a\n finding.\n\n Verify DBAs have separate administrative accounts.\n\n If DBAs do not have a separate account for database administration purposes,\n this is a finding.\n\n To list all objects owned by an administrative account that have had access\n granted to another account, run the query:\n\n SELECT grantee, table_name, grantor, privilege, type from dba_tab_privs where\n owner= '';\n \"\n tag \"fix\": \"Revoke DBA privileges, and privileges to administer DBA-owned\n objects, from non-DBA accounts.\n\n Provide separate accounts to DBA for database administration.\"\n describe 'A manual review is required to ensure administrators must utilize a separate, distinct administrative\n account when performing administrative activities, accessing database security\n functions, or accessing security-relevant information' do\n skip 'A manual review is required to ensure administrators must utilize a separate, distinct administrative\n account when performing administrative activities, accessing database security\n functions, or accessing security-relevant information'\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61797.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61593.rb", "line": 1 }, - "id": "V-61797" + "id": "V-61593" }, { - "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": "Procedures and restrictions for import of production data to\n development databases must be documented, implemented and followed.", + "desc": "Data export from production databases may include sensitive data.\n Application developers may not be cleared for or have need-to-know to sensitive\n data. Any access they may have to production data would be considered\n unauthorized access and subject the sensitive data to unlawful or unauthorized\n disclosure.", "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": "Data export from production databases may include sensitive data.\n Application developers may not be cleared for or have need-to-know to sensitive\n data. Any access they may have to production data would be considered\n unauthorized access and subject the sensitive data to unlawful or unauthorized\n disclosure." }, - "impact": 0, + "impact": 0.5, "refs": [], "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-000516-DB-999900", + "gid": "V-61501", + "rid": "SV-75991r1_rule", + "stig_id": "O121-BP-024800", + "fix_id": "F-67417r1_fix", "cci": [ - "CCI-000164" + "CCI-000366" ], "nist": [ - "AU-9", + "CM-6 b", "Rev_4" ], "false_negatives": null, @@ -896,39 +897,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Review locations of audit logs, both internal to the database\n and database audit logs located at the operating system-level. Verify there are\n appropriate controls and permissions to protect the audit information from\n unauthorized deletion.\n\n If appropriate controls and permissions do not exist, this is a finding.\n\n - - - - -\n If Standard Auditing is used:\n DBA_TAB_PRIVS describes all object grants in the database. Check to see who\n has permissions on the AUD$ table.\n\n Related View\n\n DBA_TAB_PRIVS describes the object grants for which the current user is the\n object owner, grantor, or grantee.\n\n Column Datatype NULL Description\n GRANTEE VARCHAR2(30) NOT NULL Name of the user to whom access was granted\n OWNER VARCHAR2(30) NOT NULL Owner of the object\n TABLE_NAME VARCHAR2(30) NOT NULL Name of the object\n GRANTOR VARCHAR2(30) NOT NULL Name of the user who performed the grant\n PRIVILEGE VARCHAR2(40) NOT NULL Privilege on the object\n GRANTABLE VARCHAR2(3) Indicates whether the privilege was granted\n with the GRANT OPTION (YES) or not (NO)\n HIERARCHY VARCHAR2(3) Indicates whether the privilege was granted\n with the HIERARCHY OPTION (YES) or not (NO)\n COMMON VARCHAR2(3)\n TYPE VARCHAR2(24)\n\n sqlplus connect as sysdba;\n\n SQL> SELECT GRANTEE, TABLE_NAME, PRIVILEGE\n FROM DBA_TAB_PRIVS where table_name = 'AUD$';\n\n If Unified Auditing is used:\n DBA_TAB_PRIVS describes all object grants in the database. Check to see who\n has permissions on the AUDSYS tables.\n\n Related View\n\n DBA_TAB_PRIVS describes the object grants for which the current user is the\n object owner, grantor, or grantee.\n\n Column Datatype NULL Description\n GRANTEE VARCHAR2(30) NOT NULL Name of the user to whom access was granted\n OWNER VARCHAR2(30) NOT NULL Owner of the object\n TABLE_NAME VARCHAR2(30) NOT NULL Name of the object\n GRANTOR VARCHAR2(30) NOT NULL Name of the user who performed the grant\n PRIVILEGE VARCHAR2(40) NOT NULL Privilege on the object\n GRANTABLE VARCHAR2(3) Indicates whether the privilege was granted\n with the GRANT OPTION (YES) or not (NO)\n HIERARCHY VARCHAR2(3) Indicates whether the privilege was granted\n with the HIERARCHY OPTION (YES) or not (NO)\n COMMON VARCHAR2(3)\n TYPE VARCHAR2(24)\n\n sqlplus connect as sysdba;\n\n SQL> SELECT GRANTEE, TABLE_NAME, PRIVILEGE\n FROM DBA_TAB_PRIVS where owner='AUDSYS';", - "fix": "Add controls and modify permissions to protect database audit log\n data from unauthorized deletion, whether stored in the database itself or at\n the OS-level.\n\n - - - - -\n If Standard Auditing is used:\n Revoke access to the AUD$ table to anyone who should not have access to it.\n\n In the check we looked for all users who had access to the AUD$ table. To fix\n this, use the REVOKE command to revoke access to users who should not have\n access to the audit data.\n\n REVOKE statement\n\n Use the REVOKE statement to remove permissions from a specific user or from all\n users to perform actions on database objects.\n The following types of permissions can be revoked:\n\n Delete data from a specific table.\n Insert data into a specific table.\n Create a foreign key reference to the named table or to a subset of columns\n from a table.\n Select data from a table, view, or a subset of columns in a table.\n Create a trigger on a table.\n Update data in a table or in a subset of columns in a table.\n Run a specified routine (function or procedure).\n\n If a user named FRED had access to the AUD$ table and wanting to revoke that\n access, use the following command. The syntax that would be used for the REVOKE\n statement for tables is as follows:\n\n REVOKE privilege-type ON [ TABLE ] { table-Name | view-Name } FROM grantees\n\n SQL>REVOKE SELECT ON TABLE AUD$ FROM FRED;\n\n Revoking a privilege without specifying a column list revokes the privilege for\n all of the columns in the table.\n Syntax for routines\n\n table-privileges include\n\n DELETE |\n INSERT |\n REFERENCES [column list] |\n SELECT [column list] |\n TRIGGER |\n UPDATE [column list]\n\n column list\n\n ( column-identifier {, column-identifier}* )\n\n Use the ALL PRIVILEGES privilege type to revoke all of the permissions from the\n user for the specified table. Can also revoke one or more table privileges by\n specifying a privilege-list.\n\n Use the DELETE privilege type to revoke permission to delete rows from the\n specified table.\n\n Use the INSERT privilege type to revoke permission to insert rows into the\n specified table.\n\n Use the REFERENCES privilege type to revoke permission to create a foreign key\n reference to the specified table. If a column list is specified with the\n REFERENCES privilege, the permission is revoked on only the foreign key\n reference to the specified columns.\n\n Use the SELECT privilege type to revoke permission to perform SELECT statements\n on a table or view. If a column list is specified with the SELECT privilege,\n the permission is revoked on only those columns. If no column list is\n specified, then the privilege is valid on all of the columns in the table.\n\n Use the TRIGGER privilege type to revoke permission to create a trigger on the\n specified table.\n\n Use the UPDATE privilege type to revoke permission to use the UPDATE statement\n on the specified table. If a column list is specified, the permission is\n revoked only on the specified columns.\n grantees\n\n { authorization ID | PUBLIC } [,{ authorization ID | PUBLIC } ] *\n\n Can revoke the privileges from specific users or from all users. Use the\n keyword PUBLIC to specify all users. The privileges revoked from PUBLIC and\n from individual users are independent privileges. For example, a SELECT\n privilege on table t is granted to both PUBLIC and to the authorization ID\n harry. The SELECT privilege is later revoked from the authorization ID 'Harry',\n but the authorization ID 'Harry' can access the table through the PUBLIC\n privilege.\n\n Restriction: Cannot revoke the privileges of the owner of an object.\n routine-designator\n\n {\n qualified-name [ signature ]\n }\n\n Cascading object dependencies\n\n For views, triggers, and constraints, if the privilege on which the object\n depends is revoked, the object is automatically dropped. Derby does not try to\n determine if there are other privileges that can replace the privileges that\n are being revoked. For more information, see \"SQL standard authorization\" in\n the Java DB Developer's Guide.\n Limitations\n\n The following limitations apply to the REVOKE statement:\n\n Table-level privileges:\n\n All of the table-level privilege types for a specified grantee and table ID are\n stored in one row in the SYSTABLEPERMS system table. For example, when user2 is\n granted the SELECT and DELETE privileges on table user1.t1, a row is added to\n the SYSTABLEPERMS table. The GRANTEE field contains user2 and the TABLEID\n contains user1.t1. The SELECTPRIV and DELETEPRIV fields are set to Y. The\n remaining privilege type fields are set to N.\n\n When a grantee creates an object that relies on one of the privilege types, the\n Derby engine tracks the dependency of the object on the specific row in the\n SYSTABLEPERMS table. For example, user2 creates the view v1 by using the\n statement SELECT * FROM user1.t1; the dependency manager tracks the dependency\n of view v1 on the row in SYSTABLEPERMS for GRANTEE(user2), TABLEID(user1.t1).\n The dependency manager knows only that the view is dependent on a privilege\n type in that specific row but does not track exactly which privilege type the\n view is dependent on.\n\n When a REVOKE statement for a table-level privilege is issued for a grantee and\n table ID, all of the objects that are dependent on the grantee and table ID are\n dropped. For example, if user1 revokes the DELETE privilege on table t1 from\n user2, the row in SYSTABLEPERMS for GRANTEE(user2), TABLEID(user1.t1) is\n modified by the REVOKE statement. The dependency manager sends a revoke\n invalidation message to the view user2.v1, and the view is dropped, even though\n the view is not dependent on the DELETE privilege for GRANTEE(user2),\n TABLEID(user1.t1).\n\n Column-level privileges:\n\n Only one type of privilege for a specified grantee and table ID are stored in\n one row in the SYSCOLPERMS system table. For example, when user2 is granted the\n SELECT privilege on table user1.t1 for columns c12 and c13, a row is added to\n the SYSCOLPERMS. The GRANTEE field contains user2, the TABLEID contains\n user1.t1, the TYPE field contains S, and the COLUMNS field contains c12, c13.\n\n When a grantee creates an object that relies on the privilege type and the\n subset of columns in a table ID, the Derby engine tracks the dependency of the\n object on the specific row in the SYSCOLPERMS table. For example, user2 creates\n the view v1 by using the statement SELECT c11 FROM user1.t1; the dependency\n manager tracks the dependency of view v1 on the row in SYSCOLPERMS for\n GRANTEE(user2), TABLEID(user1.t1), TYPE(S). The dependency manager knows that\n the view is dependent on the SELECT privilege type but does not track exactly\n which columns the view is dependent on.\n\n When a REVOKE statement for a column-level privilege is issued for a grantee,\n table ID, and type, all of the objects that are dependent on the grantee, table\n ID, and type are dropped. For example, if user1 revokes the SELECT privilege on\n column c12 on table user1.t1 from user2, the row in SYSCOLPERMS for\n GRANTEE(user2), TABLEID(user1.t1), TYPE(S) is modified by the REVOKE statement.\n The dependency manager sends a revoke invalidation message to the view\n user2.v1, and the view is dropped, even though the view is not dependent on the\n column c12 for GRANTEE(user2), TABLEID(user1.t1), TYPE(S).\n\n If Unified Auditing is used:\n\n Apply the same process used in standard auditing to the tables with AUDSYS as\n the owner." + "check": "If the database being reviewed is not a production database or\n does not contain sensitive data, this check is not a finding.\n\n Review documented policy, procedures and proof of implementation for\n restrictions placed on data exports from the production database.\n\n Policy and procedures should include that only authorized users have access to\n DBMS export utilities and that export data is properly sanitized prior to\n import to a development database.\n\n Policy and procedures may also include that developers be granted the necessary\n clearance and need-to-know prior to import of production data.\n\n If documented policy, procedures and proof of implementation are not present or\n complete, this is a finding.\n\n If methods to sanitize sensitive data are required and not documented or\n followed, this is a finding.", + "fix": "Develop, document and implement policy and procedures that\n provide restrictions for production data export.\n\n Require users and administrators assigned privileges that allow the export of\n production data from a production database to acknowledge understanding of\n export restrictions.\n\n Restrict permissions allowing use or access to database export procedures or\n functions to authorized users.\n\n Ensure sensitive data from production is sanitized prior to import to a\n development database (See check O121-BP-023300.)\n\n Grant access and need-to-know to developers where allowed by policy." }, - "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-61501' do\n title \"Procedures and restrictions for import of production data to\n development databases must be documented, implemented and followed.\"\n desc \"Data export from production databases may include sensitive data.\n Application developers may not be cleared for or have need-to-know to sensitive\n data. Any access they may have to production data would be considered\n unauthorized access and subject the sensitive data to unlawful or unauthorized\n disclosure.\"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000516-DB-999900'\n tag \"gid\": 'V-61501'\n tag \"rid\": 'SV-75991r1_rule'\n tag \"stig_id\": 'O121-BP-024800'\n tag \"fix_id\": 'F-67417r1_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 database being reviewed is not a production database or\n does not contain sensitive data, this check is not a finding.\n\n Review documented policy, procedures and proof of implementation for\n restrictions placed on data exports from the production database.\n\n Policy and procedures should include that only authorized users have access to\n DBMS export utilities and that export data is properly sanitized prior to\n import to a development database.\n\n Policy and procedures may also include that developers be granted the necessary\n clearance and need-to-know prior to import of production data.\n\n If documented policy, procedures and proof of implementation are not present or\n complete, this is a finding.\n\n If methods to sanitize sensitive data are required and not documented or\n followed, this is a finding.\"\n tag \"fix\": \"Develop, document and implement policy and procedures that\n provide restrictions for production data export.\n\n Require users and administrators assigned privileges that allow the export of\n production data from a production database to acknowledge understanding of\n export restrictions.\n\n Restrict permissions allowing use or access to database export procedures or\n functions to authorized users.\n\n Ensure sensitive data from production is sanitized prior to import to a\n development database (See check O121-BP-023300.)\n\n Grant access and need-to-know to developers where allowed by policy.\"\n describe 'A manual review is required to ensure procedures and restrictions for import of production data to\n development databases are documented, implemented and followed' do\n skip 'A manual review is required to ensure procedures and restrictions for import of production data to\n development databases are documented, implemented and followed'\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61657.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61501.rb", "line": 1 }, - "id": "V-61657" + "id": "V-61501" }, { - "title": "The DBMS must support enforcement of logical access restrictions\n associated with changes to the DBMS configuration and to the database itself.", - "desc": "When dealing with access restrictions pertaining to change control, it\n should be noted any changes to the hardware, software, and/or firmware\n components of the information system and/or application can have significant\n effects on the overall security of the system.\n\n Accordingly, only qualified and authorized individuals must be allowed to\n obtain access to application components for the purposes of initiating changes,\n including upgrades and modifications.\n\n Modifications to the DBMS settings, the database files, database\n configuration files, or the underlying database application files themselves\n could have catastrophic consequences to the database. Modification to DBMS\n settings could include turning off access controls to the database, the halting\n of archiving, the halting of auditing, and any number of other malicious\n actions.", + "title": "The Oracle REMOTE_LOGIN_PASSWORDFILE parameter must be set to\n EXCLUSIVE or NONE.", + "desc": "The REMOTE_LOGIN_PASSWORDFILE setting of \"NONE\" disallows remote\n administration of the database. The REMOTE_LOGIN_PASSWORDFILE setting of\n \"EXCLUSIVE\" allows for auditing of individual DBA logons to the SYS account.\n If not set to \"EXCLUSIVE\", remote connections to the database as \"internal\"\n or \"as SYSDBA\" are not logged to an individual account.", "descriptions": { - "default": "When dealing with access restrictions pertaining to change control, it\n should be noted any changes to the hardware, software, and/or firmware\n components of the information system and/or application can have significant\n effects on the overall security of the system.\n\n Accordingly, only qualified and authorized individuals must be allowed to\n obtain access to application components for the purposes of initiating changes,\n including upgrades and modifications.\n\n Modifications to the DBMS settings, the database files, database\n configuration files, or the underlying database application files themselves\n could have catastrophic consequences to the database. Modification to DBMS\n settings could include turning off access controls to the database, the halting\n of archiving, the halting of auditing, and any number of other malicious\n actions." + "default": "The REMOTE_LOGIN_PASSWORDFILE setting of \"NONE\" disallows remote\n administration of the database. The REMOTE_LOGIN_PASSWORDFILE setting of\n \"EXCLUSIVE\" allows for auditing of individual DBA logons to the SYS account.\n If not set to \"EXCLUSIVE\", remote connections to the database as \"internal\"\n or \"as SYSDBA\" are not logged to an individual account." }, - "impact": 0, - "refs": [ - { - "ref": [] - } - ], + "impact": 0.5, + "refs": [], "tags": { - "gtitle": "SRG-APP-000128-DB-000086", - "gid": "V-61671", - "rid": "SV-76161r1_rule", - "stig_id": "O121-C2-010300", - "fix_id": "F-67585r1_fix", + "gtitle": "SRG-APP-000516-DB-999900", + "gid": "V-61431", + "rid": "SV-75921r2_rule", + "stig_id": "O121-BP-022200", + "fix_id": "F-67347r2_fix", "cci": [ - "CCI-000345" + "CCI-000366" ], "nist": [ - "CM-5", + "CM-6 b", "Rev_4" ], "false_negatives": null, @@ -941,39 +938,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Review DBMS settings and vendor documentation to ensure the\n database supports and does not interfere with enforcement of logical access\n restrictions associated with changes to the DBMS configuration and to the\n database itself.\n\n If the DBMS software in any way restricts the implementation of logical access\n controls implemented to protect its integrity or availability, this is a\n finding.", - "fix": "Configure the DBMS to allow implementation of logical access\n restrictions aimed at protecting the DBMS from unauthorized changes to its\n configuration and to the database itself.\n\n - - - - -\n When the Oracle Database is installed on a Unix-like operating system, the\n required umask is 022, and the file permissions are set so that any\n modifications to the startup files can only be performed by the owner of the\n software, a member of the group DBA, or the root user. Changing the umask has\n caused problems when patching the environment. If changes are to be made, they\n should be reverted to the status they were in before the modification for\n patching and upgrades." + "check": "From SQL*Plus:\n\n select value from v$parameter where upper(name) = 'REMOTE_LOGIN_PASSWORDFILE';\n\n If the value returned does not equal 'EXCLUSIVE' or 'NONE', this is a finding.", + "fix": "Disable use of the REMOTE_LOGIN_PASSWORDFILE where remote\n administration is not authorized by specifying a value of NONE.\n\n If authorized, restrict use of a password file to exclusive use by each\n database by specifying a value of EXCLUSIVE.\n\n From SQL*Plus:\n\n alter system set REMOTE_LOGIN_PASSWORDFILE = 'EXCLUSIVE' scope = spfile;\n\n OR\n\n alter system set REMOTE_LOGIN_PASSWORDFILE = 'NONE' scope = spfile;\n\n The above SQL*Plus command will set the parameter to take effect at next system\n startup." }, - "code": " control 'V-61671' 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-61431' do\n title \"The Oracle REMOTE_LOGIN_PASSWORDFILE parameter must be set to\n EXCLUSIVE or NONE.\"\n desc \"The REMOTE_LOGIN_PASSWORDFILE setting of \\\"NONE\\\" disallows remote\n administration of the database. The REMOTE_LOGIN_PASSWORDFILE setting of\n \\\"EXCLUSIVE\\\" allows for auditing of individual DBA logons to the SYS account.\n If not set to \\\"EXCLUSIVE\\\", remote connections to the database as \\\"internal\\\"\n or \\\"as SYSDBA\\\" are not logged to an individual account.\"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000516-DB-999900'\n tag \"gid\": 'V-61431'\n tag \"rid\": 'SV-75921r2_rule'\n tag \"stig_id\": 'O121-BP-022200'\n tag \"fix_id\": 'F-67347r2_fix'\n tag \"cci\": ['CCI-000366']\n tag \"nist\": ['CM-6 b', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"From SQL*Plus:\n\n select value from v$parameter where upper(name) = 'REMOTE_LOGIN_PASSWORDFILE';\n\n If the value returned does not equal 'EXCLUSIVE' or 'NONE', this is a finding.\"\n tag \"fix\": \"Disable use of the REMOTE_LOGIN_PASSWORDFILE where remote\n administration is not authorized by specifying a value of NONE.\n\n If authorized, restrict use of a password file to exclusive use by each\n database by specifying a value of EXCLUSIVE.\n\n From SQL*Plus:\n\n alter system set REMOTE_LOGIN_PASSWORDFILE = 'EXCLUSIVE' scope = spfile;\n\n OR\n\n alter system set REMOTE_LOGIN_PASSWORDFILE = 'NONE' scope = spfile;\n\n The above SQL*Plus command will set the parameter to take effect at next system\n startup.\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n parameter = sql.query(\"select value from v$parameter where upper(name) = 'REMOTE_LOGIN_PASSWORDFILE';\").column('value')\n\n describe.one do\n describe 'The oracle database REMOTE_LOGIN_PASSWORDFILE parameter' do\n subject { parameter }\n it { should cmp 'EXCLUSIVE' }\n end\n\n describe 'The oracle database REMOTE_LOGIN_PASSWORDFILE parameter' do\n subject { parameter }\n it { should cmp 'NONE' }\n end\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61671.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61431.rb", "line": 1 }, - "id": "V-61671" + "id": "V-61431" }, { - "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": "The DBMS must automatically audit account modification.", + "desc": "Once an attacker establishes initial access to a system, they often\n attempt to create a persistent method of re-establishing access. One way to\n accomplish this is for the attacker to simply modify an existing account.\n\n Auditing of account modification is one method and best practice for\n mitigating this risk. A comprehensive application account management process\n ensures an audit trail automatically documents the modification of application\n user accounts and, as required, notifies administrators, application owners,\n and/or appropriate individuals. Applications must provide this capability\n directly, leveraging complementary technology providing this capability or a\n combination thereof.\n\n Automated account auditing processes greatly reduces the risk that accounts\n will be surreptitiously modified and provides logging that can be used for\n forensic purposes.\n\n Note that user authentication and account management should be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP.\n\n However, notwithstanding how accounts are managed, Oracle auditing should\n always be configured to capture account modification.", "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": "Once an attacker establishes initial access to a system, they often\n attempt to create a persistent method of re-establishing access. One way to\n accomplish this is for the attacker to simply modify an existing account.\n\n Auditing of account modification is one method and best practice for\n mitigating this risk. A comprehensive application account management process\n ensures an audit trail automatically documents the modification of application\n user accounts and, as required, notifies administrators, application owners,\n and/or appropriate individuals. Applications must provide this capability\n directly, leveraging complementary technology providing this capability or a\n combination thereof.\n\n Automated account auditing processes greatly reduces the risk that accounts\n will be surreptitiously modified and provides logging that can be used for\n forensic purposes.\n\n Note that user authentication and account management should be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP.\n\n However, notwithstanding how accounts are managed, Oracle auditing should\n always be configured to capture account modification." }, "impact": 0.5, - "refs": [ - { - "ref": [] - } - ], + "refs": [], "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-000027-DB-000186", + "gid": "V-61569", + "rid": "SV-76059r2_rule", + "stig_id": "O121-C2-002300", + "fix_id": "F-67485r3_fix", "cci": [ - "CCI-000192" + "CCI-001403" ], "nist": [ - "IA-5 (1) (a)", + "AC-2 (4)", "Rev_4" ], "false_negatives": null, @@ -986,35 +979,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. 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": "Check Oracle settings (and also OS settings and/or\n enterprise-level authentication/access mechanisms settings) to determine if\n account modification is being audited. If account modification is not being\n audited by Oracle, this is a finding.\n\n If Standard Auditing is used:\n To see if Oracle is configured to capture audit data, enter the following\n SQL*Plus command:\n SHOW PARAMETER AUDIT_TRAIL\n or the following SQL query:\n SELECT * FROM SYS.V$PARAMETER WHERE NAME = 'audit_trail';\n If Oracle returns the value 'NONE', this is a finding.\n\n If Unified Auditing is used:\n To see if Oracle is configured to capture audit data including account\n modification, enter the following SQL*Plus command:\n SELECT ' Account modification is not being audited. '\n FROM dual\n WHERE (SELECT Count(*)\n FROM (select policy_name , audit_option from audit_unified_policies\n WHERE audit_option = 'ALTER USER'\n and policy_name in (select policy_name from\n audit_unified_enabled_policies where user_name='ALL USERS'))) = 0\n OR (SELECT value\n FROM v$option\n WHERE parameter = 'Unified Auditing') != 'TRUE';\n\n If Oracle returns \"no rows selected\", this is not a finding.", + "fix": "Configure Oracle to audit account modifications activities.\n\n If Standard Auditing is used:\n Use this process to ensure auditable events are captured:\n ALTER SYSTEM SET AUDIT_TRAIL= SCOPE=SPFILE;\n Audit trail type can be 'OS', 'DB', 'DB,EXTENDED', 'XML' or 'XML,EXTENDED'.\n After executing this statement, it may be necessary to shut down and restart\n the Oracle database.\n\n If Unified Auditing is used:\n To ensure auditable events are captured:\n Link the oracle binary with uniaud_on, and then restart the database. Oracle\n Database Upgrade Guide describes how to enable unified auditing. Reference\n V-61625 for information on how to configure a policy to audit account\n modification.\n\n For more information on the configuration of auditing, refer to the following\n documents:\n \"Auditing Database Activity\" in the Oracle Database 2 Day + Security Guide:\n http://docs.oracle.com/database/121/TDPSG/tdpsg_auditing.htm#TDPSG50000\n \"Monitoring Database Activity with Auditing\" in the Oracle Database Security\n Guide:\n http://docs.oracle.com/database/121/DBSEG/part_6.htm#CCHEHCGI\n \"DBMS_AUDIT_MGMT\" in the Oracle Database PL/SQL Packages and Types Reference:\n http://docs.oracle.com/database/121/ARPLS/d_audit_mgmt.htm#ARPLS241\n Oracle Database Upgrade Guide:\n http://docs.oracle.com/database/121/UPGRD/afterup.htm#UPGRD52810" }, - "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-61569' do\n title 'The DBMS must automatically audit account modification.'\n desc \"Once an attacker establishes initial access to a system, they often\n attempt to create a persistent method of re-establishing access. One way to\n accomplish this is for the attacker to simply modify an existing account.\n\n Auditing of account modification is one method and best practice for\n mitigating this risk. A comprehensive application account management process\n ensures an audit trail automatically documents the modification of application\n user accounts and, as required, notifies administrators, application owners,\n and/or appropriate individuals. Applications must provide this capability\n directly, leveraging complementary technology providing this capability or a\n combination thereof.\n\n Automated account auditing processes greatly reduces the risk that accounts\n will be surreptitiously modified and provides logging that can be used for\n forensic purposes.\n\n Note that user authentication and account management should be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP.\n\n However, notwithstanding how accounts are managed, Oracle auditing should\n always be configured to capture account modification.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000027-DB-000186'\n tag \"gid\": 'V-61569'\n tag \"rid\": 'SV-76059r2_rule'\n tag \"stig_id\": 'O121-C2-002300'\n tag \"fix_id\": 'F-67485r3_fix'\n tag \"cci\": ['CCI-001403']\n tag \"nist\": ['AC-2 (4)', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Check Oracle settings (and also OS settings and/or\n enterprise-level authentication/access mechanisms settings) to determine if\n account modification is being audited. If account modification is not being\n audited by Oracle, this is a finding.\n\n If Standard Auditing is used:\n To see if Oracle is configured to capture audit data, enter the following\n SQL*Plus command:\n SHOW PARAMETER AUDIT_TRAIL\n or the following SQL query:\n SELECT * FROM SYS.V$PARAMETER WHERE NAME = 'audit_trail';\n If Oracle returns the value 'NONE', this is a finding.\n\n If Unified Auditing is used:\n To see if Oracle is configured to capture audit data including account\n modification, enter the following SQL*Plus command:\n SELECT ' Account modification is not being audited. '\n FROM dual\n WHERE (SELECT Count(*)\n FROM (select policy_name , audit_option from audit_unified_policies\n WHERE audit_option = 'ALTER USER'\n and policy_name in (select policy_name from\n audit_unified_enabled_policies where user_name='ALL USERS'))) = 0\n OR (SELECT value\n FROM v$option\n WHERE parameter = 'Unified Auditing') != 'TRUE';\n\n If Oracle returns \\\"no rows selected\\\", this is not a finding.\"\n tag \"fix\": \"Configure Oracle to audit account modifications activities.\n\n If Standard Auditing is used:\n Use this process to ensure auditable events are captured:\n ALTER SYSTEM SET AUDIT_TRAIL= SCOPE=SPFILE;\n Audit trail type can be 'OS', 'DB', 'DB,EXTENDED', 'XML' or 'XML,EXTENDED'.\n After executing this statement, it may be necessary to shut down and restart\n the Oracle database.\n\n If Unified Auditing is used:\n To ensure auditable events are captured:\n Link the oracle binary with uniaud_on, and then restart the database. Oracle\n Database Upgrade Guide describes how to enable unified auditing. Reference\n V-61625 for information on how to configure a policy to audit account\n modification.\n\n For more information on the configuration of auditing, refer to the following\n documents:\n \\\"Auditing Database Activity\\\" in the Oracle Database 2 Day + Security Guide:\n http://docs.oracle.com/database/121/TDPSG/tdpsg_auditing.htm#TDPSG50000\n \\\"Monitoring Database Activity with Auditing\\\" in the Oracle Database Security\n Guide:\n http://docs.oracle.com/database/121/DBSEG/part_6.htm#CCHEHCGI\n \\\"DBMS_AUDIT_MGMT\\\" in the Oracle Database PL/SQL Packages and Types Reference:\n http://docs.oracle.com/database/121/ARPLS/d_audit_mgmt.htm#ARPLS241\n Oracle Database Upgrade Guide:\n http://docs.oracle.com/database/121/UPGRD/afterup.htm#UPGRD52810\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n standard_auditing_used = input('standard_auditing_used')\n unified_auditing_used = input('unified_auditing_used')\n\n describe.one do\n describe 'Standard auditing is in use for audit purposes' do\n subject { standard_auditing_used }\n it { should be true }\n end\n\n describe 'Unified auditing is in use for audit purposes' do\n subject { unified_auditing_used }\n it { should be true }\n end\n end\n\n audit_trail = sql.query(\"select value from v$parameter where name = 'audit_trail';\").column('value')\n\n if standard_auditing_used\n describe 'The oracle database audit_trail parameter' do\n subject { audit_trail }\n it { should_not cmp 'NONE' }\n end\n end\n\n unified_auditing = sql.query(\"SELECT value FROM V$OPTION WHERE PARAMETER = 'Unified Auditing';\").column('value')\n\n if unified_auditing_used\n describe 'The oracle database unified auditing parameter' do\n subject { unified_auditing }\n it { should_not cmp 'FALSE' }\n end\n\n unified_auditing_events = sql.query(\"SELECT ' Account modification is not being audited. '\n FROM dual\n WHERE (SELECT Count(*)\n FROM (select policy_name , audit_option from audit_unified_policies\n WHERE audit_option = 'ALTER USER'\n and policy_name in (select policy_name from\n audit_unified_enabled_policies where user_name='ALL USERS'))) = 0\n OR (SELECT value\n FROM v$option\n WHERE parameter = 'Unified Auditing') != 'TRUE';\").column('Account modification is not being audited.').uniq\n\n describe 'The unified auditing data capture for account modification' do\n subject { unified_auditing_events.to_s }\n it { should_not cmp '[nil]' }\n end\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61723.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61569.rb", "line": 1 }, - "id": "V-61723" + "id": "V-61569" }, { - "title": "The DBMS must enforce Discretionary Access Control (DAC) policy\n allowing users to specify and control sharing by named individuals, groups of\n individuals, or by both, limiting propagation of access rights and including or\n excluding access to the granularity of a single user.", - "desc": "Access control policies (e.g., identity-based policies, role-based\n policies, attribute-based policies) and access enforcement mechanisms (e.g.,\n access control lists, access control matrices, cryptography) are employed by\n organizations to control access between users (or processes acting on behalf of\n users) and objects (e.g., devices, files, records, processes, programs,\n domains).\n\n DAC is a type of access control methodology serving as a means of\n restricting access to objects and data based on the identity of subjects and/or\n groups to which they belong. It is discretionary in the sense that application\n users with the appropriate permissions to access an application resource or\n data have the discretion to pass that permission on to another user either\n directly or indirectly.\n\n Data protection requirements may result in a DAC policy being specified as\n part of the application design. Discretionary access controls would be employed\n at the application level to restrict and control access to application objects\n and data thereby providing increased information security for the organization.\n\n When DAC controls are employed, those controls must limit sharing to named\n application users, groups of users, or both. The application DAC controls must\n also limit the propagation of access rights and have the ability to exclude\n access to data down to the granularity of a single user.\n\n Databases using DAC must have the ability for the owner of an object or\n information to assign or revoke rights to view or modify the object or\n information. If the owner of an object or information does not have rights to\n exclude access to an object or information at a user level, users may gain\n access to objects and information they are not authorized to view/modify.", + "title": "Use of the DBMS software installation account must be restricted.", + "desc": "This requirement is intended to limit exposure due to operating from\n within a privileged account or role. The inclusion of role is intended to\n address those situations where an access control policy, such as Role Based\n Access Control (RBAC), is being implemented and where a change of role provides\n the same degree of assurance in the change of access authorizations for both\n the user and all processes acting on behalf of the user as would be provided by\n a change between a privileged and non-privileged account.\n\n To limit exposure when operating from within a privileged account or role,\n the application must support organizational requirements that users of\n information system accounts, or roles, with access to organization-defined\n lists of security functions or security-relevant information, use\n non-privileged accounts, or roles, when accessing other (non-security) system\n functions.\n\n Use of privileged accounts for non-administrative purposes puts data at\n risk of unintended or unauthorized loss, modification, or exposure. In\n particular, DBA accounts if used for non-administration application development\n or application maintenance can lead to miss-assignment of privileges where\n privileges are inherited by object owners. It may also lead to loss or\n compromise of application data where the elevated privileges bypass controls\n designed in and provided by applications.\n\n The DBMS software installation account may require privileges not required\n for database administration or other functions. Use of accounts configured with\n excess privileges may result in the loss or compromise of data or system\n settings due to elevated privileges that bypass controls designed to protect\n them.\n\n This requirement is particularly important because Oracle equates the\n installation account with the SYS account - the super-DBA. Once logged on to\n the operating system, this account can connect to the database AS SYSDBA\n without further authentication. It is very powerful and, by virtue of not\n being linked to any one person, cannot be audited to the level of the\n individual.", "descriptions": { - "default": "Access control policies (e.g., identity-based policies, role-based\n policies, attribute-based policies) and access enforcement mechanisms (e.g.,\n access control lists, access control matrices, cryptography) are employed by\n organizations to control access between users (or processes acting on behalf of\n users) and objects (e.g., devices, files, records, processes, programs,\n domains).\n\n DAC is a type of access control methodology serving as a means of\n restricting access to objects and data based on the identity of subjects and/or\n groups to which they belong. It is discretionary in the sense that application\n users with the appropriate permissions to access an application resource or\n data have the discretion to pass that permission on to another user either\n directly or indirectly.\n\n Data protection requirements may result in a DAC policy being specified as\n part of the application design. Discretionary access controls would be employed\n at the application level to restrict and control access to application objects\n and data thereby providing increased information security for the organization.\n\n When DAC controls are employed, those controls must limit sharing to named\n application users, groups of users, or both. The application DAC controls must\n also limit the propagation of access rights and have the ability to exclude\n access to data down to the granularity of a single user.\n\n Databases using DAC must have the ability for the owner of an object or\n information to assign or revoke rights to view or modify the object or\n information. If the owner of an object or information does not have rights to\n exclude access to an object or information at a user level, users may gain\n access to objects and information they are not authorized to view/modify." + "default": "This requirement is intended to limit exposure due to operating from\n within a privileged account or role. The inclusion of role is intended to\n address those situations where an access control policy, such as Role Based\n Access Control (RBAC), is being implemented and where a change of role provides\n the same degree of assurance in the change of access authorizations for both\n the user and all processes acting on behalf of the user as would be provided by\n a change between a privileged and non-privileged account.\n\n To limit exposure when operating from within a privileged account or role,\n the application must support organizational requirements that users of\n information system accounts, or roles, with access to organization-defined\n lists of security functions or security-relevant information, use\n non-privileged accounts, or roles, when accessing other (non-security) system\n functions.\n\n Use of privileged accounts for non-administrative purposes puts data at\n risk of unintended or unauthorized loss, modification, or exposure. In\n particular, DBA accounts if used for non-administration application development\n or application maintenance can lead to miss-assignment of privileges where\n privileges are inherited by object owners. It may also lead to loss or\n compromise of application data where the elevated privileges bypass controls\n designed in and provided by applications.\n\n The DBMS software installation account may require privileges not required\n for database administration or other functions. Use of accounts configured with\n excess privileges may result in the loss or compromise of data or system\n settings due to elevated privileges that bypass controls designed to protect\n them.\n\n This requirement is particularly important because Oracle equates the\n installation account with the SYS account - the super-DBA. Once logged on to\n the operating system, this account can connect to the database AS SYSDBA\n without further authentication. It is very powerful and, by virtue of not\n being linked to any one person, cannot be audited to the level of the\n individual." }, - "impact": 0.5, + "impact": 0.7, "refs": [], "tags": { - "gtitle": "SRG-APP-000036-DB-000174", - "gid": "V-61577", - "rid": "SV-76067r1_rule", - "stig_id": "O121-C2-003000", - "fix_id": "F-67493r1_fix", - "cci": [ - "CCI-002165" - ], - "nist": [ - "AC-3 (4)", + "gtitle": "SRG-APP-000063-DB-000022", + "gid": "V-61865", + "rid": "SV-76355r2_rule", + "stig_id": "O121-OS-004600", + "fix_id": "F-67781r4_fix", + "cci": [ + "CCI-000366" + ], + "nist": [ + "CM-6 b", "Rev_4" ], "false_negatives": null, @@ -1027,21 +1020,21 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Check DBMS settings to determine if users are able to assign\n and revoke rights to the objects and information that they own. If users cannot\n assign or revoke rights to the objects and information that they own to groups,\n roles, or individual users, this is a finding.", - "fix": "Modify DBMS settings to allow users to assign or revoke access\n rights to objects and information owned by the user. The ability to grant or\n revoke rights must include the ability to grant or revoke those rights down to\n the granularity of a single user.\n\n (Note: In most cases, no fix will be necessary. This is default functionality\n for Oracle.)" + "check": "Review system documentation to identify the installation\n account.\n\n Verify whether the account is used for anything involving interactive activity\n beyond DBMS software installation, upgrade, and maintenance actions.\n\n If the account is used for anything involving interactive activity beyond DBMS\n software installation, upgrade, and maintenance actions, this is a finding.", + "fix": "Restrict interactive use of the DBMS software installation\n account to DBMS software installation, upgrade, and maintenance actions only.\n\n If possible, disable installation accounts when authorized actions are not\n being performed. Otherwise, disable the use of the account(s) for interactive\n activity." }, - "code": "control 'V-61577' do\n title \"The DBMS must enforce Discretionary Access Control (DAC) policy\n allowing users to specify and control sharing by named individuals, groups of\n individuals, or by both, limiting propagation of access rights and including or\n excluding access to the granularity of a single user.\"\n desc \"Access control policies (e.g., identity-based policies, role-based\n policies, attribute-based policies) and access enforcement mechanisms (e.g.,\n access control lists, access control matrices, cryptography) are employed by\n organizations to control access between users (or processes acting on behalf of\n users) and objects (e.g., devices, files, records, processes, programs,\n domains).\n\n DAC is a type of access control methodology serving as a means of\n restricting access to objects and data based on the identity of subjects and/or\n groups to which they belong. It is discretionary in the sense that application\n users with the appropriate permissions to access an application resource or\n data have the discretion to pass that permission on to another user either\n directly or indirectly.\n\n Data protection requirements may result in a DAC policy being specified as\n part of the application design. Discretionary access controls would be employed\n at the application level to restrict and control access to application objects\n and data thereby providing increased information security for the organization.\n\n When DAC controls are employed, those controls must limit sharing to named\n application users, groups of users, or both. The application DAC controls must\n also limit the propagation of access rights and have the ability to exclude\n access to data down to the granularity of a single user.\n\n Databases using DAC must have the ability for the owner of an object or\n information to assign or revoke rights to view or modify the object or\n information. If the owner of an object or information does not have rights to\n exclude access to an object or information at a user level, users may gain\n access to objects and information they are not authorized to view/modify.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000036-DB-000174'\n tag \"gid\": 'V-61577'\n tag \"rid\": 'SV-76067r1_rule'\n tag \"stig_id\": 'O121-C2-003000'\n tag \"fix_id\": 'F-67493r1_fix'\n tag \"cci\": ['CCI-002165']\n tag \"nist\": ['AC-3 (4)', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Check DBMS settings to determine if users are able to assign\n and revoke rights to the objects and information that they own. If users cannot\n assign or revoke rights to the objects and information that they own to groups,\n roles, or individual users, this is a finding.\"\n tag \"fix\": \"Modify DBMS settings to allow users to assign or revoke access\n rights to objects and information owned by the user. The ability to grant or\n revoke rights must include the ability to grant or revoke those rights down to\n the granularity of a single user.\n\n (Note: In most cases, no fix will be necessary. This is default functionality\n for Oracle.)\"\n describe 'A manual review is required to ensure the DBMS enforces Discretionary Access Control (DAC) policy\n allowing users to specify and control sharing by named individuals, groups of\n individuals, or by both, limiting propagation of access rights and including or\n excluding access to the granularity of a single user.' do\n skip 'A manual review is required to ensure the DBMS enforces Discretionary Access Control (DAC) policy\n allowing users to specify and control sharing by named individuals, groups of\n individuals, or by both, limiting propagation of access rights and including or\n excluding access to the granularity of a single user.'\n end\nend\n", + "code": "control 'V-61865' do\n title 'Use of the DBMS software installation account must be restricted.'\n desc \"This requirement is intended to limit exposure due to operating from\n within a privileged account or role. The inclusion of role is intended to\n address those situations where an access control policy, such as Role Based\n Access Control (RBAC), is being implemented and where a change of role provides\n the same degree of assurance in the change of access authorizations for both\n the user and all processes acting on behalf of the user as would be provided by\n a change between a privileged and non-privileged account.\n\n To limit exposure when operating from within a privileged account or role,\n the application must support organizational requirements that users of\n information system accounts, or roles, with access to organization-defined\n lists of security functions or security-relevant information, use\n non-privileged accounts, or roles, when accessing other (non-security) system\n functions.\n\n Use of privileged accounts for non-administrative purposes puts data at\n risk of unintended or unauthorized loss, modification, or exposure. In\n particular, DBA accounts if used for non-administration application development\n or application maintenance can lead to miss-assignment of privileges where\n privileges are inherited by object owners. It may also lead to loss or\n compromise of application data where the elevated privileges bypass controls\n designed in and provided by applications.\n\n The DBMS software installation account may require privileges not required\n for database administration or other functions. Use of accounts configured with\n excess privileges may result in the loss or compromise of data or system\n settings due to elevated privileges that bypass controls designed to protect\n them.\n\n This requirement is particularly important because Oracle equates the\n installation account with the SYS account - the super-DBA. Once logged on to\n the operating system, this account can connect to the database AS SYSDBA\n without further authentication. It is very powerful and, by virtue of not\n being linked to any one person, cannot be audited to the level of the\n individual.\n \"\n impact 0.7\n tag \"gtitle\": 'SRG-APP-000063-DB-000022'\n tag \"gid\": 'V-61865'\n tag \"rid\": 'SV-76355r2_rule'\n tag \"stig_id\": 'O121-OS-004600'\n tag \"fix_id\": 'F-67781r4_fix'\n tag \"cci\": ['CCI-000366']\n tag \"nist\": ['CM-6 b', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Review system documentation to identify the installation\n account.\n\n Verify whether the account is used for anything involving interactive activity\n beyond DBMS software installation, upgrade, and maintenance actions.\n\n If the account is used for anything involving interactive activity beyond DBMS\n software installation, upgrade, and maintenance actions, this is a finding.\"\n tag \"fix\": \"Restrict interactive use of the DBMS software installation\n account to DBMS software installation, upgrade, and maintenance actions only.\n\n If possible, disable installation accounts when authorized actions are not\n being performed. Otherwise, disable the use of the account(s) for interactive\n activity.\"\n describe 'A manual review is required to ensure the use of the DBMS software installation account is restricted' do\n skip 'A manual review is required to ensure the use of the DBMS software installation account is restricted'\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61577.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61865.rb", "line": 1 }, - "id": "V-61577" + "id": "V-61865" }, { - "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.", + "title": "DBMS passwords must not be stored in compiled, encoded, or encrypted\n batch jobs or compiled, encoded, or encrypted application source code.", + "desc": "Password maximum lifetime is the maximum period of time, (typically\n in days) a user's password may be in effect before the user is forced to change\n it.\n\n Passwords need to be changed at specific policy-based intervals as per\n policy. Any password, no matter how complex, can eventually be cracked.\n\n One method of minimizing this risk is to use complex passwords and\n periodically change them. If the application does not limit the lifetime of\n passwords and force users to change their passwords, there is the risk that the\n system and/or application passwords could be compromised.\n\n The storage of passwords in application source or batch job code that is\n compiled, encoded, or encrypted prevents compliance with password expiration\n and other management requirements, as well as provides another means for\n potential discovery.\n\n This requirement applies equally to those accounts managed by Oracle and\n those managed and authenticated by the OS or an enterprise-wide mechanism.\n\n This requirement should not be construed as prohibiting or discouraging the\n encryption of source code, which remains an advisable precaution.\n\n Transport Layer Security (TLS) is the successor protocol to Secure Sockets\n Layer (SSL). Although the Oracle configuration parameters have names including\n 'SSL', such as SSL_VERSION and SSL_CIPHER_SUITES, they refer to TLS.\n\n This calls for inspection of application source code, which will require\n collaboration with the application developers. It is recognized that in many\n cases, the database administrator (DBA) is organizationally separate from the\n application developers and may have limited, if any, access to source code.\n Nevertheless, protections of this type are so important to the secure operation\n of databases that they must not be ignored. At a minimum, the DBA must attempt\n to obtain assurances from the development organization that this issue has been\n addressed and must document what has been discovered.", "descriptions": { - "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." + "default": "Password maximum lifetime is the maximum period of time, (typically\n in days) a user's password may be in effect before the user is forced to change\n it.\n\n Passwords need to be changed at specific policy-based intervals as per\n policy. Any password, no matter how complex, can eventually be cracked.\n\n One method of minimizing this risk is to use complex passwords and\n periodically change them. If the application does not limit the lifetime of\n passwords and force users to change their passwords, there is the risk that the\n system and/or application passwords could be compromised.\n\n The storage of passwords in application source or batch job code that is\n compiled, encoded, or encrypted prevents compliance with password expiration\n and other management requirements, as well as provides another means for\n potential discovery.\n\n This requirement applies equally to those accounts managed by Oracle and\n those managed and authenticated by the OS or an enterprise-wide mechanism.\n\n This requirement should not be construed as prohibiting or discouraging the\n encryption of source code, which remains an advisable precaution.\n\n Transport Layer Security (TLS) is the successor protocol to Secure Sockets\n Layer (SSL). Although the Oracle configuration parameters have names including\n 'SSL', such as SSL_VERSION and SSL_CIPHER_SUITES, they refer to TLS.\n\n This calls for inspection of application source code, which will require\n collaboration with the application developers. It is recognized that in many\n cases, the database administrator (DBA) is organizationally separate from the\n application developers and may have limited, if any, access to source code.\n Nevertheless, protections of this type are so important to the secure operation\n of databases that they must not be ignored. At a minimum, the DBA must attempt\n to obtain assurances from the development organization that this issue has been\n addressed and must document what has been discovered." }, "impact": 0, "refs": [ @@ -1050,16 +1043,16 @@ } ], "tags": { - "gtitle": "SRG-APP-000516-DB-999900", - "gid": "V-61489", - "rid": "SV-75979r1_rule", - "stig_id": "O121-BP-024200", - "fix_id": "F-67405r1_fix", + "gtitle": "SRG-APP-000174-DB-000079", + "gid": "V-61737", + "rid": "SV-76227r3_rule", + "stig_id": "O121-C2-015100", + "fix_id": "F-67653r2_fix", "cci": [ - "CCI-000366" + "CCI-000199" ], "nist": [ - "CM-6 b", + "IA-5 (1) (d)", "Rev_4" ], "false_negatives": null, @@ -1072,36 +1065,39 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "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." + "check": "Review application source code required to be encoded or\n encrypted for database accounts used by applications or batch jobs to access\n the database.\n\n Review source batch job code prior to compiling, encoding, or encrypting for\n database accounts used by applications or the batch jobs themselves to access\n the database.\n\n Determine if the compiled, encoded, or encrypted application source code or\n batch jobs contain passwords used for authentication to the database.\n\n If any of the identified compiled, encoded, or encrypted application source\n code or batch job code do contain passwords used for authentication to the\n database, this is a finding.\n\n - - - - -\n The check would depend on the information provided by the DBA. In a default\n Oracle installation, all passwords are stored in an encrypted manner. Ask the\n DBA if they have created an External Password Store for applications, batch\n jobs, and scripts to use.\n\n Secure External Password Store\n\n Can store password credentials for connecting to databases by using a\n client-side Oracle wallet. An Oracle wallet is a secure software container that\n stores authentication and signing credentials.\n\n This wallet usage can simplify large-scale deployments that rely on password\n credentials for connecting to databases. When this feature is configured,\n application code, batch jobs, and scripts no longer need embedded user names\n and passwords. This reduces risk because the passwords are no longer exposed,\n and password management policies are more easily enforced without changing\n application code whenever user names or passwords change.\n\n The external password store of the wallet is separate from the area where\n public key infrastructure (PKI) credentials are stored. Consequently, cannot\n use Oracle Wallet Manager to manage credentials in the external password store\n of the wallet. Instead, use the command-line utility mkstore to manage these\n credentials.\n\n How Does the External Password Store Work?\n\n Typically, users (and as applications, batch jobs, and scripts) connect to\n databases by using a standard CONNECT statement that specifies a database\n connection string. This string can include a user name and password, and an\n Oracle Net service name identifying the database on an Oracle Database network.\n If the password is omitted, the connection prompts the user for the password.\n\n For example, the service name could be the URL that identifies that database,\n or a TNS alias entered in the tnsnames.ora file in the database. Another\n possibility is a host:port:sid string.\n\n The following examples are standard CONNECT statements that could be used for a\n client that is not configured to use the external password store:\n\n CONNECT salesapp@sales_db.us.example.com\n Enter password: password\n\n CONNECT salesapp@orasales\n Enter password: password\n\n CONNECT salesapp@ourhost37:1527:DB17\n Enter password: password\n\n In these examples, salesapp is the user name, with the unique connection string\n for the database shown as specified in three different ways. Could use its URL\n sales_db.us.example.com, or its TNS alias, orasales, from the tnsnames.ora\n file, or its host:port:sid string.\n\n However, when clients are configured to use the secure external password store,\n applications can connect to a database with the following CONNECT statement\n syntax, without specifying database logon credentials:\n\n CONNECT /@db_connect_string\n\n CONNECT /@db_connect_string AS SYSDBA\n\n CONNECT /@db_connect_string AS SYSOPER\n\n In this specification, db_connect_string is a valid connection string to access\n the intended database, such as the service name, URL, or alias as shown in the\n earlier examples. Each user account must have its own unique connection string;\n cannot create one connection string for multiple users.\n\n In this case, the database credentials, user name and password, are securely\n stored in an Oracle wallet created for this purpose. The autologon feature of\n this wallet is turned on, so the system does not need a password to open the\n wallet. From the wallet, it gets the credentials to access the database for the\n user they represent.", + "fix": "Design DBMS application code and batch job code that is compiled,\n encoded or encrypted, to NOT contain passwords.\n\n - - - - -\n Oracle provides the capability to provide for a secure external password\n facility. Use the Oracle mkstore to create a secure storage area for passwords\n for applications, batch jobs, and scripts to use or deploy a site-authorized\n facility to perform this function.\n\n Check to see what has been stored in the Oracle External Password Store\n\n To view all contents of a client wallet external password store, check specific\n credentials by viewing them. Listing the external password store contents\n provides information can use to decide whether to add or delete credentials\n from the store. To list the contents of the external password store, enter the\n following command at the command line:\n\n $ mkstore -wrl wallet_location -listCredential\n\n For example:\n\n $ mkstore -wrl c:\\oracle\\product\\12.1.0\\db_1\\wallets -listCredential\n\n The wallet_location specifies the path to the directory where the wallet, whose\n external password store contents is to be viewed, is located. This command\n lists all of the credential database service names (aliases) and the\n corresponding user name (schema) for that database. Passwords are not listed.\n\n Configuring Clients to Use the External Password Store\n\n If the client is already configured to use external authentication, such as\n Windows native authentication or Transport Layer Security (TLS), then Oracle\n Database uses that authentication method. The same credentials used for this\n type of authentication are typically also used to log on to the database.\n\n For clients not using such authentication methods or wanting to override them\n for database authentication, can set the SQLNET.WALLET_OVERRIDE parameter in\n sqlnet.ora to TRUE. The default value for SQLNET.WALLET_OVERRIDE is FALSE,\n allowing standard use of authentication credentials as before.\n\n If wanting a client to use the secure external password store feature, then\n perform the following configuration task:\n\n 1. Create a wallet on the client by using the following syntax at the command\n line:\n\n mkstore -wrl wallet_location -create\n\n For example:\n\n mkstore -wrl c:\\oracle\\product\\12.1.0\\db_1\\wallets -create\n Enter password: password\n\n The wallet_location is the path to the directory where the wallet is to be\n created and stored. This command creates an Oracle wallet with the autologon\n feature enabled at the location specified. The autologon feature enables the\n client to access the wallet contents without supplying a password.\n\n The mkstore utility -create option uses password complexity verification.\n\n 2. Create database connection credentials in the wallet by using the following\n syntax at the command line:\n\n mkstore -wrl wallet_location -createCredential db_connect_string username\n Enter password: password\n\n For example:\n\n mkstore -wrl c:\\oracle\\product\\12.1.0\\db_1\\wallets -createCredential\n oracle system\n Enter password: password\n\n In this specification:\n\n The wallet_location is the path to the directory where the wallet was created.\n The db_connect_string used in the CONNECT /@db_connect_string statement must be\n identical to the db_connect_string specified in the -createCredential command.\n\n The db_connect_string is the TNS alias used to specify the database in the\n tnsnames.ora file or any service name used to identify the database on an\n Oracle network. By default, tnsnames.ora is located in the\n $ORACLE_HOME/network/admin directory on UNIX systems and in ORACLE_HOME etwork\\admin on Windows.\n\n The username is the database logon credential. When prompted, enter the\n password for this user.\n\n 3. In the client sqlnet.ora file, enter the WALLET_LOCATION parameter and set\n it to the directory location of the wallet created in Step 1. For example, if\n the wallet was created in\n $ORACLE_HOME/network/admin and Oracle home is set to /private/ora12,\n then need to enter the following into your client sqlnet.ora file:\n\n WALLET_LOCATION =\n (SOURCE =\n (METHOD = FILE)\n (METHOD_DATA =\n (DIRECTORY = /private/ora12/network/admin)\n )\n )\n\n 4. In the client sqlnet.ora file, enter the SQLNET.WALLET_OVERRIDE parameter\n and set it to TRUE as follows:\n\n SQLNET.WALLET_OVERRIDE = TRUE\n\n setting causes all CONNECT /@db_connect_string statements to use the\n information in the wallet at the specified location to authenticate to\n databases.\n\n When external authentication is in use, an authenticated user with such a\n wallet can use the CONNECT /@db_connect_string syntax to access the previously\n specified databases without providing a user name and password. However, if a\n user fails that external authentication, then these connect statements also\n fail.\n\n Below is a sample sqlnet.ora file with the WALLET_LOCATION and the\n SQLNET.WALLET_OVERRIDE parameters set as described in Steps 3 and 4.\n\n Below is a sample SQLNET.ORA File with Wallet Parameters Set\n\n WALLET_LOCATION =\n (SOURCE =\n (METHOD = FILE)\n (METHOD_DATA =\n (DIRECTORY = /private/ora12/network/admin)\n )\n )\n\n SQLNET.WALLET_OVERRIDE = TRUE\n SSL_CLIENT_AUTHENTICATION = FALSE\n SSL_VERSION = 1.2 or 1.1\n\n Note: \"SSL_VERSION = 1.2 or 1.1\" is the actual value, not a suggestion to\n use one or the other.\n\n (Note: this assumes that a single sqlnet.ora file, in the default location, is\n in use. Please see the supplemental file, \"Non-default sqlnet.ora\n configurations.pdf\" for how to find multiple and/or differently-located\n sqlnet.ora files.)" }, - "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", + "code": " control 'V-61737' do\n impact 0.0\n describe 'This control is not applicable on oracle within aws rds, as aws manages the operating system in which the oracle database is running on' do\n skip 'This control is not applicable on oracle within aws rds, as aws manages the operating system in which the oracle database is running on'\n end\n end\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61489.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61737.rb", "line": 1 }, - "id": "V-61489" + "id": "V-61737" }, { - "title": "The DBMS must protect the audit records generated, as a result of\n remote access to privileged accounts, and the execution of privileged\n functions.", - "desc": "Protection of audit records and audit data is of critical importance.\n Care must be taken to ensure privileged users cannot circumvent audit\n protections put in place.\n\n Auditing might not be reliable when performed by an information system\n which the user being audited has privileged access to.\n\n The privileged user could inhibit auditing or directly modify audit\n records. To prevent this from occurring, privileged access shall be further\n defined between audit-related privileges and other privileges, thus limiting\n the users with audit-related privileges.\n\n Reducing the risk of audit compromises by privileged users can also be\n achieved, for example, by performing audit activity on a separate information\n system where the user in question has limited access or by using storage media\n that cannot be modified (e.g., write-once recording devices).\n\n If an attacker were to gain access to audit tools he could analyze audit\n logs for system weaknesses or weaknesses in the auditing itself. An attacker\n could also manipulate logs to hide evidence of malicious activity.", + "title": "The DBMS must use multifactor authentication for local access to\n privileged accounts.", + "desc": "Multifactor authentication is defined as using two or more factors to\n achieve authentication.\n\n Factors include:\n (i) Something a user knows (e.g., password/PIN);\n (ii) Something a user has (e.g., cryptographic identification device,\n token); or\n (iii) Something a user is (e.g., biometric).\n\n A privileged account is defined as an information system account with\n authorizations of a privileged user.\n\n Local Access is defined as access to an organizational information system\n by a user (or process acting on behalf of a user) communicating through a\n direct connection without the use of a network.\n\n The lack of multifactor authentication makes it much easier for an attacker\n to gain unauthorized access to a system.\n\n Transport Layer Security (TLS) is the successor protocol to Secure Sockets\n Layer (SSL). Although the Oracle configuration parameters have names including\n 'SSL', such as SSL_VERSION and SSL_CIPHER_SUITES, they refer to TLS.", "descriptions": { - "default": "Protection of audit records and audit data is of critical importance.\n Care must be taken to ensure privileged users cannot circumvent audit\n protections put in place.\n\n Auditing might not be reliable when performed by an information system\n which the user being audited has privileged access to.\n\n The privileged user could inhibit auditing or directly modify audit\n records. To prevent this from occurring, privileged access shall be further\n defined between audit-related privileges and other privileges, thus limiting\n the users with audit-related privileges.\n\n Reducing the risk of audit compromises by privileged users can also be\n achieved, for example, by performing audit activity on a separate information\n system where the user in question has limited access or by using storage media\n that cannot be modified (e.g., write-once recording devices).\n\n If an attacker were to gain access to audit tools he could analyze audit\n logs for system weaknesses or weaknesses in the auditing itself. An attacker\n could also manipulate logs to hide evidence of malicious activity." + "default": "Multifactor authentication is defined as using two or more factors to\n achieve authentication.\n\n Factors include:\n (i) Something a user knows (e.g., password/PIN);\n (ii) Something a user has (e.g., cryptographic identification device,\n token); or\n (iii) Something a user is (e.g., biometric).\n\n A privileged account is defined as an information system account with\n authorizations of a privileged user.\n\n Local Access is defined as access to an organizational information system\n by a user (or process acting on behalf of a user) communicating through a\n direct connection without the use of a network.\n\n The lack of multifactor authentication makes it much easier for an attacker\n to gain unauthorized access to a system.\n\n Transport Layer Security (TLS) is the successor protocol to Secure Sockets\n Layer (SSL). Although the Oracle configuration parameters have names including\n 'SSL', such as SSL_VERSION and SSL_CIPHER_SUITES, they refer to TLS." }, "impact": 0, - "refs": [], + "refs": [ + { + "ref": [] + } + ], "tags": { - "gtitle": "SRG-APP-000127-DB-000172", - "gid": "V-61669", - "rid": "SV-76159r1_rule", - "stig_id": "O121-C2-010200", - "fix_id": "F-67583r1_fix", + "gtitle": "SRG-APP-000151-DB-000106", + "gid": "V-61707", + "rid": "SV-76197r2_rule", + "stig_id": "O121-C2-013100", + "fix_id": "F-67623r1_fix", "cci": [ - "CCI-000366", - "CCI-001351" + "CCI-000767" ], "nist": [ - "AU-9 (4)", + "IA-2 (3)", "Rev_4" ], "false_negatives": null, @@ -1114,35 +1110,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "If Standard Auditing is used:\n For table-based auditing (DB or DB,EXTENDED), review the DBMS permissions on\n the views and base tables holding the audit data.\n\n For file-based auditing (OS, XML, or XML,EXTENDED), review the operating\n system/file system permissions on the audit file(s).\n\n If permissions exist that enable unauthorized users to view audit data, this is\n a finding.\n\n If permissions exist that enable any user (other than an account created\n specifically to manage log space and off-load audit records to a log management\n system) to modify or delete audit records, or create spurious audit records,\n this is a finding.\n\n If Unified Auditing is used:\n AUDIT_ADMIN role. This role enables the creation of unified and fine-grained\n audit policies, use the AUDIT and NOAUDIT SQL statements, view audit data, and\n manage the audit trail administration. Grant this role only to trusted users.\n\n\n\n\n AUDIT_VIEWER role. This role enables users to view and analyze audit data. The\n kind of user who needs this role is typically an external auditor.\n\n Check to ensure the authorized users have the correct roles. If permissions\n exist that enable unauthorized users to view audit data, this is a finding.\n\n If permissions exist that enable any user (other than an account created\n specifically to manage log space and off-load audit records to a log management\n system) to modify or delete audit records, or create spurious audit records,\n this is a finding.", - "fix": "If Standard Auditing is used:\n Add controls and modify permissions to protect database audit log records from\n modification, deletion, spurious creation, or unauthorized viewing.\n\n If Unified Auditing is used:\n Grant the correct Audit roles to authorized users." + "check": "Review DBMS settings, OS settings, and/or enterprise-level\n authentication/access mechanism settings to determine whether users logging on\n to privileged accounts locally are required to use multifactor authentication.\n\n If users logging on to privileged accounts locally are not required to use\n multifactor authentication, this is a finding.\n\n Use authentication to prove the identities of users who are attempting to log\n on to the database. Authenticating user identity is imperative in distributed\n environments, without which there can be little confidence in network security.\n Passwords are the most common means of authentication. Oracle Database enables\n strong authentication with Oracle authentication adapters that support various\n third-party authentication services, including TLS with digital certificates.\n\n If the $ORACLE_HOME/network/admin/sqlnet.ora contains entries similar to the\n following, TLS is enabled.\n (Note: This assumes that a single sqlnet.ora file, in the default location, is\n in use. Please see the supplemental file \"Non-default sqlnet.ora\n configurations.pdf\" for how to find multiple and/or differently located\n sqlnet.ora files.)\n\n SQLNET.AUTHENTICATION_SERVICES= (BEQ, TCPS)\n SSL_VERSION = 1.2 or 1.1\n SSL_CLIENT_AUTHENTICATION = TRUE\n WALLET_LOCATION =\n (SOURCE =\n (METHOD = FILE)\n (METHOD_DATA =\n (DIRECTORY = /u01/app/oracle/product/12.1.0/dbhome_1/owm/wallets)\n )\n )\n\n SSL_CIPHER_SUITES= (SSL_RSA_WITH_AES_256_CBC_SHA384)\n ADR_BASE = /u01/app/oracle\n\n Note: \"SSL_VERSION = 1.2 or 1.1\" is the actual value, not a suggestion to\n use one or the other.", + "fix": "Configure DBMS, OS and/or enterprise-level authentication/access\n mechanism to require multifactor authentication for local users logging on to\n privileged accounts.\n\n If appropriate, enable support for Transport Layer Security (TLS) protocols and\n multifactor authentication through the use of Smart Cards (CAC/PIV)." }, - "code": "control 'V-61669' do\n title \"The DBMS must protect the audit records generated, as a result of\n remote access to privileged accounts, and the execution of privileged\n functions.\"\n desc \"Protection of audit records and audit data is of critical importance.\n Care must be taken to ensure privileged users cannot circumvent audit\n protections put in place.\n\n Auditing might not be reliable when performed by an information system\n which the user being audited has privileged access to.\n\n The privileged user could inhibit auditing or directly modify audit\n records. To prevent this from occurring, privileged access shall be further\n defined between audit-related privileges and other privileges, thus limiting\n the users with audit-related privileges.\n\n Reducing the risk of audit compromises by privileged users can also be\n achieved, for example, by performing audit activity on a separate information\n system where the user in question has limited access or by using storage media\n that cannot be modified (e.g., write-once recording devices).\n\n If an attacker were to gain access to audit tools he could analyze audit\n logs for system weaknesses or weaknesses in the auditing itself. An attacker\n could also manipulate logs to hide evidence of malicious activity.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000127-DB-000172'\n tag \"gid\": 'V-61669'\n tag \"rid\": 'SV-76159r1_rule'\n tag \"stig_id\": 'O121-C2-010200'\n tag \"fix_id\": 'F-67583r1_fix'\n tag \"cci\": ['CCI-000366', 'CCI-001351']\n tag \"nist\": ['CM-6 b', 'Rev_4']\n tag \"nist\": ['AU-9 (4)', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"If Standard Auditing is used:\n For table-based auditing (DB or DB,EXTENDED), review the DBMS permissions on\n the views and base tables holding the audit data.\n\n For file-based auditing (OS, XML, or XML,EXTENDED), review the operating\n system/file system permissions on the audit file(s).\n\n If permissions exist that enable unauthorized users to view audit data, this is\n a finding.\n\n If permissions exist that enable any user (other than an account created\n specifically to manage log space and off-load audit records to a log management\n system) to modify or delete audit records, or create spurious audit records,\n this is a finding.\n\n If Unified Auditing is used:\n AUDIT_ADMIN role. This role enables the creation of unified and fine-grained\n audit policies, use the AUDIT and NOAUDIT SQL statements, view audit data, and\n manage the audit trail administration. Grant this role only to trusted users.\n\n\n\n\n AUDIT_VIEWER role. This role enables users to view and analyze audit data. The\n kind of user who needs this role is typically an external auditor.\n\n Check to ensure the authorized users have the correct roles. If permissions\n exist that enable unauthorized users to view audit data, this is a finding.\n\n If permissions exist that enable any user (other than an account created\n specifically to manage log space and off-load audit records to a log management\n system) to modify or delete audit records, or create spurious audit records,\n this is a finding.\"\n tag \"fix\": \"If Standard Auditing is used:\n Add controls and modify permissions to protect database audit log records from\n modification, deletion, spurious creation, or unauthorized viewing.\n\n If Unified Auditing is used:\n Grant the correct Audit roles to authorized users.\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n users_allowed_access_to_audit_info = sql.query(\"SELECT GRANTEE, TABLE_NAME, PRIVILEGE\n FROM DBA_TAB_PRIVS where owner='AUDSYS';\").column('grantee').uniq\n if users_allowed_access_to_audit_info.empty?\n impact 0.0\n describe 'There are no oracle users allowed access to audit information, control N/A' do\n skip 'There are no oracle users allowed access to audit information'\n end\n else\n users_allowed_access_to_audit_info.each do |user|\n describe \"oracle users: #{user} allowed access to audit information\" do\n subject { user }\n it { should be_in input('allowed_audit_users') }\n end\n end\n end\nend\n", + "code": " control 'V-61707' do\n impact 0.0\n describe 'This control is not applicable on oracle within aws rds, as aws manages the operating system in which the oracle database is running on' do\n skip 'This control is not applicable on oracle within aws rds, as aws manages the operating system in which the oracle database is running on'\n end\n end\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61669.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61707.rb", "line": 1 }, - "id": "V-61669" + "id": "V-61707" }, { - "title": "The system must employ automated mechanisms for supporting Oracle user\n account management.", - "desc": "A comprehensive application account management process that includes\n automation helps to ensure accounts designated as requiring attention are\n consistently and promptly addressed. Examples include, but are not limited to,\n using automation to take action on multiple accounts designated as inactive,\n suspended, or terminated, or by disabling accounts located in non-centralized\n account stores, such as multiple servers.\n\n Enterprise environments make application user account management\n challenging and complex. A user management process requiring administrators to\n manually address account management functions adds risk of potential oversight.\n\n Automated mechanisms may be comprised of differing technologies that when\n placed together contain an overall automated mechanism supporting an\n organization's automated account management requirements.\n\n Databases can have large numbers of users in disparate locations and job\n functions. Automatic account management can help mitigate the risk of human\n error found in manually managing database access.\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 DBMS must ensure remote sessions that access an\n organization-defined list of security functions and security-relevant\n information are audited.", + "desc": "Remote access is any access to an organizational information system by\n a user (or an information system) communicating through an external,\n non-organization-controlled network (e.g., the Internet). Examples of remote\n access methods include dial-up, broadband, and wireless.\n\n Remote network and system access is accomplished by leveraging common\n communication protocols to establish a remote connection. These connections\n will typically originate over either the public Internet or the Public Switched\n Telephone Network (PSTN). Neither of these internetworking mechanisms is\n private or secure and they do not by default restrict access to networked\n resources once connectivity is established.\n\n Numerous best practices are employed to protect remote connections, such as\n utilizing encryption to protect data sessions and firewalls to restrict and\n control network connectivity. In addition to these protections, auditing must\n also be utilized in order to track system activity, assist in diagnosing system\n issues, and provide evidence needed for forensic investigations after a\n security incident.\n\n When organizations define security-related application functions or\n security-related application information, it is incumbent upon the application\n providing access to that data to ensure auditing of remote connectivity to\n those resources occurs in support of organizational requirements\n\n Remote access to security functions (e.g., user management, audit log\n management, etc.) and security-relevant information requires the activity be\n audited by the organization. Any application providing remote access must\n support organizational requirements to audit access or organization-defined\n security functions and security-relevant information.\n\n Database security features accessed through remote methods must be audited\n to ensure the access is authorized and appropriate.", "descriptions": { - "default": "A comprehensive application account management process that includes\n automation helps to ensure accounts designated as requiring attention are\n consistently and promptly addressed. Examples include, but are not limited to,\n using automation to take action on multiple accounts designated as inactive,\n suspended, or terminated, or by disabling accounts located in non-centralized\n account stores, such as multiple servers.\n\n Enterprise environments make application user account management\n challenging and complex. A user management process requiring administrators to\n manually address account management functions adds risk of potential oversight.\n\n Automated mechanisms may be comprised of differing technologies that when\n placed together contain an overall automated mechanism supporting an\n organization's automated account management requirements.\n\n Databases can have large numbers of users in disparate locations and job\n functions. Automatic account management can help mitigate the risk of human\n error found in manually managing database access.\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": "Remote access is any access to an organizational information system by\n a user (or an information system) communicating through an external,\n non-organization-controlled network (e.g., the Internet). Examples of remote\n access methods include dial-up, broadband, and wireless.\n\n Remote network and system access is accomplished by leveraging common\n communication protocols to establish a remote connection. These connections\n will typically originate over either the public Internet or the Public Switched\n Telephone Network (PSTN). Neither of these internetworking mechanisms is\n private or secure and they do not by default restrict access to networked\n resources once connectivity is established.\n\n Numerous best practices are employed to protect remote connections, such as\n utilizing encryption to protect data sessions and firewalls to restrict and\n control network connectivity. In addition to these protections, auditing must\n also be utilized in order to track system activity, assist in diagnosing system\n issues, and provide evidence needed for forensic investigations after a\n security incident.\n\n When organizations define security-related application functions or\n security-related application information, it is incumbent upon the application\n providing access to that data to ensure auditing of remote connectivity to\n those resources occurs in support of organizational requirements\n\n Remote access to security functions (e.g., user management, audit log\n management, etc.) and security-relevant information requires the activity be\n audited by the organization. Any application providing remote access must\n support organizational requirements to audit access or organization-defined\n security functions and security-relevant information.\n\n Database security features accessed through remote methods must be audited\n to ensure the access is authorized and appropriate." }, "impact": 0.5, "refs": [], "tags": { - "gtitle": "SRG-APP-000023-DB-000001", - "gid": "V-61557", - "rid": "SV-76047r2_rule", - "stig_id": "O121-C2-001800", - "fix_id": "F-67473r2_fix", + "gtitle": "SRG-APP-000019-DB-000197", + "gid": "V-61553", + "rid": "SV-76043r1_rule", + "stig_id": "O121-C2-001600", + "fix_id": "F-67469r1_fix", "cci": [ - "CCI-000015" + "CCI-002186" ], "nist": [ - "AC-2 (1)", + "AC-3 (10)", "Rev_4" ], "false_negatives": null, @@ -1155,35 +1151,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "If all user accounts are authenticated by the OS or an\n enterprise-level authentication/access mechanism, and not by Oracle, this is\n not a finding.\n\n If an Oracle feature/product, an OS feature, a third-party product, or custom\n code is used to automate account management, this is not a finding.\n\n Determine what the site-defined definition of an acceptably small level of\n manual account-management activity is. If the site has established the\n definition, documented it, and obtained ISSO-ISSM-AO approval, use that\n definition. If not, use the following rule of thumb as the definition: no\n more than 12 such accounts exist or are expected to exist; no more than 100\n manual account-management actions (account creation, modification, locking,\n unlocking, removal and the like) are expected to occur in the course of a year.\n\n If the amount of account management activity is small, as defined in the\n preceding paragraph, this is not a finding.\n\n Otherwise, this is a finding.", - "fix": "Utilize an Oracle feature/product, an OS feature, a third-party\n product, or custom code to automate some or all account maintenance\n functionality.\n\n - - - - -\n\n Roles and Profiles are two Oracle features that should be employed in account\n management. (Indeed, other requirements mandate the use of Roles.) Following\n are some notes from Oracle on the use of Profiles.\n\n A profile is a named set of resource limits and password parameters that\n restrict database usage and instance resources for a user. You can assign a\n profile to each user, and a default profile to all others. Each user can have\n only one profile, and creating a new one supersedes any earlier one.\n\n Profile resource limits are enforced only when you enable resource limitation\n for the associated database. Enabling such limitation can occur either before\n starting up the database (the RESOURCE_LIMIT initialization parameter) or while\n it is open (using an ALTER SYSTEM statement).\n\n While password parameters reside in profiles, they are unaffected by\n RESOURCE_LIMIT or ALTER SYSTEM and password management is always enabled." + "check": "Verify, using vendor and system documentation if necessary,\n that the DBMS is configured to use Oracle's auditing features, or that a\n third-party product or custom code is deployed and configured to satisfy this\n requirement.\n\n If a third-party product or custom code is used, compare its current\n configuration with the audit requirements. If any of the requirements is not\n covered by the configuration, this is a finding.\n\n The remainder of this Check is applicable specifically where Oracle auditing is\n in use.\n\n If Standard Auditing is used:\n To see if Oracle is configured to capture audit data, enter the following\n SQL*Plus command:\n SHOW PARAMETER AUDIT_TRAIL\n or the following SQL query:\n SELECT * FROM SYS V$PARAMETER WHERE NAME = 'audit_trail';\n select value from v$parameter where name='audit_trail';\n If Oracle returns the value 'NONE', this is a finding.\n\n To confirm that Oracle audit is capturing information on the required events,\n review the contents of the SYS.AUD$ table or the audit file, whichever is in\n use. If auditable events are not listed, this is a finding.\n\n If Unified Auditing is used:\n To see if Oracle is configured to capture audit data, enter the following\n SQL*Plus command:\n SELECT * FROM V$OPTION WHERE PARAMETER = 'Unified Auditing';\n If Oracle returns the value 'TRUE', this is not a finding.\n\n To confirm that Oracle audit is capturing information on the required events,\n review the contents of the SYS.UNIFIED_AUDIT_TRAIL view. If auditable events\n are not listed, this is a finding.", + "fix": "Configure the DBMS's auditing to audit organization-defined\n auditable events. If preferred, use a third-party tool. The tool must provide\n the minimum capability to audit the required events.\n\n If using a third-party product, proceed in accordance with the product\n documentation. If using Oracle's capabilities, proceed as follows.\n\n If Standard Auditing is used:\n Use this process to ensure auditable events are captured:\n ALTER SYSTEM SET AUDIT_TRAIL= SCOPE=SPFILE;\n Audit trail type can be 'OS', 'DB', 'DB,EXTENDED', 'XML' or 'XML,EXTENDED'.\n After executing this statement, it may be necessary to shut down and restart\n the Oracle database.\n\n If the site-specific audit requirements are not covered by the default audit\n options, deploy and configure Fine-Grained Auditing. For details, refer to\n Oracle documentation at the locations below.\n\n If Unified Auditing is used:\n Use this process to ensure auditable events are captured:\n Link the oracle binary with uniaud_on, and then restart the database. Oracle\n Database Upgrade Guide describes how to enable unified auditing.\n\n For more information on the configuration of auditing, refer to the following\n documents:\n \"Auditing Database Activity\" in the Oracle Database 2 Day + Security Guide:\n http://docs.oracle.com/database/121/TDPSG/tdpsg_auditing.htm#TDPSG50000\n \"Monitoring Database Activity with Auditing\" in the Oracle Database Security\n Guide:\n http://docs.oracle.com/database/121/DBSEG/part_6.htm#CCHEHCGI\n \"DBMS_AUDIT_MGMT\" in the Oracle Database PL/SQL Packages and Types Reference:\n http://docs.oracle.com/database/121/ARPLS/d_audit_mgmt.htm#ARPLS241\n Oracle Database Upgrade Guide:\n http://docs.oracle.com/database/121/UPGRD/afterup.htm#UPGRD52810\n\n If the site-specific audit requirements are not covered by the default audit\n options, deploy and configure Fine-Grained Auditing. For details, refer to\n Oracle documentation at the locations above." }, - "code": "control 'V-61557' do\n title \"The system must employ automated mechanisms for supporting Oracle user\n account management.\"\n desc \"A comprehensive application account management process that includes\n automation helps to ensure accounts designated as requiring attention are\n consistently and promptly addressed. Examples include, but are not limited to,\n using automation to take action on multiple accounts designated as inactive,\n suspended, or terminated, or by disabling accounts located in non-centralized\n account stores, such as multiple servers.\n\n Enterprise environments make application user account management\n challenging and complex. A user management process requiring administrators to\n manually address account management functions adds risk of potential oversight.\n\n Automated mechanisms may be comprised of differing technologies that when\n placed together contain an overall automated mechanism supporting an\n organization's automated account management requirements.\n\n Databases can have large numbers of users in disparate locations and job\n functions. Automatic account management can help mitigate the risk of human\n error found in manually managing database access.\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-000023-DB-000001'\n tag \"gid\": 'V-61557'\n tag \"rid\": 'SV-76047r2_rule'\n tag \"stig_id\": 'O121-C2-001800'\n tag \"fix_id\": 'F-67473r2_fix'\n tag \"cci\": ['CCI-000015']\n tag \"nist\": ['AC-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\": \"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 If an Oracle feature/product, an OS feature, a third-party product, or custom\n code is used to automate account management, this is not a finding.\n\n Determine what the site-defined definition of an acceptably small level of\n manual account-management activity is. If the site has established the\n definition, documented it, and obtained ISSO-ISSM-AO approval, use that\n definition. If not, use the following rule of thumb as the definition: no\n more than 12 such accounts exist or are expected to exist; no more than 100\n manual account-management actions (account creation, modification, locking,\n unlocking, removal and the like) are expected to occur in the course of a year.\n\n If the amount of account management activity is small, as defined in the\n preceding paragraph, this is not a finding.\n\n Otherwise, this is a finding.\"\n tag \"fix\": \"Utilize an Oracle feature/product, an OS feature, a third-party\n product, or custom code to automate some or all account maintenance\n functionality.\n\n - - - - -\n\n Roles and Profiles are two Oracle features that should be employed in account\n management. (Indeed, other requirements mandate the use of Roles.) Following\n are some notes from Oracle on the use of Profiles.\n\n A profile is a named set of resource limits and password parameters that\n restrict database usage and instance resources for a user. You can assign a\n profile to each user, and a default profile to all others. Each user can have\n only one profile, and creating a new one supersedes any earlier one.\n\n Profile resource limits are enforced only when you enable resource limitation\n for the associated database. Enabling such limitation can occur either before\n starting up the database (the RESOURCE_LIMIT initialization parameter) or while\n it is open (using an ALTER SYSTEM statement).\n\n While password parameters reside in profiles, they are unaffected by\n RESOURCE_LIMIT or ALTER SYSTEM and password management is always enabled.\"\n describe 'A manual review is required to ensure the system must employs automated mechanisms for supporting Oracle user\n account management' do\n skip 'A manual review is required to ensure the system must employs automated mechanisms for supporting Oracle user\n account management'\n end\nend\n", + "code": "control 'V-61553' do\n title \"The DBMS must ensure remote sessions that access an\n organization-defined list of security functions and security-relevant\n information are audited.\"\n desc \"Remote access is any access to an organizational information system by\n a user (or an information system) communicating through an external,\n non-organization-controlled network (e.g., the Internet). Examples of remote\n access methods include dial-up, broadband, and wireless.\n\n Remote network and system access is accomplished by leveraging common\n communication protocols to establish a remote connection. These connections\n will typically originate over either the public Internet or the Public Switched\n Telephone Network (PSTN). Neither of these internetworking mechanisms is\n private or secure and they do not by default restrict access to networked\n resources once connectivity is established.\n\n Numerous best practices are employed to protect remote connections, such as\n utilizing encryption to protect data sessions and firewalls to restrict and\n control network connectivity. In addition to these protections, auditing must\n also be utilized in order to track system activity, assist in diagnosing system\n issues, and provide evidence needed for forensic investigations after a\n security incident.\n\n When organizations define security-related application functions or\n security-related application information, it is incumbent upon the application\n providing access to that data to ensure auditing of remote connectivity to\n those resources occurs in support of organizational requirements\n\n Remote access to security functions (e.g., user management, audit log\n management, etc.) and security-relevant information requires the activity be\n audited by the organization. Any application providing remote access must\n support organizational requirements to audit access or organization-defined\n security functions and security-relevant information.\n\n Database security features accessed through remote methods must be audited\n to ensure the access is authorized and appropriate.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000019-DB-000197'\n tag \"gid\": 'V-61553'\n tag \"rid\": 'SV-76043r1_rule'\n tag \"stig_id\": 'O121-C2-001600'\n tag \"fix_id\": 'F-67469r1_fix'\n tag \"cci\": ['CCI-002186']\n tag \"nist\": ['AC-3 (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\": \"Verify, using vendor and system documentation if necessary,\n that the DBMS is configured to use Oracle's auditing features, or that a\n third-party product or custom code is deployed and configured to satisfy this\n requirement.\n\n If a third-party product or custom code is used, compare its current\n configuration with the audit requirements. If any of the requirements is not\n covered by the configuration, this is a finding.\n\n The remainder of this Check is applicable specifically where Oracle auditing is\n in use.\n\n If Standard Auditing is used:\n To see if Oracle is configured to capture audit data, enter the following\n SQL*Plus command:\n SHOW PARAMETER AUDIT_TRAIL\n or the following SQL query:\n SELECT * FROM SYS V$PARAMETER WHERE NAME = 'audit_trail';\n select value from v$parameter where name='audit_trail';\n If Oracle returns the value 'NONE', this is a finding.\n\n To confirm that Oracle audit is capturing information on the required events,\n review the contents of the SYS.AUD$ table or the audit file, whichever is in\n use. If auditable events are not listed, this is a finding.\n\n If Unified Auditing is used:\n To see if Oracle is configured to capture audit data, enter the following\n SQL*Plus command:\n SELECT * FROM V$OPTION WHERE PARAMETER = 'Unified Auditing';\n If Oracle returns the value 'TRUE', this is not a finding.\n\n To confirm that Oracle audit is capturing information on the required events,\n review the contents of the SYS.UNIFIED_AUDIT_TRAIL view. If auditable events\n are not listed, this is a finding.\"\n tag \"fix\": \"Configure the DBMS's auditing to audit organization-defined\n auditable events. If preferred, use a third-party tool. The tool must provide\n the minimum capability to audit the required events.\n\n If using a third-party product, proceed in accordance with the product\n documentation. If using Oracle's capabilities, proceed as follows.\n\n If Standard Auditing is used:\n Use this process to ensure auditable events are captured:\n ALTER SYSTEM SET AUDIT_TRAIL= SCOPE=SPFILE;\n Audit trail type can be 'OS', 'DB', 'DB,EXTENDED', 'XML' or 'XML,EXTENDED'.\n After executing this statement, it may be necessary to shut down and restart\n the Oracle database.\n\n If the site-specific audit requirements are not covered by the default audit\n options, deploy and configure Fine-Grained Auditing. For details, refer to\n Oracle documentation at the locations below.\n\n If Unified Auditing is used:\n Use this process to ensure auditable events are captured:\n Link the oracle binary with uniaud_on, and then restart the database. Oracle\n Database Upgrade Guide describes how to enable unified auditing.\n\n For more information on the configuration of auditing, refer to the following\n documents:\n \\\"Auditing Database Activity\\\" in the Oracle Database 2 Day + Security Guide:\n http://docs.oracle.com/database/121/TDPSG/tdpsg_auditing.htm#TDPSG50000\n \\\"Monitoring Database Activity with Auditing\\\" in the Oracle Database Security\n Guide:\n http://docs.oracle.com/database/121/DBSEG/part_6.htm#CCHEHCGI\n \\\"DBMS_AUDIT_MGMT\\\" in the Oracle Database PL/SQL Packages and Types Reference:\n http://docs.oracle.com/database/121/ARPLS/d_audit_mgmt.htm#ARPLS241\n Oracle Database Upgrade Guide:\n http://docs.oracle.com/database/121/UPGRD/afterup.htm#UPGRD52810\n\n If the site-specific audit requirements are not covered by the default audit\n options, deploy and configure Fine-Grained Auditing. For details, refer to\n Oracle documentation at the locations above.\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n standard_auditing_used = input('standard_auditing_used')\n unified_auditing_used = input('unified_auditing_used')\n\n describe.one do\n describe 'Standard auditing is in use for audit purposes' do\n subject { standard_auditing_used }\n it { should be true }\n end\n\n describe 'Unified auditing is in use for audit purposes' do\n subject { unified_auditing_used }\n it { should be true }\n end\n end\n\n audit_trail = sql.query(\"select value from v$parameter where name = 'audit_trail';\").column('value')\n audit_info_captured = sql.query('SELECT EVENT_TIMESTAMP FROM UNIFIED_AUDIT_TRAIL ORDER BY EVENT_TIMESTAMP DESC FETCH FIRST 10 ROWS ONLY;').column('event_timestamp')\n\n if standard_auditing_used\n describe 'The oracle database audit_trail parameter' do\n subject { audit_trail }\n it { should_not cmp 'NONE' }\n end\n end\n\n unified_auditing = sql.query(\"SELECT value FROM V$OPTION WHERE PARAMETER = 'Unified Auditing';\").column('value')\n\n if unified_auditing_used\n describe 'The oracle database unified auditing parameter' do\n subject { unified_auditing }\n it { should_not cmp 'FALSE' }\n end\n\n describe 'The oracle database unified auditing events captured' do\n subject { audit_info_captured }\n it { should_not be_empty }\n end\n\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61557.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61553.rb", "line": 1 }, - "id": "V-61557" + "id": "V-61553" }, { - "title": "The Oracle _TRACE_FILES_PUBLIC parameter if present must be set to\n FALSE.", - "desc": "The _TRACE_FILES_PUBLIC parameter is used to make trace files used for\n debugging database applications and events available to all database users. Use\n of this capability precludes the discrete assignment of privileges based on job\n function. Additionally, its use may provide access to external files and data\n to unauthorized users.", + "title": "The system must protect audit tools from unauthorized deletion.", + "desc": "Protecting audit data also includes identifying and protecting the\n tools used to view and manipulate log data.\n\n Depending upon the log format and application, system and application log\n tools may provide the only means to manipulate and manage application and\n system log data.\n\n It is, therefore, imperative that access to audit tools be controlled and\n protected from unauthorized access.\n\n Applications providing tools to interface with audit data will leverage\n user permissions and roles identifying the user accessing the tools and the\n corresponding rights the user enjoys in order make access decisions regarding\n the access to audit tools.\n\n Audit tools include, but are not limited to, OS-provided audit tools,\n vendor-provided audit tools, and open source audit tools needed to successfully\n view and manipulate audit information system activity and records.\n\n If an attacker were to gain access to audit tools, he could analyze audit\n logs for system weaknesses or weaknesses in the auditing itself. An attacker\n could also manipulate logs to hide evidence of malicious activity.", "descriptions": { - "default": "The _TRACE_FILES_PUBLIC parameter is used to make trace files used for\n debugging database applications and events available to all database users. Use\n of this capability precludes the discrete assignment of privileges based on job\n function. Additionally, its use may provide access to external files and data\n to unauthorized users." + "default": "Protecting audit data also includes identifying and protecting the\n tools used to view and manipulate log data.\n\n Depending upon the log format and application, system and application log\n tools may provide the only means to manipulate and manage application and\n system log data.\n\n It is, therefore, imperative that access to audit tools be controlled and\n protected from unauthorized access.\n\n Applications providing tools to interface with audit data will leverage\n user permissions and roles identifying the user accessing the tools and the\n corresponding rights the user enjoys in order make access decisions regarding\n the access to audit tools.\n\n Audit tools include, but are not limited to, OS-provided audit tools,\n vendor-provided audit tools, and open source audit tools needed to successfully\n view and manipulate audit information system activity and records.\n\n If an attacker were to gain access to audit tools, he could analyze audit\n logs for system weaknesses or weaknesses in the auditing itself. An attacker\n could also manipulate logs to hide evidence of malicious activity." }, - "impact": 0.5, + "impact": 0, "refs": [], "tags": { - "gtitle": "SRG-APP-000516-DB-999900", - "gid": "V-61465", - "rid": "SV-75955r1_rule", - "stig_id": "O121-BP-023900", - "fix_id": "F-67381r1_fix", + "gtitle": "SRG-APP-000123-DB-000204", + "gid": "V-61663", + "rid": "SV-76153r1_rule", + "stig_id": "O121-C2-009800", + "fix_id": "F-67577r1_fix", "cci": [ - "CCI-000366" + "CCI-001495" ], "nist": [ - "CM-6 b", + "AU-9", "Rev_4" ], "false_negatives": null, @@ -1196,35 +1192,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "From SQL*Plus:\n\n select value from v$parameter where name = '_trace_files_public';\n\n If the value returned is TRUE, this is a finding.\n\n If the parameter does not exist or is set to FALSE, this is not a finding.", - "fix": "From SQL*Plus (shutdown database instance):\n\n shutdown immediate\n\n From SQL*Plus (create a pfile from spfile):\n\n create pfile='[PATH]init[SID].ora' from spfile;\n\n Edit the init[SID].ora file and remove the following line:\n\n *._trace_files_public=TRUE\n\n From SQL*Plus (update the spfile using the pfile):\n\n create spfile from pfile='[PATH]init[SID].ora';\n\n From SQL*Plus (start the database instance):\n\n startup\n\n Note: [PATH] depends on the platform (Windows or UNIX).\n\n Ensure the file is directed to a writable location.\n\n [SID] is equal to the oracle SID or database instance ID." + "check": "Review access permissions to tools used to view or modify audit\n log data. These tools may include the DBMS itself or tools external to the\n database.\n\n If appropriate permissions and access controls are not applied to prevent\n unauthorized deletion of these tools, this is a finding.", + "fix": "Add or modify access controls and permissions to tools used to\n view or modify audit log data. Only authorized personnel must be able to delete\n these tools." }, - "code": "control 'V-61465' do\n title \"The Oracle _TRACE_FILES_PUBLIC parameter if present must be set to\n FALSE.\"\n desc \"The _TRACE_FILES_PUBLIC parameter is used to make trace files used for\n debugging database applications and events available to all database users. Use\n of this capability precludes the discrete assignment of privileges based on job\n function. Additionally, its use may provide access to external files and data\n to unauthorized users.\"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000516-DB-999900'\n tag \"gid\": 'V-61465'\n tag \"rid\": 'SV-75955r1_rule'\n tag \"stig_id\": 'O121-BP-023900'\n tag \"fix_id\": 'F-67381r1_fix'\n tag \"cci\": ['CCI-000366']\n tag \"nist\": ['CM-6 b', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"From SQL*Plus:\n\n select value from v$parameter where name = '_trace_files_public';\n\n If the value returned is TRUE, this is a finding.\n\n If the parameter does not exist or is set to FALSE, this is not a finding.\"\n tag \"fix\": \"From SQL*Plus (shutdown database instance):\n\n shutdown immediate\n\n From SQL*Plus (create a pfile from spfile):\n\n create pfile='[PATH]init[SID].ora' from spfile;\n\n Edit the init[SID].ora file and remove the following line:\n\n *._trace_files_public=TRUE\n\n From SQL*Plus (update the spfile using the pfile):\n\n create spfile from pfile='[PATH]init[SID].ora';\n\n From SQL*Plus (start the database instance):\n\n startup\n\n Note: [PATH] depends on the platform (Windows or UNIX).\n\n Ensure the file is directed to a writable location.\n\n [SID] is equal to the oracle SID or database instance ID.\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n parameter = sql.query(\"select value from v$parameter where name = '_trace_files_public';\").column('value')\n\n describe 'The oracle database _TRACE_FILES_PUBLIC parameter' do\n subject { parameter }\n it { should_not cmp 'TRUE' }\n end\nend\n", + "code": "control 'V-61663' do\n title 'The system must protect audit tools from unauthorized deletion.'\n desc \"Protecting audit data also includes identifying and protecting the\n tools used to view and manipulate log data.\n\n Depending upon the log format and application, system and application log\n tools may provide the only means to manipulate and manage application and\n system log data.\n\n It is, therefore, imperative that access to audit tools be controlled and\n protected from unauthorized access.\n\n Applications providing tools to interface with audit data will leverage\n user permissions and roles identifying the user accessing the tools and the\n corresponding rights the user enjoys in order make access decisions regarding\n the access to audit tools.\n\n Audit tools include, but are not limited to, OS-provided audit tools,\n vendor-provided audit tools, and open source audit tools needed to successfully\n view and manipulate audit information system activity and records.\n\n If an attacker were to gain access to audit tools, he could analyze audit\n logs for system weaknesses or weaknesses in the auditing itself. An attacker\n could also manipulate logs to hide evidence of malicious activity.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000123-DB-000204'\n tag \"gid\": 'V-61663'\n tag \"rid\": 'SV-76153r1_rule'\n tag \"stig_id\": 'O121-C2-009800'\n tag \"fix_id\": 'F-67577r1_fix'\n tag \"cci\": ['CCI-001495']\n tag \"nist\": ['AU-9', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Review access permissions to tools used to view or modify audit\n log data. These tools may include the DBMS itself or tools external to the\n database.\n\n If appropriate permissions and access controls are not applied to prevent\n unauthorized deletion of these tools, this is a finding.\"\n tag \"fix\": \"Add or modify access controls and permissions to tools used to\n view or modify audit log data. Only authorized personnel must be able to delete\n these tools.\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n users_allowed_access_to_audit_info = sql.query(\"SELECT GRANTEE, TABLE_NAME, PRIVILEGE\n FROM DBA_TAB_PRIVS where owner='AUDSYS';\").column('grantee').uniq\n if users_allowed_access_to_audit_info.empty?\n impact 0.0\n describe 'There are no oracle users allowed access to audit information, control N/A' do\n skip 'There are no oracle users allowed access to audit information'\n end\n else\n users_allowed_access_to_audit_info.each do |user|\n describe \"oracle users: #{user} allowed access to audit information\" do\n subject { user }\n it { should be_in input('allowed_audit_users') }\n end\n end\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61465.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61663.rb", "line": 1 }, - "id": "V-61465" + "id": "V-61663" }, { - "title": "Use of external executables must be authorized.", - "desc": "Information systems are capable of providing a wide variety of\n functions and services. Some of the functions and services, provided by\n default, may not be necessary to support essential organizational operations\n (e.g., key missions, functions).\n\n It is detrimental for applications to provide, or install by default,\n functionality exceeding requirements or mission objectives. Examples include,\n but are not limited to, installing advertising software, demonstrations, or\n browser plugins not related to requirements or providing a wide array of\n functionality not required for the mission.\n\n Applications must adhere to the principles of least functionality by\n providing only essential capabilities.\n\n DBMS's may spawn additional external processes to execute procedures that\n are defined in the DBMS, but stored in external host files (external\n procedures). The spawned process used to execute the external procedure may\n operate within a different OS security context than the DBMS and provide\n unauthorized access to the host system.", + "title": "The DBMS must enforce password maximum lifetime restrictions.", + "desc": "Password maximum lifetime is the maximum period of time, (typically in\n days) a user's password may be in effect before the user is forced to change it.\n\n Passwords need to be changed at specific policy-based intervals as per\n policy. Any password, no matter how complex, can eventually be cracked.\n\n One method of minimizing this risk is to use complex passwords and\n periodically change them. If the application does not limit the lifetime of\n passwords and force users to change their passwords, there is the risk that the\n system and/or application passwords could be compromised.\n\n The “PASSWORD_LIFE_TIME” parameter defines the number of days a password\n remains valid. This can, but must not be, set to “UNLIMITED”. Further, the\n “PASSWORD_GRACE_TIME” parameter, if set to “UNLIMITED”, can nullify the\n “PASSWORD_LIFE_TIME”. “PASSWORD_GRACE_TIME” must be set to “0” days (or another\n small integer).\n\n Note: 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. With respect to Oracle, this requirement applies to cases\n where it is necessary to have accounts directly managed by Oracle.", "descriptions": { - "default": "Information systems are capable of providing a wide variety of\n functions and services. Some of the functions and services, provided by\n default, may not be necessary to support essential organizational operations\n (e.g., key missions, functions).\n\n It is detrimental for applications to provide, or install by default,\n functionality exceeding requirements or mission objectives. Examples include,\n but are not limited to, installing advertising software, demonstrations, or\n browser plugins not related to requirements or providing a wide array of\n functionality not required for the mission.\n\n Applications must adhere to the principles of least functionality by\n providing only essential capabilities.\n\n DBMS's may spawn additional external processes to execute procedures that\n are defined in the DBMS, but stored in external host files (external\n procedures). The spawned process used to execute the external procedure may\n operate within a different OS security context than the DBMS and provide\n unauthorized access to the host system." + "default": "Password maximum lifetime is the maximum period of time, (typically in\n days) a user's password may be in effect before the user is forced to change it.\n\n Passwords need to be changed at specific policy-based intervals as per\n policy. Any password, no matter how complex, can eventually be cracked.\n\n One method of minimizing this risk is to use complex passwords and\n periodically change them. If the application does not limit the lifetime of\n passwords and force users to change their passwords, there is the risk that the\n system and/or application passwords could be compromised.\n\n The “PASSWORD_LIFE_TIME” parameter defines the number of days a password\n remains valid. This can, but must not be, set to “UNLIMITED”. Further, the\n “PASSWORD_GRACE_TIME” parameter, if set to “UNLIMITED”, can nullify the\n “PASSWORD_LIFE_TIME”. “PASSWORD_GRACE_TIME” must be set to “0” days (or another\n small integer).\n\n Note: 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. With respect to Oracle, this requirement applies to cases\n where it is necessary to have accounts directly managed by Oracle." }, - "impact": 0, + "impact": 0.5, "refs": [], "tags": { - "gtitle": "SRG-APP-000141-DB-000093", - "gid": "V-61683", - "rid": "SV-76173r1_rule", - "stig_id": "O121-C2-011800", - "fix_id": "F-67597r1_fix", + "gtitle": "SRG-APP-000174-DB-000080", + "gid": "V-61739", + "rid": "SV-76229r3_rule", + "stig_id": "O121-C2-015200", + "fix_id": "F-67655r5_fix", "cci": [ - "CCI-000381" + "CCI-000199" ], "nist": [ - "CM-7 a", + "IA-5 (1) (d)", "Rev_4" ], "false_negatives": null, @@ -1237,35 +1233,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Review the database for definitions of application executable\n objects stored external to the database.\n\n Determine if there are methods to disable use or access, or to remove\n definitions for external executable objects.\n\n Verify any application executable objects listed are authorized by the ISSO.\n\n If any are not, this is a finding.\n\n - - - - -\n To check for external procedures, execute the following query which will\n provide the libraries containing external procedures, the owners of those\n libraries, users that have been granted access to those libraries, and the\n privileges they have been granted. If there are owners other than the owners\n that Oracle provides, then there may be executable objects stored either in the\n database or external to the database that are called by objects in the\n database. Check to see that those owners are authorized to access those\n libraries. If there are users that have been granted access to libraries\n provided by Oracle, check to see that they are authorized to access those\n libraries.\n\n (connect as sysdba)\n set linesize 130\n column library_name format a25\n column name format a15\n column owner format a15\n column grantee format a15\n column privilege format a15\n select library_name,owner, '' grantee, '' privilege\n from dba_libraries where file_spec is not null\n minus\n (\n select library_name,o.name owner, '' grantee, '' privilege\n from dba_libraries l,\n sys.user$ o,\n sys.user$ ge,\n sys.obj$ obj,\n sys.objauth$ oa\n where l.owner=o.name\n and obj.owner#=o.user#\n and obj.name=l.library_name\n and oa.obj#=obj.obj#\n and ge.user#=oa.grantee#\n and l.file_spec is not null\n )\n union all\n select library_name,o.name owner, --obj.obj#,oa.privilege#,\n ge.name grantee,\n tpm.name privilege\n from dba_libraries l,\n sys.user$ o,\n sys.user$ ge,\n sys.obj$ obj,\n sys.objauth$ oa,\n sys.table_privilege_map tpm\n where l.owner=o.name\n and obj.owner#=o.user#\n and obj.name=l.library_name\n and oa.obj#=obj.obj#\n and ge.user#=oa.grantee#\n and tpm.privilege=oa.privilege#\n and l.file_spec is not null;\n /", - "fix": "Disable use of or remove any external application executable\n object definitions that are not authorized.\n\n Revoke privileges granted to users that are not authorized access to external\n applications." + "check": "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 Review DBMS settings to determine if passwords must be changed periodically. If\n not, this is a finding:\n\n SELECT p1.profile,\n CASE p1.limit WHEN 'UNLIMITED' THEN 'UNLIMITED' ELSE\n CASE p2.limit WHEN 'UNLIMITED' THEN 'UNLIMITED' ELSE\n CASE p3.limit WHEN 'UNLIMITED' THEN 'UNLIMITED' ELSE\n CASE p4.limit WHEN 'UNLIMITED' THEN 'UNLIMITED' ELSE\n TO_CHAR(DECODE(p1.limit, 'DEFAULT', p3.limit, p1.limit) + DECODE(p2.limit,\n 'DEFAULT', p4.limit, p2.limit))\n END\n END\n END\n END effective_life_time\n FROM dba_profiles p1, dba_profiles p2, dba_profiles p3, dba_profiles p4\n WHERE p1.profile=p2.profile\n AND p3.profile='DEFAULT'\n AND p4.profile='DEFAULT'\n AND p1.resource_name='PASSWORD_LIFE_TIME'\n AND p2.resource_name='PASSWORD_GRACE_TIME'\n AND p3.resource_name='PASSWORD_LIFE_TIME' -- from DEFAULT profile\n AND p4.resource_name='PASSWORD_GRACE_TIME' -- from DEFAULT profile\n order by 1;\n\n If the “effective_life_time” is greater than “60” for any profile applied to\n user accounts, and the need for this has not been documented and approved by\n the ISSO, this is a finding.\n\n If the value is greater than 35 for any profile applied to user accounts, and\n the DBMS is configured to use Password Lifetime to disable inactive accounts,\n this is a finding.", + "fix": "For user accounts managed by Oracle: Modify DBMS settings to\n force users to periodically change their passwords. For example, using PPPPPP\n to stand for a profile name:\n ALTER PROFILE PPPPPP LIMIT PASSWORD_LIFE_TIME 35 PASSWORD_GRACE_TIME 0;\n Do this for each profile applied to user accounts.\n\n (Note: Although the DoD requirement is for a password change every 60 days,\n using a value of “35” facilitates the use of “PASSWORD_LIFE_TIME” as a means of\n locking accounts inactive for 35 days. But if “35” is not a practical or\n acceptable limit for password lifetime, set it to the standard DoD value of\n “60”.)\n\n Where a password lifetime longer than “60” is needed, document the reasons and\n obtain ISSO approval." }, - "code": "control 'V-61683' do\n title 'Use of external executables must be authorized.'\n desc \"Information systems are capable of providing a wide variety of\n functions and services. Some of the functions and services, provided by\n default, may not be necessary to support essential organizational operations\n (e.g., key missions, functions).\n\n It is detrimental for applications to provide, or install by default,\n functionality exceeding requirements or mission objectives. Examples include,\n but are not limited to, installing advertising software, demonstrations, or\n browser plugins not related to requirements or providing a wide array of\n functionality not required for the mission.\n\n Applications must adhere to the principles of least functionality by\n providing only essential capabilities.\n\n DBMS's may spawn additional external processes to execute procedures that\n are defined in the DBMS, but stored in external host files (external\n procedures). The spawned process used to execute the external procedure may\n operate within a different OS security context than the DBMS and provide\n unauthorized access to the host system.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000141-DB-000093'\n tag \"gid\": 'V-61683'\n tag \"rid\": 'SV-76173r1_rule'\n tag \"stig_id\": 'O121-C2-011800'\n tag \"fix_id\": 'F-67597r1_fix'\n tag \"cci\": ['CCI-000381']\n tag \"nist\": ['CM-7 a', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Review the database for definitions of application executable\n objects stored external to the database.\n\n Determine if there are methods to disable use or access, or to remove\n definitions for external executable objects.\n\n Verify any application executable objects listed are authorized by the ISSO.\n\n If any are not, this is a finding.\n\n - - - - -\n To check for external procedures, execute the following query which will\n provide the libraries containing external procedures, the owners of those\n libraries, users that have been granted access to those libraries, and the\n privileges they have been granted. If there are owners other than the owners\n that Oracle provides, then there may be executable objects stored either in the\n database or external to the database that are called by objects in the\n database. Check to see that those owners are authorized to access those\n libraries. If there are users that have been granted access to libraries\n provided by Oracle, check to see that they are authorized to access those\n libraries.\n\n (connect as sysdba)\n set linesize 130\n column library_name format a25\n column name format a15\n column owner format a15\n column grantee format a15\n column privilege format a15\n select library_name,owner, '' grantee, '' privilege\n from dba_libraries where file_spec is not null\n minus\n (\n select library_name,o.name owner, '' grantee, '' privilege\n from dba_libraries l,\n sys.user$ o,\n sys.user$ ge,\n sys.obj$ obj,\n sys.objauth$ oa\n where l.owner=o.name\n and obj.owner#=o.user#\n and obj.name=l.library_name\n and oa.obj#=obj.obj#\n and ge.user#=oa.grantee#\n and l.file_spec is not null\n )\n union all\n select library_name,o.name owner, --obj.obj#,oa.privilege#,\n ge.name grantee,\n tpm.name privilege\n from dba_libraries l,\n sys.user$ o,\n sys.user$ ge,\n sys.obj$ obj,\n sys.objauth$ oa,\n sys.table_privilege_map tpm\n where l.owner=o.name\n and obj.owner#=o.user#\n and obj.name=l.library_name\n and oa.obj#=obj.obj#\n and ge.user#=oa.grantee#\n and tpm.privilege=oa.privilege#\n and l.file_spec is not null;\n /\"\n tag \"fix\": \"Disable use of or remove any external application executable\n object definitions that are not authorized.\n\n Revoke privileges granted to users that are not authorized access to external\n applications.\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n dba_users = sql.query(\"select library_name,owner, '' grantee, '' privilege\n from dba_libraries where file_spec is not null\n minus\n (\n select library_name,o.name owner, '' grantee, '' privilege\n from dba_libraries l,\n sys.user$ o,\n sys.user$ ge,\n sys.obj$ obj,\n sys.objauth$ oa\n where l.owner=o.name\n and obj.owner#=o.user#\n and obj.name=l.library_name\n and oa.obj#=obj.obj#\n and ge.user#=oa.grantee#\n and l.file_spec is not null\n )\n union all\n select library_name,o.name owner, --obj.obj#,oa.privilege#,\n ge.name grantee,\n tpm.name privilege\n from dba_libraries l,\n sys.user$ o,\n sys.user$ ge,\n sys.obj$ obj,\n sys.objauth$ oa,\n sys.table_privilege_map tpm\n where l.owner=o.name\n and obj.owner#=o.user#\n and obj.name=l.library_name\n and oa.obj#=obj.obj#\n and ge.user#=oa.grantee#\n and tpm.privilege=oa.privilege#\n and l.file_spec is not null;\").column('owner').uniq\n if dba_users.empty?\n impact 0.0\n describe 'There are no oracle DBA users, control N/A' do\n skip 'There are no oracle DBA users, control N/A'\n end\n else\n dba_users.each do |user|\n describe \"oracle DBA users: #{user}\" do\n subject { user }\n it { should be_in input('allowed_dbadmin_users') }\n end\n end\n end\nend\n", + "code": "control 'V-61739' do\n title 'The DBMS must enforce password maximum lifetime restrictions.'\n desc \"Password maximum lifetime is the maximum period of time, (typically in\n days) a user's password may be in effect before the user is forced to change it.\n\n Passwords need to be changed at specific policy-based intervals as per\n policy. Any password, no matter how complex, can eventually be cracked.\n\n One method of minimizing this risk is to use complex passwords and\n periodically change them. If the application does not limit the lifetime of\n passwords and force users to change their passwords, there is the risk that the\n system and/or application passwords could be compromised.\n\n The “PASSWORD_LIFE_TIME” parameter defines the number of days a password\n remains valid. This can, but must not be, set to “UNLIMITED”. Further, the\n “PASSWORD_GRACE_TIME” parameter, if set to “UNLIMITED”, can nullify the\n “PASSWORD_LIFE_TIME”. “PASSWORD_GRACE_TIME” must be set to “0” days (or another\n small integer).\n\n Note: 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. With respect to Oracle, this requirement applies to cases\n where it is necessary to have accounts directly managed by Oracle.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000174-DB-000080'\n tag \"gid\": 'V-61739'\n tag \"rid\": 'SV-76229r3_rule'\n tag \"stig_id\": 'O121-C2-015200'\n tag \"fix_id\": 'F-67655r5_fix'\n tag \"cci\": ['CCI-000199']\n tag \"nist\": ['IA-5 (1) (d)', '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 Review DBMS settings to determine if passwords must be changed periodically. If\n not, this is a finding:\n\n SELECT p1.profile,\n CASE p1.limit WHEN 'UNLIMITED' THEN 'UNLIMITED' ELSE\n CASE p2.limit WHEN 'UNLIMITED' THEN 'UNLIMITED' ELSE\n CASE p3.limit WHEN 'UNLIMITED' THEN 'UNLIMITED' ELSE\n CASE p4.limit WHEN 'UNLIMITED' THEN 'UNLIMITED' ELSE\n TO_CHAR(DECODE(p1.limit, 'DEFAULT', p3.limit, p1.limit) + DECODE(p2.limit,\n 'DEFAULT', p4.limit, p2.limit))\n END\n END\n END\n END effective_life_time\n FROM dba_profiles p1, dba_profiles p2, dba_profiles p3, dba_profiles p4\n WHERE p1.profile=p2.profile\n AND p3.profile='DEFAULT'\n AND p4.profile='DEFAULT'\n AND p1.resource_name='PASSWORD_LIFE_TIME'\n AND p2.resource_name='PASSWORD_GRACE_TIME'\n AND p3.resource_name='PASSWORD_LIFE_TIME' -- from DEFAULT profile\n AND p4.resource_name='PASSWORD_GRACE_TIME' -- from DEFAULT profile\n order by 1;\n\n If the “effective_life_time” is greater than “60” for any profile applied to\n user accounts, and the need for this has not been documented and approved by\n the ISSO, this is a finding.\n\n If the value is greater than 35 for any profile applied to user accounts, and\n the DBMS is configured to use Password Lifetime to disable inactive accounts,\n this is a finding.\"\n tag \"fix\": \"For user accounts managed by Oracle: Modify DBMS settings to\n force users to periodically change their passwords. For example, using PPPPPP\n to stand for a profile name:\n ALTER PROFILE PPPPPP LIMIT PASSWORD_LIFE_TIME 35 PASSWORD_GRACE_TIME 0;\n Do this for each profile applied to user accounts.\n\n (Note: Although the DoD requirement is for a password change every 60 days,\n using a value of “35” facilitates the use of “PASSWORD_LIFE_TIME” as a means of\n locking accounts inactive for 35 days. But if “35” is not a practical or\n acceptable limit for password lifetime, set it to the standard DoD value of\n “60”.)\n\n Where a password lifetime longer than “60” is needed, document the reasons and\n obtain ISSO approval.\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n get_effective_life_time = sql.query(\"SELECT p1.profile,\n CASE p1.limit WHEN 'UNLIMITED' THEN 'UNLIMITED' ELSE\n CASE p2.limit WHEN 'UNLIMITED' THEN 'UNLIMITED' ELSE\n CASE p3.limit WHEN 'UNLIMITED' THEN 'UNLIMITED' ELSE\n CASE p4.limit WHEN 'UNLIMITED' THEN 'UNLIMITED' ELSE\n TO_CHAR(DECODE(p1.limit, 'DEFAULT', p3.limit, p1.limit) + DECODE(p2.limit,\n 'DEFAULT', p4.limit, p2.limit))\n END\n END\n END\n END effective_life_time\n FROM dba_profiles p1, dba_profiles p2, dba_profiles p3, dba_profiles p4\n WHERE p1.profile=p2.profile\n AND p3.profile='DEFAULT'\n AND p4.profile='DEFAULT'\n AND p1.resource_name='PASSWORD_LIFE_TIME'\n AND p2.resource_name='PASSWORD_GRACE_TIME'\n AND p3.resource_name='PASSWORD_LIFE_TIME' -- from DEFAULT profile\n AND p4.resource_name='PASSWORD_GRACE_TIME' -- from DEFAULT profile\n order by 1;\").column('effective_life_time')\n\n get_effective_life_time.each do |effective_life_time|\n\n describe 'The oracle database account effective life time limit' do\n subject { effective_life_time }\n it { should cmp >= 60 }\n end\n end\n describe get_effective_life_time do\n it { should_not be_empty }\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61683.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61739.rb", "line": 1 }, - "id": "V-61683" + "id": "V-61739" }, { - "title": "Audit trail data must be reviewed daily or more frequently.", - "desc": "Review of audit trail data provides a means for detection of\n unauthorized access or attempted access. Frequent and regularly scheduled\n reviews ensure that such access is discovered in a timely manner.", + "title": "The DBMS must enforce approved authorizations for logical access to\n the system in accordance with applicable policy.", + "desc": "Strong access controls are critical to securing application data.\n Access control policies (e.g., identity-based policies, role-based policies,\n attribute-based policies) and access enforcement mechanisms (e.g., access\n control lists, access control matrices, cryptography) must be employed by\n applications, when applicable, to control access between users (or processes\n acting on behalf of users) and objects (e.g., devices, files, records,\n processes, programs, domains) in the information system.\n\n Consideration should be given to the implementation of an audited, explicit\n override of automated mechanisms in the event of emergencies or other serious\n events.\n\n If the DBMS does not follow applicable policy when approving access it may\n be in conflict with networks or other applications in the information system.\n This may result in users either gaining or being denied access inappropriately\n and may be in conflict with applicable policy.", "descriptions": { - "default": "Review of audit trail data provides a means for detection of\n unauthorized access or attempted access. Frequent and regularly scheduled\n reviews ensure that such access is discovered in a timely manner." + "default": "Strong access controls are critical to securing application data.\n Access control policies (e.g., identity-based policies, role-based policies,\n attribute-based policies) and access enforcement mechanisms (e.g., access\n control lists, access control matrices, cryptography) must be employed by\n applications, when applicable, to control access between users (or processes\n acting on behalf of users) and objects (e.g., devices, files, records,\n processes, programs, domains) in the information system.\n\n Consideration should be given to the implementation of an audited, explicit\n override of automated mechanisms in the event of emergencies or other serious\n events.\n\n If the DBMS does not follow applicable policy when approving access it may\n be in conflict with networks or other applications in the information system.\n This may result in users either gaining or being denied access inappropriately\n and may be in conflict with applicable policy." }, "impact": 0.5, "refs": [], "tags": { - "gtitle": "SRG-APP-000516-DB-999900", - "gid": "V-61457", - "rid": "SV-75947r1_rule", - "stig_id": "O121-BP-023500", - "fix_id": "F-67373r2_fix", + "gtitle": "SRG-APP-000033-DB-000084", + "gid": "V-61575", + "rid": "SV-76065r1_rule", + "stig_id": "O121-C2-002700", + "fix_id": "F-67491r1_fix", "cci": [ - "CCI-000366" + "CCI-000213" ], "nist": [ - "CM-6 b", + "AC-3", "Rev_4" ], "false_negatives": null, @@ -1278,39 +1274,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "If the database being reviewed is not a production database,\n this check is not a finding.\n\n Review policy and procedures documented or noted in the System Security plan as\n well as evidence of implementation for daily audit trail monitoring.\n\n If policy and procedures are not documented or evidence of implementation is\n not available, this is a finding.", - "fix": "Develop, document and implement policy and procedures to monitor\n audit trail data daily." + "check": "Check DBMS settings to determine whether users are restricted\n from accessing objects and data they are not authorized to access. If\n appropriate access controls are not implemented to restrict access to\n authorized users and to restrict the access of those users to objects and data\n they are authorized to see, this is a finding.\n\n The easiest way to isolate access is by using the Oracle Database Vault. To\n check to see if the Oracle Database Vault is installed, issue the following\n query:\n\n SQL> SELECT * FROM V$OPTION WHERE PARAMETER = 'Oracle Database Vault';\n\n If Oracle Database Vault is installed, review its settings for appropriateness\n and completeness of the access it permits and denies to each type of user. If\n appropriate and complete, this is not a finding.\n\n If Oracle Database Vault is not installed, review the roles and profiles in the\n database and the assignment of users to these for appropriateness and\n completeness of the access permitted and denied each type of user. If\n appropriate and complete, this is not a finding.\n\n If the access permitted and denied each type of user is inappropriate or\n incomplete, this is a finding.\n\n Following are code examples for reviewing roles, profiles, etc.\n\n Find out what role the users have:\n select * from dba_role_privs where granted_role = ''\n\n List all roles given to a user:\n select * from dba_role_privs where grantee = '';\n\n List all roles for all users:\n column grantee format a32\n column granted_role format a32\n break on grantee\n select grantee, granted_role from dba_role_privs;\n\n Use the following query to list all privileges given to a user:\n select\n lpad(' ', 2*level) || granted_role \"User roles and privileges\"\n from\n (\n /* THE USERS */\n select\n null grantee,\n username granted_role\n from\n dba_users\n where\n username like upper('')\n /* THE ROLES TO ROLES RELATIONS */\n union\n select\n grantee,\n granted_role\n from\n dba_role_privs\n /* THE ROLES TO PRIVILEGE RELATIONS */\n union\n select\n grantee,\n privilege\n from\n dba_sys_privs\n )\n start with grantee is null\n connect by grantee = prior granted_role;\n\n List which tables a certain role gives SELECT access to using the query:\n select * from role_tab_privs where role='' and privilege = 'SELECT';\n\n List all tables a user can SELECT from using the query:\n select * from dba_tab_privs where GRANTEE ='' and privilege =\n 'SELECT';\n\n List all users who can SELECT on a particular table (either through being given\n a relevant role or through a direct grant - e.g., grant select on a table to\n Joe). The result of this query should also show through which role the user has\n this access or whether it was a direct grant.\n\n select\n Grantee,'Granted Through Role' as Grant_Type,\n role,\n table_name\n from role_tab_privs rtp, dba_role_privs drp\n where rtp.role = drp.granted_role\n and table_name = ''\n union\n select\n Grantee,\n 'Direct Grant' as Grant_type,\n null as role,\n table_name\n from dba_tab_privs\n where table_name = '';", + "fix": "If Oracle Database Vault is in use, use it to configure the\n correct access privileges for each type of user.\n\n If Oracle Database Vault is not in use, configure the correct access privileges\n for each type of user using Roles and Profiles.\n\n For more information on the configuration of Database Vault, refer to the\n following documents:\n Database Vault Administrator's Guide:\n https://docs.oracle.com/database/121/DVADM/toc.htm" }, - "code": "control 'V-61457' do\n title 'Audit trail data must be reviewed daily or more frequently.'\n desc \"Review of audit trail data provides a means for detection of\n unauthorized access or attempted access. Frequent and regularly scheduled\n reviews ensure that such access is discovered in a timely manner.\"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000516-DB-999900'\n tag \"gid\": 'V-61457'\n tag \"rid\": 'SV-75947r1_rule'\n tag \"stig_id\": 'O121-BP-023500'\n tag \"fix_id\": 'F-67373r2_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 database being reviewed is not a production database,\n this check is not a finding.\n\n Review policy and procedures documented or noted in the System Security plan as\n well as evidence of implementation for daily audit trail monitoring.\n\n If policy and procedures are not documented or evidence of implementation is\n not available, this is a finding.\"\n tag \"fix\": \"Develop, document and implement policy and procedures to monitor\n audit trail data daily.\"\n describe 'A manual review is required to ensure audit trail data is reviewed daily or more frequently' do\n skip 'A manual review is required to ensure audit trail data is reviewed daily or more frequently'\n end\nend\n", + "code": "control 'V-61575' do\n title \"The DBMS must enforce approved authorizations for logical access to\n the system in accordance with applicable policy.\"\n desc \"Strong access controls are critical to securing application data.\n Access control policies (e.g., identity-based policies, role-based policies,\n attribute-based policies) and access enforcement mechanisms (e.g., access\n control lists, access control matrices, cryptography) must be employed by\n applications, when applicable, to control access between users (or processes\n acting on behalf of users) and objects (e.g., devices, files, records,\n processes, programs, domains) in the information system.\n\n Consideration should be given to the implementation of an audited, explicit\n override of automated mechanisms in the event of emergencies or other serious\n events.\n\n If the DBMS does not follow applicable policy when approving access it may\n be in conflict with networks or other applications in the information system.\n This may result in users either gaining or being denied access inappropriately\n and may be in conflict with applicable policy.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000033-DB-000084'\n tag \"gid\": 'V-61575'\n tag \"rid\": 'SV-76065r1_rule'\n tag \"stig_id\": 'O121-C2-002700'\n tag \"fix_id\": 'F-67491r1_fix'\n tag \"cci\": ['CCI-000213']\n tag \"nist\": ['AC-3', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Check DBMS settings to determine whether users are restricted\n from accessing objects and data they are not authorized to access. If\n appropriate access controls are not implemented to restrict access to\n authorized users and to restrict the access of those users to objects and data\n they are authorized to see, this is a finding.\n\n The easiest way to isolate access is by using the Oracle Database Vault. To\n check to see if the Oracle Database Vault is installed, issue the following\n query:\n\n SQL> SELECT * FROM V$OPTION WHERE PARAMETER = 'Oracle Database Vault';\n\n If Oracle Database Vault is installed, review its settings for appropriateness\n and completeness of the access it permits and denies to each type of user. If\n appropriate and complete, this is not a finding.\n\n If Oracle Database Vault is not installed, review the roles and profiles in the\n database and the assignment of users to these for appropriateness and\n completeness of the access permitted and denied each type of user. If\n appropriate and complete, this is not a finding.\n\n If the access permitted and denied each type of user is inappropriate or\n incomplete, this is a finding.\n\n Following are code examples for reviewing roles, profiles, etc.\n\n Find out what role the users have:\n select * from dba_role_privs where granted_role = ''\n\n List all roles given to a user:\n select * from dba_role_privs where grantee = '';\n\n List all roles for all users:\n column grantee format a32\n column granted_role format a32\n break on grantee\n select grantee, granted_role from dba_role_privs;\n\n Use the following query to list all privileges given to a user:\n select\n lpad(' ', 2*level) || granted_role \\\"User roles and privileges\\\"\n from\n (\n /* THE USERS */\n select\n null grantee,\n username granted_role\n from\n dba_users\n where\n username like upper('')\n /* THE ROLES TO ROLES RELATIONS */\n union\n select\n grantee,\n granted_role\n from\n dba_role_privs\n /* THE ROLES TO PRIVILEGE RELATIONS */\n union\n select\n grantee,\n privilege\n from\n dba_sys_privs\n )\n start with grantee is null\n connect by grantee = prior granted_role;\n\n List which tables a certain role gives SELECT access to using the query:\n select * from role_tab_privs where role='' and privilege = 'SELECT';\n\n List all tables a user can SELECT from using the query:\n select * from dba_tab_privs where GRANTEE ='' and privilege =\n 'SELECT';\n\n List all users who can SELECT on a particular table (either through being given\n a relevant role or through a direct grant - e.g., grant select on a table to\n Joe). The result of this query should also show through which role the user has\n this access or whether it was a direct grant.\n\n select\n Grantee,'Granted Through Role' as Grant_Type,\n role,\n table_name\n from role_tab_privs rtp, dba_role_privs drp\n where rtp.role = drp.granted_role\n and table_name = ''\n union\n select\n Grantee,\n 'Direct Grant' as Grant_type,\n null as role,\n table_name\n from dba_tab_privs\n where table_name = '';\"\n tag \"fix\": \"If Oracle Database Vault is in use, use it to configure the\n correct access privileges for each type of user.\n\n If Oracle Database Vault is not in use, configure the correct access privileges\n for each type of user using Roles and Profiles.\n\n For more information on the configuration of Database Vault, refer to the\n following documents:\n Database Vault Administrator's Guide:\n https://docs.oracle.com/database/121/DVADM/toc.htm\"\n describe 'A manual review is required to ensure the DBMS enforces approved authorizations for logical access to\n the system in accordance with applicable policy' do\n skip 'A manual review is required to ensure the DBMS enforces approved authorizations for logical access to\n the system in accordance with applicable policy'\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61457.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61575.rb", "line": 1 }, - "id": "V-61457" + "id": "V-61575" }, { - "title": "The DBMS must support organizational requirements to enforce password\n complexity by the number of special characters used.", - "desc": "Password complexity or strength is a measure of the effectiveness of a\n password in resisting attempts at guessing and brute-force attacks.\n\n Password complexity is one factor of several that determine how long it\n takes to crack a password. The more complex the password is, the greater the\n number of possible combinations that need to be tested before the password is\n compromised.\n\n Use of a complex password helps to increase the time and resources required\n to compromise the password.\n\n Note that user authentication and account management must be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP This requirement applies to cases where it is necessary to\n have accounts directly managed by Oracle.", + "title": "Access to default accounts used to support replication must be\n restricted to authorized DBAs.", + "desc": "Replication database accounts are used for database connections\n between databases. Replication requires the configuration of these accounts\n using the same username and password on all databases participating in the\n replication. Replication connections use fixed user database links. This means\n that access to the replication account on one server provides access to the\n other servers participating in the replication. Granting unauthorized access to\n the replication account provides unauthorized and privileged access to all\n databases participating in the replication group.", "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": "Replication database accounts are used for database connections\n between databases. Replication requires the configuration of these accounts\n using the same username and password on all databases participating in the\n replication. Replication connections use fixed user database links. This means\n that access to the replication account on one server provides access to the\n other servers participating in the replication. Granting unauthorized access to\n the replication account provides unauthorized and privileged access to all\n databases participating in the replication group." }, "impact": 0.5, - "refs": [ - { - "ref": [] - } - ], + "refs": [], "tags": { - "gtitle": "SRG-APP-000169-DB-000176", - "gid": "V-61729", - "rid": "SV-76219r1_rule", - "stig_id": "O121-C2-014400", - "fix_id": "F-67645r1_fix", + "gtitle": "SRG-APP-000516-DB-999900", + "gid": "V-61411", + "rid": "SV-75901r1_rule", + "stig_id": "O121-BP-021200", + "fix_id": "F-67327r1_fix", "cci": [ - "CCI-001619" + "CCI-000366" ], "nist": [ - "IA-5 (1) (a)", + "CM-6 b", "Rev_4" ], "false_negatives": null, @@ -1323,35 +1315,39 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "If all user accounts are managed and authenticated by the OS or\n an enterprise-level authentication/access mechanism, and not by Oracle, this is\n not a finding.\n\n For each profile that can be applied to accounts where authentication is under\n Oracle's control, determine the password verification function, if any, that is\n in use:\n\n SELECT * FROM SYS.DBA_PROFILES\n WHERE RESOURCE_NAME = 'PASSWORD_VERIFY_FUNCTION'\n [AND PROFILE NOT IN ()]\n ORDER BY PROFILE;\n Bearing in mind that a profile can inherit from another profile, and the root\n profile is called DEFAULT, determine the name of the password verification\n function effective for each profile.\n\n If, for any profile, the function name is null, this is a finding.\n\n For each password verification function, examine its source code.\n\n If it does not enforce the organization-defined minimum number of special\n characters (1 unless otherwise specified), this is a finding.", - "fix": "If all user accounts are authenticated by the OS or an\n enterprise-level authentication/access mechanism, and not by Oracle, no fix to\n the DBMS is required.\n\n If any user accounts are managed by Oracle: Develop, test and implement a\n password verification function that enforces DoD requirements.\n\n (Oracle supplies a sample function called ORA12C_STRONG_VERIFY_FUNCTION, in the\n script file\n /RDBMS/ADMIN/utlpwdmg.sql. This can be used as the starting point\n for a customized function.)" + "check": "From SQL*Plus:\n\n select 'The number of replication objects defined is: '||\n count(*) from all_tables\n where table_name like 'REPCAT%';\n\n If the count returned is 0, then Oracle Replication is not installed and this\n check is not a finding.\n\n Otherwise:\n\n From SQL*Plus:\n\n select count(*) from sys.dba_repcatlog;\n\n If the count returned is 0, then Oracle Replication is not in use and this\n check is not a finding.\n\n If any results are returned, ask the ISSO or DBA if the replication account\n (the default is REPADMIN, but may be customized) is restricted to\n ISSO-authorized personnel only.\n\n If it is not, this is a finding.\n\n If there are multiple replication accounts, confirm that all are justified and\n documented with the ISSO.\n\n If they are not, this is a finding.\n\n Note: Oracle Database Advanced Replication is deprecated in Oracle Database\n 12c. Use Oracle GoldenGate to replace all features of Advanced Replication,\n including multimaster replication, updatable materialized views, hierarchical\n materialized views, and deployment templates.", + "fix": "Change the password for default and custom replication accounts\n and provide the password to ISSO-authorized users only." }, - "code": "control 'V-61729' do\n title \"The DBMS must support organizational requirements to enforce password\n complexity by the number of special characters used.\"\n desc \"Password complexity or strength is a measure of the effectiveness of a\n password in resisting attempts at guessing and brute-force attacks.\n\n Password complexity is one factor of several that determine how long it\n takes to crack a password. The more complex the password is, the greater the\n number of possible combinations that need to be tested before the password is\n compromised.\n\n Use of a complex password helps to increase the time and resources required\n to compromise the password.\n\n Note that user authentication and account management must be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP This requirement applies to cases where it is necessary to\n have accounts directly managed by Oracle.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000169-DB-000176'\n tag \"gid\": 'V-61729'\n tag \"rid\": 'SV-76219r1_rule'\n tag \"stig_id\": 'O121-C2-014400'\n tag \"fix_id\": 'F-67645r1_fix'\n tag \"cci\": ['CCI-001619']\n tag \"nist\": ['IA-5 (1) (a)', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"If all user accounts are managed and authenticated by the OS or\n an enterprise-level authentication/access mechanism, and not by Oracle, this is\n not a finding.\n\n For each profile that can be applied to accounts where authentication is under\n Oracle's control, determine the password verification function, if any, that is\n in use:\n\n SELECT * FROM SYS.DBA_PROFILES\n WHERE RESOURCE_NAME = 'PASSWORD_VERIFY_FUNCTION'\n [AND PROFILE NOT IN ()]\n ORDER BY PROFILE;\n Bearing in mind that a profile can inherit from another profile, and the root\n profile is called DEFAULT, determine the name of the password verification\n function effective for each profile.\n\n If, for any profile, the function name is null, this is a finding.\n\n For each password verification function, examine its source code.\n\n If it does not enforce the organization-defined minimum number of special\n characters (1 unless otherwise specified), this is a finding.\"\n tag \"fix\": \"If all user accounts are authenticated by the OS or an\n enterprise-level authentication/access mechanism, and not by Oracle, no fix to\n the DBMS is required.\n\n If any user accounts are managed by Oracle: Develop, test and implement a\n password verification function that enforces DoD requirements.\n\n (Oracle supplies a sample function called ORA12C_STRONG_VERIFY_FUNCTION, in the\n script file\n /RDBMS/ADMIN/utlpwdmg.sql. This can be used as the starting point\n for a customized function.)\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n query = %{\n SELECT PROFILE, RESOURCE_NAME, LIMIT FROM DBA_PROFILES WHERE PROFILE =\n '%s' AND RESOURCE_NAME = 'PASSWORD_VERIFY_FUNCTION'\n }\n\n user_profiles = sql.query('SELECT profile FROM dba_users;').column('profile').uniq\n\n user_profiles.each do |profile|\n next if profile == \"RDSADMIN\"\n password_verify_function = sql.query(format(query, profile: profile)).column('limit')\n\n describe \"The oracle database account password verify function for profile: #{profile}\" do\n subject { password_verify_function }\n it { should_not eq ['NULL'] }\n end\n end\n if user_profiles.empty?\n describe 'There are no user profiles, therefore this control is NA' do\n skip 'There are no user profiles, therefore this control is NA'\n end\n end\nend\n", + "code": "control 'V-61411' do\n title \"Access to default accounts used to support replication must be\n restricted to authorized DBAs.\"\n desc \"Replication database accounts are used for database connections\n between databases. Replication requires the configuration of these accounts\n using the same username and password on all databases participating in the\n replication. Replication connections use fixed user database links. This means\n that access to the replication account on one server provides access to the\n other servers participating in the replication. Granting unauthorized access to\n the replication account provides unauthorized and privileged access to all\n databases participating in the replication group.\"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000516-DB-999900'\n tag \"gid\": 'V-61411'\n tag \"rid\": 'SV-75901r1_rule'\n tag \"stig_id\": 'O121-BP-021200'\n tag \"fix_id\": 'F-67327r1_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 'The number of replication objects defined is: '||\n count(*) from all_tables\n where table_name like 'REPCAT%';\n\n If the count returned is 0, then Oracle Replication is not installed and this\n check is not a finding.\n\n Otherwise:\n\n From SQL*Plus:\n\n select count(*) from sys.dba_repcatlog;\n\n If the count returned is 0, then Oracle Replication is not in use and this\n check is not a finding.\n\n If any results are returned, ask the ISSO or DBA if the replication account\n (the default is REPADMIN, but may be customized) is restricted to\n ISSO-authorized personnel only.\n\n If it is not, this is a finding.\n\n If there are multiple replication accounts, confirm that all are justified and\n documented with the ISSO.\n\n If they are not, this is a finding.\n\n Note: Oracle Database Advanced Replication is deprecated in Oracle Database\n 12c. Use Oracle GoldenGate to replace all features of Advanced Replication,\n including multimaster replication, updatable materialized views, hierarchical\n materialized views, and deployment templates.\"\n tag \"fix\": \"Change the password for default and custom replication accounts\n and provide the password to ISSO-authorized users only.\"\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n is_oracle_replication_used = sql.query(\"select count(*) from all_tables\n where table_name like 'REPCAT%';\").column('count(*)')\n\n oracle_replication_accounts = sql.query('select * from sys.dba_repcatlog;').column('gname')\n\n if !is_oracle_replication_used.include?('0')\n describe \"The ISSO or DBA must manually ensure the following replication accounts are justified: #{oracle_replication_accounts}\" do\n skip \"The ISSO or DBA must manually ensure the following replication accounts are justified: #{oracle_replication_accounts}\"\n end\n else\n describe 'The number of replication accounts defined' do\n subject { is_oracle_replication_used }\n it { should cmp 0 }\n end\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61729.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61411.rb", "line": 1 }, - "id": "V-61729" + "id": "V-61411" }, { - "title": "The DBMS must notify appropriate individuals when accounts are\n terminated.", - "desc": "When application accounts are terminated, user accessibility is\n affected. Accounts are utilized for identifying individual application users\n or for identifying the application processes themselves.\n\n In order to detect and respond to events that affect user accessibility and\n application processing, applications must notify the appropriate individuals\n when an account is terminated so they can investigate the event. Such a\n capability greatly reduces the risk that application accessibility will be\n negatively affected for extended periods of time and provides logging that can\n be used for forensic purposes.\n\n Note that user authentication and account management must be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP. This requirement applies to cases where accounts are\n directly managed by Oracle.\n\n Notwithstanding how accounts are normally managed, the DBMS must support\n the requirement to notify appropriate individuals upon account termination\n within Oracle. Indeed, in a configuration where accounts are managed\n externally, the manipulation of an account within Oracle may indicate hostile\n activity.", + "title": "Network access to the DBMS must be restricted to authorized personnel.", + "desc": "Restricting remote access to specific, trusted systems helps prevent\n access by unauthorized and potentially malicious users.", "descriptions": { - "default": "When application accounts are terminated, user accessibility is\n affected. Accounts are utilized for identifying individual application users\n or for identifying the application processes themselves.\n\n In order to detect and respond to events that affect user accessibility and\n application processing, applications must notify the appropriate individuals\n when an account is terminated so they can investigate the event. Such a\n capability greatly reduces the risk that application accessibility will be\n negatively affected for extended periods of time and provides logging that can\n be used for forensic purposes.\n\n Note that user authentication and account management must be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP. This requirement applies to cases where accounts are\n directly managed by Oracle.\n\n Notwithstanding how accounts are normally managed, the DBMS must support\n the requirement to notify appropriate individuals upon account termination\n within Oracle. Indeed, in a configuration where accounts are managed\n externally, the manipulation of an account within Oracle may indicate hostile\n activity." + "default": "Restricting remote access to specific, trusted systems helps prevent\n access by unauthorized and potentially malicious users." }, - "impact": 0.5, - "refs": [], + "impact": 0, + "refs": [ + { + "ref": [] + } + ], "tags": { - "gtitle": "SRG-APP-000294-DB-000129", - "gid": "V-61803", - "rid": "SV-76293r2_rule", - "stig_id": "O121-C2-020700", - "fix_id": "F-67719r1_fix", + "gtitle": "SRG-APP-000516-DB-999900", + "gid": "V-61515", + "rid": "SV-76005r2_rule", + "stig_id": "O121-BP-025600", + "fix_id": "F-67431r1_fix", "cci": [ - "CCI-001686" + "CCI-000366" ], "nist": [ - "AC-2 (4)", + "CM-6 b", "Rev_4" ], "false_negatives": null, @@ -1364,35 +1360,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Check DBMS settings to determine whether it will notify\n appropriate individuals when accounts are terminated.\n\n If the DBMS does not notify appropriate individuals when accounts are\n terminated, this is a finding.", - "fix": "Working with the DBA and site management, determine the\n appropriate individuals (by job role) to be notified.\n\n If Oracle Audit Vault is available, configure it to notify the appropriate\n individuals when accounts are terminated.\n\n If Oracle Audit Vault is not available, configure the Oracle DBMS's auditing\n feature to record termination of accounts.\n\n If Standard Auditing is used:\n Create and deploy a mechanism, such as a frequently-run job, to monitor the\n SYS.AUD$ table for these records and notify the appropriate individuals.\n\n If unified Auditing is used:\n Create and deploy a mechanism, such as a frequently-run job, to monitor the\n SYS.UNIFIED_AUDIT_TRAIL view for these records and notify the appropriate\n individuals." + "check": "IP address restriction may be defined for the database\n listener, by use of the Oracle Connection Manager or by an external network\n device.\n\n Identify the method used to enforce address restriction (interview or System\n Security Plan review).\n\n If enforced by the database listener, then review the SQLNET.ORA file located\n in the ORACLE_HOME/network/admin directory (note: this assumes that a single\n sqlnet.ora file, in the default location, is in use; please see the\n supplemental file \"Non-default sqlnet.ora configurations.pdf\" for how to find\n multiple and/or differently located sqlnet.ora files) or the directory\n indicated by the TNS_ADMIN environment variable or registry setting.\n\n If the following entries do not exist, then restriction by IP address is not\n configured and is a finding.\n\n tcp.validnode_checking=YES\n tcp.invited_nodes=(IP1, IP2, IP3)\n\n If enforced by an Oracle Connection Manager, then review the CMAN.ORA file for\n the Connection Manager (located in the TNS_ADMIN or ORACLE_HOME/network/admin\n directory for the connection manager).\n\n If a RULE entry allows all addresses (\"/32\") or does not match the address\n range specified in the System Security Plan, this is a finding.\n\n (rule=(src=[IP]/27)(dst=[IP])(srv=*)(act=accept))\n\n Note: an IP address with a \"/\" indicates acceptance by subnet mask where the\n number after the \"/\" is the left most number of bits in the address that must\n match for the rule to apply.\n\n If this rule is database-specific, then determine if the SERVICE_NAMES\n parameter is set:\n\n From SQL*PLUS:\n\n select value from v$parameter where name = 'service_names';\n\n If SERVICE_NAMES is set in the initialization file for the database instance,\n use (srv=[service name]), else, use (srv=*) if not set or rule applies to all\n databases on the DBMS server.\n\n If network access restriction is performed by an external device, validate ACLs\n are in place to prohibit unauthorized access to the DBMS. To do this, find the\n IP address of the database server (destination address) and source address\n (authorized IPs) in the System Security Plan. Confirm only authorized IPs from\n the System Security Plan are allowed access to the DBMS.", + "fix": "Configure the database listener to restrict access by IP address\n or set up an external device to restrict network access to the DBMS." }, - "code": "control 'V-61803' do\n title \"The DBMS must notify appropriate individuals when accounts are\n terminated.\"\n desc \"When application accounts are terminated, user accessibility is\n affected. Accounts are utilized for identifying individual application users\n or for identifying the application processes themselves.\n\n In order to detect and respond to events that affect user accessibility and\n application processing, applications must notify the appropriate individuals\n when an account is terminated so they can investigate the event. Such a\n capability greatly reduces the risk that application accessibility will be\n negatively affected for extended periods of time and provides logging that can\n be used for forensic purposes.\n\n Note that user authentication and account management must be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP. This requirement applies to cases where accounts are\n directly managed by Oracle.\n\n Notwithstanding how accounts are normally managed, the DBMS must support\n the requirement to notify appropriate individuals upon account termination\n within Oracle. Indeed, in a configuration where accounts are managed\n externally, the manipulation of an account within Oracle may indicate hostile\n activity.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000294-DB-000129'\n tag \"gid\": 'V-61803'\n tag \"rid\": 'SV-76293r2_rule'\n tag \"stig_id\": 'O121-C2-020700'\n tag \"fix_id\": 'F-67719r1_fix'\n tag \"cci\": ['CCI-001686']\n tag \"nist\": ['AC-2 (4)', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Check DBMS settings to determine whether it will notify\n appropriate individuals when accounts are terminated.\n\n If the DBMS does not notify appropriate individuals when accounts are\n terminated, this is a finding.\"\n tag \"fix\": \"Working with the DBA and site management, determine the\n appropriate individuals (by job role) to be notified.\n\n If Oracle Audit Vault is available, configure it to notify the appropriate\n individuals when accounts are terminated.\n\n If Oracle Audit Vault is not available, configure the Oracle DBMS's auditing\n feature to record termination of accounts.\n\n If Standard Auditing is used:\n Create and deploy a mechanism, such as a frequently-run job, to monitor the\n SYS.AUD$ table for these records and notify the appropriate individuals.\n\n If unified Auditing is used:\n Create and deploy a mechanism, such as a frequently-run job, to monitor the\n SYS.UNIFIED_AUDIT_TRAIL view for these records and notify the appropriate\n individuals.\"\n describe 'A manual review is required to ensure the DBMS notifies the appropriate individuals when accounts are\n terminated' do\n skip 'A manual review is required to ensure the DBMS notifies the appropriate individuals when accounts are\n terminated'\n end\nend\n", + "code": " control 'V-61515' do\n impact 0.0\n describe 'This control is not applicable on oracle within aws rds, as aws manages the operating system in which the oracle database is running on' do\n skip 'This control is not applicable on oracle within aws rds, as aws manages the operating system in which the oracle database is running on'\n end\n end\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61803.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61515.rb", "line": 1 }, - "id": "V-61803" + "id": "V-61515" }, { - "title": "The DBMS must protect audit data records and integrity by using\n cryptographic mechanisms.", - "desc": "Protection of audit records and audit data is of critical importance.\n Cryptographic mechanisms are the industry-established standard used to protect\n the integrity of audit data. An example of a cryptographic mechanism is the\n computation and application of a cryptographic-signed hash using asymmetric\n cryptography.\n\n Non-repudiation protects individuals against later claims by an author of\n not having performed a particular action, a sender of not having transmitted a\n message, a receiver of not having received a message, or a signatory of not\n having signed a document.", + "title": "Plans and procedures for testing DBMS installations, upgrades and\n patches must be defined and followed prior to production implementation.", + "desc": "Updates and patches to existing software have the intention of\n improving the security or enhancing or adding features to the product. However,\n it is unfortunately common that updates or patches can render production\n systems inoperable or even introduce serious vulnerabilities. Some updates also\n set security configurations back to unacceptable settings that do not meet\n security requirements. For these reasons, it is a good practice to test updates\n and patches offline before introducing them in a production environment.", "descriptions": { - "default": "Protection of audit records and audit data is of critical importance.\n Cryptographic mechanisms are the industry-established standard used to protect\n the integrity of audit data. An example of a cryptographic mechanism is the\n computation and application of a cryptographic-signed hash using asymmetric\n cryptography.\n\n Non-repudiation protects individuals against later claims by an author of\n not having performed a particular action, a sender of not having transmitted a\n message, a receiver of not having received a message, or a signatory of not\n having signed a document." + "default": "Updates and patches to existing software have the intention of\n improving the security or enhancing or adding features to the product. However,\n it is unfortunately common that updates or patches can render production\n systems inoperable or even introduce serious vulnerabilities. Some updates also\n set security configurations back to unacceptable settings that do not meet\n security requirements. For these reasons, it is a good practice to test updates\n and patches offline before introducing them in a production environment." }, "impact": 0.5, "refs": [], "tags": { - "gtitle": "SRG-APP-000126-DB-000171", - "gid": "V-61667", - "rid": "SV-76157r2_rule", - "stig_id": "O121-C2-010100", - "fix_id": "F-67581r5_fix", + "gtitle": "SRG-APP-000516-DB-999900", + "gid": "V-61499", + "rid": "SV-75989r1_rule", + "stig_id": "O121-BP-024700", + "fix_id": "F-67415r1_fix", "cci": [ - "CCI-001350" + "CCI-000366" ], "nist": [ - "AU-9 (3)", + "CM-6 b", "Rev_4" ], "false_negatives": null, @@ -1405,30 +1401,79 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Review the DBMS settings to determine whether audit logging is\n configured to produce logs consistent with the amount of space allocated for\n logging.\n\n If auditing will generate excessive logs so that they may outgrow the space\n reserved for logging, this is a finding.\n\n If file-based auditing is in use, check that the file(s) is/are encrypted by\n the operating system/file system.\n\n If not, this is a finding\n\n If standard, table-based auditing is used: The audit logs are written to a\n table called AUD$, and if a Virtual Private Database is deployed, we also\n create a table called FGA_LOG$. First check the current location of the audit\n trail tables.\n\n CONN / AS SYSDBA\n\n SELECT table_name, tablespace_name\n FROM dba_tables\n WHERE table_name IN ('AUD$', 'FGA_LOG$')\n ORDER BY table_name;\n\n TABLE_NAME TABLESPACE_NAME\n ------------------------------ ------------------------------\n AUD$ SYSTEM\n FGA_LOG$ SYSTEM\n\n If the tablespace name is SYSTEM, the table needs to be relocated to its own\n tablespace. Ensure that adequate space is allocated to that tablespace.\n\n If Unified Auditing is used:\n Audit logs are written to tables in the AUDSYS schema. The default tablespace\n for AUDSYS is USERS. A separate tablespace should be created to contain audit\n data. Ensure that adequate space is allocated to that tablespace.", - "fix": "For file-based auditing (OS, XML, or XML,EXTENDED), implement\n operating system/file system encryption for the audit file.\n\n For table-based auditing, deploy the audit tables in an encrypted tablespace.\n\n - - - - -\n If auditing is not enabled, use the following steps to enable auditing.\n\n sqlplus connect as sysdba\n\n Turn on Oracle audit\n\n a. If the database uses an spfile\n\n SQL> alter system set audit_trail=DB,EXTENDED scope=spfile ;\n System altered.\n\n b. if database uses pfile, modify init.ora directly.\n For these changes to take place, the database must be restarted.\n\n Next we create an encrypted tablespace. Before tablespaces can be encrypted or\n decrypted, a master encryption key must be generated or set. The tablespace\n master encryption key is stored in an external security module and is used to\n encrypt the TDE tablespace encryption keys.\n\n - - - - -\n\n Caution: Do not attempt to encrypt Oracle internal objects such as the SYSTEM,\n SYSAUX, UNDO, or TEMP tablespaces. Oracle does not support this with TDE.\n When moving AUD$ to a new tablespace, be aware that associated LOB objects will\n also need to be moved. Finally, when upgrading, the AUD$ table and LOBs will\n need to be moved back to the SYSTEM tablespace or the upgrade will fail.\n\n - - - - -\n\n Check to ensure that the ENCRYPTION_WALLET_LOCATION (or WALLET_LOCATION)\n parameter in the sqlnet.ora file points to the correct software wallet\n location. (Note: This assumes that a single sqlnet.ora file, in the default\n location, is 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.) For example:\n\n ENCRYPTION_WALLET_LOCATION=\n (SOURCE=(METHOD=FILE)(METHOD_DATA=\n (DIRECTORY=/app/wallet)))\n\n If the ENCRYPTION_WALLET_LOCATION parameter is not set, then it attempts to use\n the keystore in the location that is specified by the parameter WALLET_LOCATION.\n\n If the WALLET_LOCATION parameter is also not set, then Oracle Database looks\n for a keystore at the default database location, which is\n ORACLE_BASE/admin/DB_UNIQUE_NAME/wallet or\n ORACLE_HOME/admin/DB_UNIQUE_NAME/wallet. (DB_UNIQUE_NAME is the unique name of\n the database specified in the initialization parameter file.) When the keystore\n location is not set in the sqlnet.ora file, then the V$ENCRYPTION_WALLET view\n displays the default location. Can check the location and status of the\n keystore in the V$ENCRYPTION_WALLET view.\n\n Oracle Database 12c Release 1 (12.1) uses the same master encryption key for\n both TDE column encryption and TDE tablespace encryption. When issuing the\n ALTER SYSTEM SET ENCRYPTION KEY command, a unified master encryption key is\n created for both TDE column encryption and TDE tablespace encryption.\n\n Resetting the Tablespace Master Encryption Key\n\n Oracle Database 12c Release 1 (12.1) uses a unified master encryption key for\n both TDE column encryption and TDE tablespace encryption. When resetting\n (rekeying) the master encryption key for TDE column encryption, the master\n encryption key for TDE tablespace encryption also gets reset. The ALTER SYSTEM\n SET ENCRYPTION KEY command resets the tablespace master encryption key. Before\n creating an encrypted tablespace, the Oracle wallet containing the tablespace\n master encryption key must be open. The wallet must also be open before\n accessing data in an encrypted tablespace. The security administrator needs to\n open the Oracle wallet after starting the Oracle instance. A restart of the\n Oracle instance requires the security administrator to open the wallet again.\n The security administrator also needs to open the wallet before performing\n database recovery operations. This is because background processes may require\n access to encrypted redo and undo logs. When performing database recovery, the\n wallet must be opened before opening the database. This is illustrated in the\n following statements:\n\n SQL> STARTUP MOUNT;\n SQL> ALTER SYSTEM SET ENCRYPTION WALLET OPEN IDENTIFIED BY \"password\";\n SQL> ALTER DATABASE OPEN;\n\n Can also choose to use auto logon wallets if the environment does not require\n the extra security provided by a wallet that needs to be explicitly opened;\n however, this is not the recommended practice.\n\n Creating the wallet/keystore\n\n SQL> ADMINISTER KEY MANAGEMENT CREATE KEYSTORE '/app/wallet' IDENTIFIED BY\n password;\n\n keystore altered.\n\n Set the TDE Master Encryption Key in the Software Keystore\n\n SQL> ADMINISTER KEY MANAGEMENT SET KEY IDENTIFIED BY password WITH BACKUP USING\n 'backup_identifier';\n\n keystore altered.\n\n Creating an Encrypted Tablespace\n\n The CREATE TABLESPACE command enables the creation of an encrypted tablespace.\n The permanent_tablespace_clause enables choosing the encryption algorithm and\n the key length for encryption. The ENCRYPT keyword in the storage_clause\n encrypts the tablespace. The following syntax illustrates this:\n\n CREATE\n [ BIGFILE | SMALLFILE ]\n { permanent_tablespace_clause\n | temporary_tablespace_clause\n | undo_tablespace_clause\n } ;\n\n Where, permanent_tablespace_clause=TABLESPACE , ENCRYPTION [USING algorithm]\n storage_clause\n Where, storage_clause=[ENCRYPT] where:\n\n The encryption algorithm can have one of the following values:\n\n 3DES168\n AES128\n AES192\n AES256\n\n The key lengths are included in the names of the algorithms themselves. If no\n encryption algorithm is specified, the default encryption algorithm is used.\n The default encryption algorithm is AES128.\n\n Note: The ENCRYPTION keyword in the permanent_tablespace_clause is used to\n specify the encryption algorithm. The ENCRYPT keyword in the storage_clause\n actually encrypts the tablespace. For security reasons, a tablespace cannot be\n encrypted with the NO SALT option.\n\n Commands to create Encrypted Tablespace\n\n CREATE TABLESPACE securespace\n DATAFILE '/home/user/oradata/secure01.dbf'\n SIZE 150M\n ENCRYPTION USING '3DES168'\n DEFAULT STORAGE(ENCRYPT);\n\n This creates a tablespace called securespace2 using an algorithm of 3DES168.\n\n Cannot encrypt an existing tablespace. However, can import data into an\n encrypted tablespace using the Oracle Data Pump utility. Can also use SQL\n commands like CREATE TABLE...AS SELECT...or ALTER TABLE...MOVE... to move data\n into an encrypted tablespace. The CREATE TABLE...AS SELECT... command enables\n the creation of a table from an existing table. The ALTER TABLE...MOVE...\n command enables the move of a table into the encrypted tablespace.\n\n Then we move the sys.aud$ from system tablespace to securespace tablespace.\n\n SQL> exec DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_LOCATION(audit_trail_type =>\n DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD, audit_trail_location_value =>\n 'securespace');\n\n PL/SQL procedure successfully completed.\n\n Then check the tablespace the table is stored in.\n\n SQL> SELECT table_name, tablespace_name FROM dba_tables WHERE table_name\n ='AUD$';\n\n TABLE_NAME TABLESPACE_NAME\n ---------------------------- ------------------------\n AUD$ SECURESPACE" + "check": "Review policy and procedures documented or noted in the System\n Security Plan and evidence of implementation for testing DBMS installations,\n upgrades and patches prior to production deployment.\n\n If policy and procedures do not exist or evidence of implementation does not\n exist, this is a finding.", + "fix": "Develop, document and implement procedures for testing DBMS\n installations, upgrades and patches prior to deployment on production systems." }, - "code": "control 'V-61667' do\n title \"The DBMS must protect audit data records and integrity by using\n cryptographic mechanisms.\"\n desc \"Protection of audit records and audit data is of critical importance.\n Cryptographic mechanisms are the industry-established standard used to protect\n the integrity of audit data. An example of a cryptographic mechanism is the\n computation and application of a cryptographic-signed hash using asymmetric\n cryptography.\n\n Non-repudiation protects individuals against later claims by an author of\n not having performed a particular action, a sender of not having transmitted a\n message, a receiver of not having received a message, or a signatory of not\n having signed a document.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000126-DB-000171'\n tag \"gid\": 'V-61667'\n tag \"rid\": 'SV-76157r2_rule'\n tag \"stig_id\": 'O121-C2-010100'\n tag \"fix_id\": 'F-67581r5_fix'\n tag \"cci\": ['CCI-001350']\n tag \"nist\": ['AU-9 (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\": \"Review the DBMS settings to determine whether audit logging is\n configured to produce logs consistent with the amount of space allocated for\n logging.\n\n If auditing will generate excessive logs so that they may outgrow the space\n reserved for logging, this is a finding.\n\n If file-based auditing is in use, check that the file(s) is/are encrypted by\n the operating system/file system.\n\n If not, this is a finding\n\n If standard, table-based auditing is used: The audit logs are written to a\n table called AUD$, and if a Virtual Private Database is deployed, we also\n create a table called FGA_LOG$. First check the current location of the audit\n trail tables.\n\n CONN / AS SYSDBA\n\n SELECT table_name, tablespace_name\n FROM dba_tables\n WHERE table_name IN ('AUD$', 'FGA_LOG$')\n ORDER BY table_name;\n\n TABLE_NAME TABLESPACE_NAME\n ------------------------------ ------------------------------\n AUD$ SYSTEM\n FGA_LOG$ SYSTEM\n\n If the tablespace name is SYSTEM, the table needs to be relocated to its own\n tablespace. Ensure that adequate space is allocated to that tablespace.\n\n If Unified Auditing is used:\n Audit logs are written to tables in the AUDSYS schema. The default tablespace\n for AUDSYS is USERS. A separate tablespace should be created to contain audit\n data. Ensure that adequate space is allocated to that tablespace.\"\n tag \"fix\": \"For file-based auditing (OS, XML, or XML,EXTENDED), implement\n operating system/file system encryption for the audit file.\n\n For table-based auditing, deploy the audit tables in an encrypted tablespace.\n\n - - - - -\n If auditing is not enabled, use the following steps to enable auditing.\n\n sqlplus connect as sysdba\n\n Turn on Oracle audit\n\n a. If the database uses an spfile\n\n SQL> alter system set audit_trail=DB,EXTENDED scope=spfile ;\n System altered.\n\n b. if database uses pfile, modify init.ora directly.\n For these changes to take place, the database must be restarted.\n\n Next we create an encrypted tablespace. Before tablespaces can be encrypted or\n decrypted, a master encryption key must be generated or set. The tablespace\n master encryption key is stored in an external security module and is used to\n encrypt the TDE tablespace encryption keys.\n\n - - - - -\n\n Caution: Do not attempt to encrypt Oracle internal objects such as the SYSTEM,\n SYSAUX, UNDO, or TEMP tablespaces. Oracle does not support this with TDE.\n When moving AUD$ to a new tablespace, be aware that associated LOB objects will\n also need to be moved. Finally, when upgrading, the AUD$ table and LOBs will\n need to be moved back to the SYSTEM tablespace or the upgrade will fail.\n\n - - - - -\n\n Check to ensure that the ENCRYPTION_WALLET_LOCATION (or WALLET_LOCATION)\n parameter in the sqlnet.ora file points to the correct software wallet\n location. (Note: This assumes that a single sqlnet.ora file, in the default\n location, is 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.) For example:\n\n ENCRYPTION_WALLET_LOCATION=\n (SOURCE=(METHOD=FILE)(METHOD_DATA=\n (DIRECTORY=/app/wallet)))\n\n If the ENCRYPTION_WALLET_LOCATION parameter is not set, then it attempts to use\n the keystore in the location that is specified by the parameter WALLET_LOCATION.\n\n If the WALLET_LOCATION parameter is also not set, then Oracle Database looks\n for a keystore at the default database location, which is\n ORACLE_BASE/admin/DB_UNIQUE_NAME/wallet or\n ORACLE_HOME/admin/DB_UNIQUE_NAME/wallet. (DB_UNIQUE_NAME is the unique name of\n the database specified in the initialization parameter file.) When the keystore\n location is not set in the sqlnet.ora file, then the V$ENCRYPTION_WALLET view\n displays the default location. Can check the location and status of the\n keystore in the V$ENCRYPTION_WALLET view.\n\n Oracle Database 12c Release 1 (12.1) uses the same master encryption key for\n both TDE column encryption and TDE tablespace encryption. When issuing the\n ALTER SYSTEM SET ENCRYPTION KEY command, a unified master encryption key is\n created for both TDE column encryption and TDE tablespace encryption.\n\n Resetting the Tablespace Master Encryption Key\n\n Oracle Database 12c Release 1 (12.1) uses a unified master encryption key for\n both TDE column encryption and TDE tablespace encryption. When resetting\n (rekeying) the master encryption key for TDE column encryption, the master\n encryption key for TDE tablespace encryption also gets reset. The ALTER SYSTEM\n SET ENCRYPTION KEY command resets the tablespace master encryption key. Before\n creating an encrypted tablespace, the Oracle wallet containing the tablespace\n master encryption key must be open. The wallet must also be open before\n accessing data in an encrypted tablespace. The security administrator needs to\n open the Oracle wallet after starting the Oracle instance. A restart of the\n Oracle instance requires the security administrator to open the wallet again.\n The security administrator also needs to open the wallet before performing\n database recovery operations. This is because background processes may require\n access to encrypted redo and undo logs. When performing database recovery, the\n wallet must be opened before opening the database. This is illustrated in the\n following statements:\n\n SQL> STARTUP MOUNT;\n SQL> ALTER SYSTEM SET ENCRYPTION WALLET OPEN IDENTIFIED BY \\\"password\\\";\n SQL> ALTER DATABASE OPEN;\n\n Can also choose to use auto logon wallets if the environment does not require\n the extra security provided by a wallet that needs to be explicitly opened;\n however, this is not the recommended practice.\n\n Creating the wallet/keystore\n\n SQL> ADMINISTER KEY MANAGEMENT CREATE KEYSTORE '/app/wallet' IDENTIFIED BY\n password;\n\n keystore altered.\n\n Set the TDE Master Encryption Key in the Software Keystore\n\n SQL> ADMINISTER KEY MANAGEMENT SET KEY IDENTIFIED BY password WITH BACKUP USING\n 'backup_identifier';\n\n keystore altered.\n\n Creating an Encrypted Tablespace\n\n The CREATE TABLESPACE command enables the creation of an encrypted tablespace.\n The permanent_tablespace_clause enables choosing the encryption algorithm and\n the key length for encryption. The ENCRYPT keyword in the storage_clause\n encrypts the tablespace. The following syntax illustrates this:\n\n CREATE\n [ BIGFILE | SMALLFILE ]\n { permanent_tablespace_clause\n | temporary_tablespace_clause\n | undo_tablespace_clause\n } ;\n\n Where, permanent_tablespace_clause=TABLESPACE , ENCRYPTION [USING algorithm]\n storage_clause\n Where, storage_clause=[ENCRYPT] where:\n\n The encryption algorithm can have one of the following values:\n\n 3DES168\n AES128\n AES192\n AES256\n\n The key lengths are included in the names of the algorithms themselves. If no\n encryption algorithm is specified, the default encryption algorithm is used.\n The default encryption algorithm is AES128.\n\n Note: The ENCRYPTION keyword in the permanent_tablespace_clause is used to\n specify the encryption algorithm. The ENCRYPT keyword in the storage_clause\n actually encrypts the tablespace. For security reasons, a tablespace cannot be\n encrypted with the NO SALT option.\n\n Commands to create Encrypted Tablespace\n\n CREATE TABLESPACE securespace\n DATAFILE '/home/user/oradata/secure01.dbf'\n SIZE 150M\n ENCRYPTION USING '3DES168'\n DEFAULT STORAGE(ENCRYPT);\n\n This creates a tablespace called securespace2 using an algorithm of 3DES168.\n\n Cannot encrypt an existing tablespace. However, can import data into an\n encrypted tablespace using the Oracle Data Pump utility. Can also use SQL\n commands like CREATE TABLE...AS SELECT...or ALTER TABLE...MOVE... to move data\n into an encrypted tablespace. The CREATE TABLE...AS SELECT... command enables\n the creation of a table from an existing table. The ALTER TABLE...MOVE...\n command enables the move of a table into the encrypted tablespace.\n\n Then we move the sys.aud$ from system tablespace to securespace tablespace.\n\n SQL> exec DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_LOCATION(audit_trail_type =>\n DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD, audit_trail_location_value =>\n 'securespace');\n\n PL/SQL procedure successfully completed.\n\n Then check the tablespace the table is stored in.\n\n SQL> SELECT table_name, tablespace_name FROM dba_tables WHERE table_name\n ='AUD$';\n\n TABLE_NAME TABLESPACE_NAME\n ---------------------------- ------------------------\n AUD$ SECURESPACE\"\n describe 'A manual review is required to ensure the DBMS must protect audit data records and integrity by using\n cryptographic mechanisms' do\n skip 'A manual review is required to ensure the DBMS must protect audit data records and integrity by using\n cryptographic mechanisms'\n end\nend\n", + "code": "control 'V-61499' do\n title \"Plans and procedures for testing DBMS installations, upgrades and\n patches must be defined and followed prior to production implementation.\"\n desc \"Updates and patches to existing software have the intention of\n improving the security or enhancing or adding features to the product. However,\n it is unfortunately common that updates or patches can render production\n systems inoperable or even introduce serious vulnerabilities. Some updates also\n set security configurations back to unacceptable settings that do not meet\n security requirements. For these reasons, it is a good practice to test updates\n and patches offline before introducing them in a production environment.\"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000516-DB-999900'\n tag \"gid\": 'V-61499'\n tag \"rid\": 'SV-75989r1_rule'\n tag \"stig_id\": 'O121-BP-024700'\n tag \"fix_id\": 'F-67415r1_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 and evidence of implementation for testing DBMS installations,\n upgrades and patches prior to production deployment.\n\n If policy and procedures do not exist or evidence of implementation does not\n exist, this is a finding.\"\n tag \"fix\": \"Develop, document and implement procedures for testing DBMS\n installations, upgrades and patches prior to deployment on production systems.\"\n describe 'A manual review is required to ensure plans and procedures for testing DBMS installations, upgrades and\n patches are defined and followed prior to production implementation' do\n skip 'A manual review is required to ensure plans and procedures for testing DBMS installations, upgrades and\n patches are defined and followed prior to production implementation'\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61667.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61499.rb", "line": 1 }, - "id": "V-61667" + "id": "V-61499" }, { - "title": "Administrators must utilize a separate, distinct administrative\n account when performing administrative activities, accessing database security\n functions, or accessing security-relevant information.", - "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 When privileged activities are not separated from non-privileged\n activities, the database can be subject to unauthorized changes to settings and\n data that a standard user would not normally have access to, outside of an\n authorized maintenance session.", + "title": "The DBMS must map the authenticated identity to the user account using\n PKI-based authentication.", + "desc": "The cornerstone of the PKI is the private key used to encrypt or\n digitally sign information. The key by itself is a cryptographic value that\n does not contain specific user information.\n\n When including the DBMS in the Private Key Infrastructure, the\n authenticated user must map directly to a user account in the DBMS. If the user\n account is not directly tied to the authenticated identity, there is no way to\n know which, if any, database user account has been authorized.\n\n Transport Layer Security (TLS) is the successor protocol to Secure Sockets\n Layer (SSL). Although the Oracle configuration parameters have names including\n 'SSL', such as SSL_VERSION and SSL_CIPHER_SUITES, they refer to TLS.", "descriptions": { - "default": "This requirement is intended to limit exposure due to operating from\n within a privileged account or role. The inclusion of role is intended to\n address those situations where an access control policy, such as Role Based\n Access Control (RBAC), is being implemented and where a change of role provides\n the same degree of assurance in the change of access authorizations for both\n the user and all processes acting on behalf of the user as would be provided by\n a change between a privileged and non-privileged account.\n\n To limit exposure when operating from within a privileged account or role,\n the application must support organizational requirements that users of\n information system accounts, or roles, with access to organization-defined\n lists of security functions or security-relevant information, use\n non-privileged accounts, or roles, when accessing other (non-security) system\n functions.\n\n When privileged activities are not separated from non-privileged\n activities, the database can be subject to unauthorized changes to settings and\n data that a standard user would not normally have access to, outside of an\n authorized maintenance session." + "default": "The cornerstone of the PKI is the private key used to encrypt or\n digitally sign information. The key by itself is a cryptographic value that\n does not contain specific user information.\n\n When including the DBMS in the Private Key Infrastructure, the\n authenticated user must map directly to a user account in the DBMS. If the user\n account is not directly tied to the authenticated identity, there is no way to\n know which, if any, database user account has been authorized.\n\n Transport Layer Security (TLS) is the successor protocol to Secure Sockets\n Layer (SSL). Although the Oracle configuration parameters have names including\n 'SSL', such as SSL_VERSION and SSL_CIPHER_SUITES, they refer to TLS." }, - "impact": 0.5, - "refs": [], + "impact": 0, + "refs": [ + { + "ref": [] + } + ], "tags": { - "gtitle": "SRG-APP-000063-DB-000017", - "gid": "V-61593", - "rid": "SV-76083r2_rule", - "stig_id": "O121-C2-004100", - "fix_id": "F-67509r1_fix", + "gtitle": "SRG-APP-000177-DB-000069", + "gid": "V-61743", + "rid": "SV-76233r2_rule", + "stig_id": "O121-C2-015500", + "fix_id": "F-67659r1_fix", + "cci": [ + "CCI-000187" + ], + "nist": [ + "IA-5 (2) (c)", + "Rev_4" + ], + "false_negatives": null, + "false_positives": null, + "documentable": false, + "mitigations": null, + "severity_override_guidance": false, + "potential_impacts": null, + "third_party_tools": null, + "mitigation_controls": null, + "responsibility": null, + "ia_controls": null, + "check": "Review DBMS configuration to verify DBMS user accounts are\n being mapped directly to authenticated identity information being passed via\n the PKI.\n\n If user accounts are not being mapped to authenticated identity information\n being passed via the PKI, this is a finding.\n\n - - - - -\n The database supports PKI-based authentication by using digital certificates\n over TLS in addition to the native encryption and data integrity capabilities\n of these protocols.\n\n Oracle provides a complete PKI that is based on RSA Security, Inc., Public-Key\n Cryptography Standards, and which interoperates with Oracle servers and\n clients. The database uses a wallet that is a container that is used to store\n authentication and signing credentials, including private keys, certificates,\n and trusted certificates needed by TLS. In an Oracle environment, every entity\n that communicates over TLS must have a wallet containing an X.509 version 3\n certificate, private key, and list of trusted certificates. Security\n administrators use Oracle Wallet Manager to manage security credentials on the\n server.\n\n If the $ORACLE_HOME/network/admin/sqlnet.ora contains the following entries,\n TLS is installed. (Note: This assumes that a single sqlnet.ora file, in the\n default location, is in use. Please see the supplemental file \"Non-default\n sqlnet.ora configurations.pdf\" for how to find multiple and/or differently\n located sqlnet.ora files.)\n\n WALLET_LOCATION = (SOURCE=\n (METHOD = FILE)\n (METHOD_DATA =\n DIRECTORY=/wallet)\n\n SSL_CIPHER_SUITES=(SSL_cipher_suiteExample)\n SSL_VERSION = 1.2 or 1.1\n SSL_CLIENT_AUTHENTICATION=FALSE/TRUE\n\n Note: \"SSL_VERSION = 1.2 or 1.1\" is the actual value, not a suggestion to\n use one or the other.", + "fix": "Configure the DBMS to map the authenticated identity directly to\n the DBMS user account." + }, + "code": " control 'V-61743' do\n impact 0.0\n describe 'This control is not applicable on oracle within aws rds, as aws manages the operating system in which the oracle database is running on' do\n skip 'This control is not applicable on oracle within aws rds, as aws manages the operating system in which the oracle database is running on'\n end\n end\n", + "source_location": { + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61743.rb", + "line": 1 + }, + "id": "V-61743" + }, + { + "title": "Remote administration must be disabled for the Oracle connection\n manager.", + "desc": "Remote administration provides a potential opportunity for malicious\n users to make unauthorized changes to the Connection Manager configuration or\n interrupt its service.", + "descriptions": { + "default": "Remote administration provides a potential opportunity for malicious\n users to make unauthorized changes to the Connection Manager configuration or\n interrupt its service." + }, + "impact": 0, + "refs": [ + { + "ref": [] + } + ], + "tags": { + "gtitle": "SRG-APP-000516-DB-999900", + "gid": "V-61533", + "rid": "SV-76023r1_rule", + "stig_id": "O121-BP-026500", + "fix_id": "F-67449r1_fix", "cci": [ "CCI-000366" ], @@ -1446,35 +1491,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Review permissions for objects owned by DBA or other\n administrative accounts.\n\n If any objects owned by administrative accounts can be accessed by\n non-DBA/non-administrative users, either directly or indirectly, this is a\n finding.\n\n Verify DBAs have separate administrative accounts.\n\n If DBAs do not have a separate account for database administration purposes,\n this is a finding.\n\n To list all objects owned by an administrative account that have had access\n granted to another account, run the query:\n\n SELECT grantee, table_name, grantor, privilege, type from dba_tab_privs where\n owner= '';\n ", - "fix": "Revoke DBA privileges, and privileges to administer DBA-owned\n objects, from non-DBA accounts.\n\n Provide separate accounts to DBA for database administration." + "check": "View the cman.ora file in the ORACLE_HOME/network/admin\n directory.\n\n If the file does not exist, the database is not accessed via Oracle Connection\n Manager and this check is not a finding.\n\n If the entry and value for REMOTE_ADMIN is not listed or is not set to a value\n of NO (REMOTE_ADMIN = NO), this is a finding.", + "fix": "View the cman.ora file in the ORACLE_HOME/network/admin directory\n of the Connection Manager.\n\n Include the following line in the file:\n\n REMOTE_ADMIN = NO" }, - "code": "control 'V-61593' do\n title \"Administrators must utilize a separate, distinct administrative\n account when performing administrative activities, accessing database security\n functions, or accessing security-relevant information.\"\n desc \"This requirement is intended to limit exposure due to operating from\n within a privileged account or role. The inclusion of role is intended to\n address those situations where an access control policy, such as Role Based\n Access Control (RBAC), is being implemented and where a change of role provides\n the same degree of assurance in the change of access authorizations for both\n the user and all processes acting on behalf of the user as would be provided by\n a change between a privileged and non-privileged account.\n\n To limit exposure when operating from within a privileged account or role,\n the application must support organizational requirements that users of\n information system accounts, or roles, with access to organization-defined\n lists of security functions or security-relevant information, use\n non-privileged accounts, or roles, when accessing other (non-security) system\n functions.\n\n When privileged activities are not separated from non-privileged\n activities, the database can be subject to unauthorized changes to settings and\n data that a standard user would not normally have access to, outside of an\n authorized maintenance session.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000063-DB-000017'\n tag \"gid\": 'V-61593'\n tag \"rid\": 'SV-76083r2_rule'\n tag \"stig_id\": 'O121-C2-004100'\n tag \"fix_id\": 'F-67509r1_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 permissions for objects owned by DBA or other\n administrative accounts.\n\n If any objects owned by administrative accounts can be accessed by\n non-DBA/non-administrative users, either directly or indirectly, this is a\n finding.\n\n Verify DBAs have separate administrative accounts.\n\n If DBAs do not have a separate account for database administration purposes,\n this is a finding.\n\n To list all objects owned by an administrative account that have had access\n granted to another account, run the query:\n\n SELECT grantee, table_name, grantor, privilege, type from dba_tab_privs where\n owner= '';\n \"\n tag \"fix\": \"Revoke DBA privileges, and privileges to administer DBA-owned\n objects, from non-DBA accounts.\n\n Provide separate accounts to DBA for database administration.\"\n describe 'A manual review is required to ensure administrators must utilize a separate, distinct administrative\n account when performing administrative activities, accessing database security\n functions, or accessing security-relevant information' do\n skip 'A manual review is required to ensure administrators must utilize a separate, distinct administrative\n account when performing administrative activities, accessing database security\n functions, or accessing security-relevant information'\n end\nend\n", + "code": " control 'V-61533' do\n impact 0.0\n describe 'This control is not applicable on oracle within aws rds, as aws manages the operating system in which the oracle database is running on' do\n skip 'This control is not applicable on oracle within aws rds, as aws manages the operating system in which the oracle database is running on'\n end\n end\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61593.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61533.rb", "line": 1 }, - "id": "V-61593" + "id": "V-61533" }, { - "title": "The DBMS must automatically terminate emergency accounts after an\n organization-defined time period for each type of account.", - "desc": "Emergency application accounts are typically created due to an\n unforeseen operational event or could ostensibly be used in the event of a\n vendor support visit where a support representative requires a temporary unique\n account in order to perform diagnostic testing or conduct some other\n support-related activity. When these types of accounts are created, there is a\n risk that the temporary account may remain in place and active after the\n support representative has left.\n\n In the event emergency application accounts are required, the application\n must ensure accounts that are designated as temporary in nature shall\n automatically terminate these accounts after an organization-defined time\n period. Such a process and capability greatly reduces the risk that accounts\n will be misused, hijacked, or application data compromised.\n\n Note that user authentication and account management must be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP. This requirement applies to cases where it is necessary to\n have accounts directly managed by Oracle.\n\n If it is possible for any temporary emergency accounts to be created and\n managed by Oracle, then the DBMS or application must provide or utilize a\n mechanism to automatically terminate such accounts after an\n organization-defined time period.\n\n Emergency database accounts must be automatically terminated after an\n organization-defined time period in order to mitigate the risk of the account\n being misused.", + "title": "Replication accounts must not be granted DBA privileges.", + "desc": "Replication accounts may be used to access databases defined for the\n replication architecture. An exploit of a replication on one database could\n lead to the compromise of any database participating in the replication that\n uses the same account name and credentials. If the replication account is\n compromised and it has DBA privileges, the database is at additional risk to\n unauthorized or malicious action.", "descriptions": { - "default": "Emergency application accounts are typically created due to an\n unforeseen operational event or could ostensibly be used in the event of a\n vendor support visit where a support representative requires a temporary unique\n account in order to perform diagnostic testing or conduct some other\n support-related activity. When these types of accounts are created, there is a\n risk that the temporary account may remain in place and active after the\n support representative has left.\n\n In the event emergency application accounts are required, the application\n must ensure accounts that are designated as temporary in nature shall\n automatically terminate these accounts after an organization-defined time\n period. Such a process and capability greatly reduces the risk that accounts\n will be misused, hijacked, or application data compromised.\n\n Note that user authentication and account management must be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP. This requirement applies to cases where it is necessary to\n have accounts directly managed by Oracle.\n\n If it is possible for any temporary emergency accounts to be created and\n managed by Oracle, then the DBMS or application must provide or utilize a\n mechanism to automatically terminate such accounts after an\n organization-defined time period.\n\n Emergency database accounts must be automatically terminated after an\n organization-defined time period in order to mitigate the risk of the account\n being misused." + "default": "Replication accounts may be used to access databases defined for the\n replication architecture. An exploit of a replication on one database could\n lead to the compromise of any database participating in the replication that\n uses the same account name and credentials. If the replication account is\n compromised and it has DBA privileges, the database is at additional risk to\n unauthorized or malicious action." }, "impact": 0.5, "refs": [], "tags": { - "gtitle": "SRG-APP-000234-DB-000157", - "gid": "V-61777", - "rid": "SV-76267r1_rule", - "stig_id": "O121-C2-018600", - "fix_id": "F-67693r1_fix", + "gtitle": "SRG-APP-000516-DB-999900", + "gid": "V-61513", + "rid": "SV-76003r1_rule", + "stig_id": "O121-BP-025500", + "fix_id": "F-67429r1_fix", "cci": [ - "CCI-001682" + "CCI-000366" ], "nist": [ - "AC-2 (2)", + "CM-6 b", "Rev_4" ], "false_negatives": null, @@ -1487,21 +1532,21 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "If the organization has a policy, consistently enforced,\n forbidding the creation of emergency or temporary accounts, this is not a\n finding.\n\n Check DBMS settings, OS settings, and/or enterprise-level authentication/access\n mechanisms settings to determine if emergency accounts are being automatically\n terminated by the system after an organization-defined time period. Check also\n for custom code (scheduled jobs, procedures, triggers, etc.) for achieving\n this.\n\n If emergency accounts are not being terminated after an organization-defined\n time period, this is a finding.", - "fix": "Create a profile specifically for emergency or temporary\n accounts. When creating the accounts, assign them to this profile. Configure\n DBMS, OS, and/or enterprise-level authentication/access mechanisms, or\n implement custom code, to terminate accounts with this profile after an\n organization-defined time period." + "check": "If a review of the System Security Plan confirms the use of\n replication is not required, not permitted and the database is not configured\n for replication, this check is not a finding.\n\n If any replication accounts are assigned DBA roles or roles with DBA\n privileges, this is a finding.", + "fix": "Restrict privileges assigned to replication accounts to the\n fewest possible privileges.\n\n Remove DBA roles from replication accounts.\n\n Create and use custom replication accounts assigned least privileges for\n supporting replication operations." }, - "code": "control 'V-61777' do\n title \"The DBMS must automatically terminate emergency accounts after an\n organization-defined time period for each type of account.\"\n desc \"Emergency application accounts are typically created due to an\n unforeseen operational event or could ostensibly be used in the event of a\n vendor support visit where a support representative requires a temporary unique\n account in order to perform diagnostic testing or conduct some other\n support-related activity. When these types of accounts are created, there is a\n risk that the temporary account may remain in place and active after the\n support representative has left.\n\n In the event emergency application accounts are required, the application\n must ensure accounts that are designated as temporary in nature shall\n automatically terminate these accounts after an organization-defined time\n period. Such a process and capability greatly reduces the risk that accounts\n will be misused, hijacked, or application data compromised.\n\n Note that user authentication and account management must be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP. This requirement applies to cases where it is necessary to\n have accounts directly managed by Oracle.\n\n If it is possible for any temporary emergency accounts to be created and\n managed by Oracle, then the DBMS or application must provide or utilize a\n mechanism to automatically terminate such accounts after an\n organization-defined time period.\n\n Emergency database accounts must be automatically terminated after an\n organization-defined time period in order to mitigate the risk of the account\n being misused.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000234-DB-000157'\n tag \"gid\": 'V-61777'\n tag \"rid\": 'SV-76267r1_rule'\n tag \"stig_id\": 'O121-C2-018600'\n tag \"fix_id\": 'F-67693r1_fix'\n tag \"cci\": ['CCI-001682']\n tag \"nist\": ['AC-2 (2)', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"If the organization has a policy, consistently enforced,\n forbidding the creation of emergency or temporary accounts, this is not a\n finding.\n\n Check DBMS settings, OS settings, and/or enterprise-level authentication/access\n mechanisms settings to determine if emergency accounts are being automatically\n terminated by the system after an organization-defined time period. Check also\n for custom code (scheduled jobs, procedures, triggers, etc.) for achieving\n this.\n\n If emergency accounts are not being terminated after an organization-defined\n time period, this is a finding.\"\n tag \"fix\": \"Create a profile specifically for emergency or temporary\n accounts. When creating the accounts, assign them to this profile. Configure\n DBMS, OS, and/or enterprise-level authentication/access mechanisms, or\n implement custom code, to terminate accounts with this profile after an\n organization-defined time period.\"\n describe 'A manual review is required to ensure the DBMS automatically terminates emergency accounts after an\n organization-defined time period for each type of account' do\n skip 'A manual review is required to ensure the DBMS automatically terminates emergency accounts after an\n organization-defined time period for each type of account'\n end\nend\n", + "code": "control 'V-61513' do\n title 'Replication accounts must not be granted DBA privileges.'\n desc \"Replication accounts may be used to access databases defined for the\n replication architecture. An exploit of a replication on one database could\n lead to the compromise of any database participating in the replication that\n uses the same account name and credentials. If the replication account is\n compromised and it has DBA privileges, the database is at additional risk to\n unauthorized or malicious action.\"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000516-DB-999900'\n tag \"gid\": 'V-61513'\n tag \"rid\": 'SV-76003r1_rule'\n tag \"stig_id\": 'O121-BP-025500'\n tag \"fix_id\": 'F-67429r1_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 a review of the System Security Plan confirms the use of\n replication is not required, not permitted and the database is not configured\n for replication, this check is not a finding.\n\n If any replication accounts are assigned DBA roles or roles with DBA\n privileges, this is a finding.\"\n tag \"fix\": \"Restrict privileges assigned to replication accounts to the\n fewest possible privileges.\n\n Remove DBA roles from replication accounts.\n\n Create and use custom replication accounts assigned least privileges for\n supporting replication operations.\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n is_oracle_replication_used = sql.query(\"select count(*) from all_tables\n where table_name like 'REPCAT%';\").column('count(*)')\n\n oracle_replication_accounts = sql.query('select * from sys.dba_repcatlog;').column('gname')\n\n if !is_oracle_replication_used.include?('0')\n describe \"The ISSO or DBA must manually ensure the following replication accounts are justified and are not granted DBA privileges: #{oracle_replication_accounts}\" do\n skip \"The ISSO or DBA must manually ensure the following replication accounts are justified and are not granted DBA privileges: #{oracle_replication_accounts}\"\n end\n else\n describe 'The number of replication accounts defined' do\n subject { is_oracle_replication_used }\n it { should cmp 0 }\n end\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61777.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61513.rb", "line": 1 }, - "id": "V-61777" + "id": "V-61513" }, { - "title": "The DBMS must use multifactor authentication for local access to\n privileged accounts.", - "desc": "Multifactor authentication is defined as using two or more factors to\n achieve authentication.\n\n Factors include:\n (i) Something a user knows (e.g., password/PIN);\n (ii) Something a user has (e.g., cryptographic identification device,\n token); or\n (iii) Something a user is (e.g., biometric).\n\n A privileged account is defined as an information system account with\n authorizations of a privileged user.\n\n Local Access is defined as access to an organizational information system\n by a user (or process acting on behalf of a user) communicating through a\n direct connection without the use of a network.\n\n The lack of multifactor authentication makes it much easier for an attacker\n to gain unauthorized access to a system.\n\n Transport Layer Security (TLS) is the successor protocol to Secure Sockets\n Layer (SSL). Although the Oracle configuration parameters have names including\n 'SSL', such as SSL_VERSION and SSL_CIPHER_SUITES, they refer to TLS.", + "title": "Connections by mid-tier web and application systems to the Oracle DBMS\n from a DMZ or external network must be encrypted.\n ", + "desc": "Multi-tier systems may be configured with the database and connecting\n middle-tier system located on an internal network, with the database located on\n an internal network behind a firewall and the middle-tier system located in a\n DMZ. In cases where either or both systems are located in the DMZ (or on\n networks external to DoD), network communications between the systems must be\n encrypted.", "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 Local Access is defined as access to an organizational information system\n by a user (or process acting on behalf of a user) communicating through a\n direct connection without the use of a network.\n\n The lack of multifactor authentication makes it much easier for an attacker\n to gain unauthorized access to a system.\n\n Transport Layer Security (TLS) is the successor protocol to Secure Sockets\n Layer (SSL). Although the Oracle configuration parameters have names including\n 'SSL', such as SSL_VERSION and SSL_CIPHER_SUITES, they refer to TLS." + "default": "Multi-tier systems may be configured with the database and connecting\n middle-tier system located on an internal network, with the database located on\n an internal network behind a firewall and the middle-tier system located in a\n DMZ. In cases where either or both systems are located in the DMZ (or on\n networks external to DoD), network communications between the systems must be\n encrypted." }, "impact": 0, "refs": [ @@ -1510,16 +1555,16 @@ } ], "tags": { - "gtitle": "SRG-APP-000151-DB-000106", - "gid": "V-61707", - "rid": "SV-76197r2_rule", - "stig_id": "O121-C2-013100", - "fix_id": "F-67623r1_fix", + "gtitle": "SRG-APP-000516-DB-999900", + "gid": "V-61447", + "rid": "SV-75937r2_rule", + "stig_id": "O121-BP-023000", + "fix_id": "F-67363r2_fix", "cci": [ - "CCI-000767" + "CCI-000366" ], "nist": [ - "IA-2 (3)", + "CM-6 b", "Rev_4" ], "false_negatives": null, @@ -1532,36 +1577,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 locally are required to use multifactor authentication.\n\n If users logging on to privileged accounts locally are not required to use\n multifactor authentication, this is a finding.\n\n Use authentication to prove the identities of users who are attempting to log\n on to the database. Authenticating user identity is imperative in distributed\n environments, without which there can be little confidence in network security.\n Passwords are the most common means of authentication. Oracle Database enables\n strong authentication with Oracle authentication adapters that support various\n third-party authentication services, including TLS with digital certificates.\n\n If the $ORACLE_HOME/network/admin/sqlnet.ora contains entries similar to the\n following, TLS is enabled.\n (Note: This assumes that a single sqlnet.ora file, in the default location, is\n in use. Please see the supplemental file \"Non-default sqlnet.ora\n configurations.pdf\" for how to find multiple and/or differently located\n sqlnet.ora files.)\n\n SQLNET.AUTHENTICATION_SERVICES= (BEQ, TCPS)\n SSL_VERSION = 1.2 or 1.1\n SSL_CLIENT_AUTHENTICATION = TRUE\n WALLET_LOCATION =\n (SOURCE =\n (METHOD = FILE)\n (METHOD_DATA =\n (DIRECTORY = /u01/app/oracle/product/12.1.0/dbhome_1/owm/wallets)\n )\n )\n\n SSL_CIPHER_SUITES= (SSL_RSA_WITH_AES_256_CBC_SHA384)\n ADR_BASE = /u01/app/oracle\n\n Note: \"SSL_VERSION = 1.2 or 1.1\" is the actual value, not a suggestion to\n use one or the other.", - "fix": "Configure DBMS, OS and/or enterprise-level authentication/access\n mechanism to require multifactor authentication for local users logging on to\n privileged accounts.\n\n If appropriate, enable support for Transport Layer Security (TLS) protocols and\n multifactor authentication through the use of Smart Cards (CAC/PIV)." + "check": "Review the System Security Plan for remote applications that\n access and use the database.\n\n For each remote application or application server, determine whether\n communications between it and the DBMS are encrypted. If any are not encrypted,\n this is a finding.", + "fix": "Configure communications between the DBMS and remote\n applications/application servers to use DoD-approved encryption." }, - "code": " control 'V-61707' do\n impact 0.0\n describe 'This control is not applicable on oracle within aws rds, as aws manages the operating system in which the oracle database is running on' do\n skip 'This control is not applicable on oracle within aws rds, as aws manages the operating system in which the oracle database is running on'\n end\n end\n", + "code": " control 'V-61447' do\n impact 0.0\n describe 'This control is not applicable on oracle within aws rds, as aws manages the operating system in which the oracle database is running on' do\n skip 'This control is not applicable on oracle within aws rds, as aws manages the operating system in which the oracle database is running on'\n end\n end\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61707.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61447.rb", "line": 1 }, - "id": "V-61707" + "id": "V-61447" }, { - "title": "The DBMS must be protected from unauthorized access by developers.", - "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 production databases can affect the operation and/or security of the database\n system. Operating system and database privileges assigned to developers on\n production systems must not be allowed.", + "title": "The system must protect audit information from any type of\n unauthorized access.", + "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 difficult, if not impossible, to achieve. In addition, access to\n audit records provides information an attacker could potentially use to his or\n her advantage.\n\n To ensure the veracity of audit data, the information system and/or the\n application must protect audit information from any and all unauthorized\n access. This includes read, write, copy, etc.\n\n This requirement can be achieved through multiple methods which will depend\n upon system architecture and design. Some commonly employed methods include\n ensuring log files enjoy the proper file system permissions utilizing file\n system protections and limiting log data location.\n\n Additionally, applications with user interfaces to audit records must not\n allow for the unfettered manipulation of or access to those records via the\n application. If the application provides access to the audit data, the\n application becomes accountable for ensuring that audit information is\n protected from unauthorized access.\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.", "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 production databases can affect the operation and/or security of the database\n system. Operating system and database privileges assigned to developers on\n production systems must not be allowed." + "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 difficult, if not impossible, to achieve. In addition, access to\n audit records provides information an attacker could potentially use to his or\n her advantage.\n\n To ensure the veracity of audit data, the information system and/or the\n application must protect audit information from any and all unauthorized\n access. This includes read, write, copy, etc.\n\n This requirement can be achieved through multiple methods which will depend\n upon system architecture and design. Some commonly employed methods include\n ensuring log files enjoy the proper file system permissions utilizing file\n system protections and limiting log data location.\n\n Additionally, applications with user interfaces to audit records must not\n allow for the unfettered manipulation of or access to those records via the\n application. If the application provides access to the audit data, the\n application becomes accountable for ensuring that audit information is\n protected from unauthorized access.\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." }, - "impact": 0.5, + "impact": 0, "refs": [], "tags": { - "gtitle": "SRG-APP-000062-DB-000014", - "gid": "V-61585", - "rid": "SV-76075r1_rule", - "stig_id": "O121-C2-003700", - "fix_id": "F-67501r1_fix", + "gtitle": "SRG-APP-000118-DB-000059", + "gid": "V-61653", + "rid": "SV-76143r2_rule", + "stig_id": "O121-C2-009300", + "fix_id": "F-67567r3_fix", "cci": [ - "CCI-000366", - "CCI-002220" + "CCI-000162" ], "nist": [ - "AC-5 c", + "AU-9", "Rev_4" ], "false_negatives": null, @@ -1574,35 +1618,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Check the production system to ensure no developer accounts\n have rights to modify the production database structure or alter production\n data.\n\n If developer accounts with these rights exist, ask for documentation that shows\n these accounts have formal approval and risk acceptance. If this documentation\n does not exist, 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.", - "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": "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 access.\n\n If appropriate controls and permissions do not exist, this is a finding.\n\n - - - - -\n If Standard Auditing is used:\n DBA_TAB_PRIVS describes all object grants in the database. Check to see who\n has permissions on the AUD$ table.\n\n Related View\n\n DBA_TAB_PRIVS describes the object grants for which the current user is the\n object owner, grantor, or grantee.\n Column Datatype NULL Description\n GRANTEE VARCHAR2(30) NOT NULL Name of the user to whom access was granted\n 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 with the\n GRANT OPTION (YES) or not (NO)\n HIERARCHY VARCHAR2(3) Indicates whether the privilege was granted with the\n HIERARCHY OPTION (YES) or not (NO)\n COMMON VARCHAR2(3)\n TYPE VARCHAR2(24)\n\n sqlplus connect as sysdba;\n\n SQL> SELECT GRANTEE, TABLE_NAME, PRIVILEGE\n FROM DBA_TAB_PRIVS where table_name = 'AUD$';\n\n If Unified Auditing is used:\n DBA_TAB_PRIVS describes all object grants in the database. Check to see who\n has permissions on the AUDSYS tables.\n\n Related View\n\n DBA_TAB_PRIVS describes the object grants for which the current user is the\n object owner, grantor, or grantee.\n Column Datatype NULL Description\n GRANTEE VARCHAR2(30) NOT NULL Name of the user to whom access was\n 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 with\n the GRANT OPTION (YES) or not (NO)\n HIERARCHY VARCHAR2(3) Indicates whether the privilege was granted with\n 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 access, whether stored in the database itself or at the\n OS level." }, - "code": "control 'V-61585' do\n title 'The DBMS must be protected from unauthorized access by developers.'\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 production databases can affect the operation and/or security of the database\n system. Operating system and database privileges assigned to developers on\n production systems must not be allowed.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000062-DB-000014'\n tag \"gid\": 'V-61585'\n tag \"rid\": 'SV-76075r1_rule'\n tag \"stig_id\": 'O121-C2-003700'\n tag \"fix_id\": 'F-67501r1_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\": \"Check the production system to ensure no developer accounts\n have rights to modify the production database structure or alter production\n data.\n\n If developer accounts with these rights exist, ask for documentation that shows\n these accounts have formal approval and risk acceptance. If this documentation\n does not exist, 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 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' do\n skip 'A manual review is required to ensure the DBMS is protected from unauthorized access by developers'\n end\nend\n", + "code": "control 'V-61653' do\n title \"The system must protect audit information from any type of\n unauthorized access.\"\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 difficult, if not impossible, to achieve. In addition, access to\n audit records provides information an attacker could potentially use to his or\n her advantage.\n\n To ensure the veracity of audit data, the information system and/or the\n application must protect audit information from any and all unauthorized\n access. This includes read, write, copy, etc.\n\n This requirement can be achieved through multiple methods which will depend\n upon system architecture and design. Some commonly employed methods include\n ensuring log files enjoy the proper file system permissions utilizing file\n system protections and limiting log data location.\n\n Additionally, applications with user interfaces to audit records must not\n allow for the unfettered manipulation of or access to those records via the\n application. If the application provides access to the audit data, the\n application becomes accountable for ensuring that audit information is\n protected from unauthorized access.\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 impact 0.5\n tag \"gtitle\": 'SRG-APP-000118-DB-000059'\n tag \"gid\": 'V-61653'\n tag \"rid\": 'SV-76143r2_rule'\n tag \"stig_id\": 'O121-C2-009300'\n tag \"fix_id\": 'F-67567r3_fix'\n tag \"cci\": ['CCI-000162']\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 access.\n\n If appropriate controls and permissions do not exist, this is a finding.\n\n - - - - -\n If Standard Auditing is used:\n DBA_TAB_PRIVS describes all object grants in the database. Check to see who\n has permissions on the AUD$ table.\n\n Related View\n\n DBA_TAB_PRIVS describes the object grants for which the current user is the\n object owner, grantor, or grantee.\n Column Datatype NULL Description\n GRANTEE VARCHAR2(30) NOT NULL Name of the user to whom access was granted\n 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 with the\n GRANT OPTION (YES) or not (NO)\n HIERARCHY VARCHAR2(3) Indicates whether the privilege was granted with the\n HIERARCHY OPTION (YES) or not (NO)\n COMMON VARCHAR2(3)\n TYPE VARCHAR2(24)\n\n sqlplus connect as sysdba;\n\n SQL> SELECT GRANTEE, TABLE_NAME, PRIVILEGE\n FROM DBA_TAB_PRIVS where table_name = 'AUD$';\n\n If Unified Auditing is used:\n DBA_TAB_PRIVS describes all object grants in the database. Check to see who\n has permissions on the AUDSYS tables.\n\n Related View\n\n DBA_TAB_PRIVS describes the object grants for which the current user is the\n object owner, grantor, or grantee.\n Column Datatype NULL Description\n GRANTEE VARCHAR2(30) NOT NULL Name of the user to whom access was\n 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 with\n the GRANT OPTION (YES) or not (NO)\n HIERARCHY VARCHAR2(3) Indicates whether the privilege was granted with\n 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 access, whether stored in the database itself or at the\n OS level.\"\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-61585.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61653.rb", "line": 1 }, - "id": "V-61585" + "id": "V-61653" }, { - "title": "The DBA role must not be assigned excessive or unauthorized\n privileges.", - "desc": "This requirement is intended to limit exposure due to operating from\n within a privileged account or role. The inclusion of role is intended to\n address those situations where an access control policy, such as Role Based\n Access Control (RBAC), is being implemented and where a change of role provides\n the same degree of assurance in the change of access authorizations for both\n the user and all processes acting on behalf of the user as would be provided by\n a change between a privileged and non-privileged account.\n\n Audit of privileged activity may require physical separation employing\n information systems on which the user does not have privileged access.\n\n To limit exposure and provide forensic history of activity when operating\n from within a privileged account or role, the application must support\n organizational requirements that users of information system accounts, or\n roles, with access to organization-defined lists of security functions or\n security-relevant information, use non-privileged accounts, or roles, when\n accessing other (non-security) system functions.\n\n If feasible, applications must provide access logging that ensures users\n who are granted a privileged role (or roles) have their privileged activity\n logged.\n\n DBAs, if assigned excessive privileges, could perform actions that endanger\n the information system or hide evidence of malicious activity.", + "title": "Use of external executables must be authorized.", + "desc": "Information systems are capable of providing a wide variety of\n functions and services. Some of the functions and services, provided by\n default, may not be necessary to support essential organizational operations\n (e.g., key missions, functions).\n\n It is detrimental for applications to provide, or install by default,\n functionality exceeding requirements or mission objectives. Examples include,\n but are not limited to, installing advertising software, demonstrations, or\n browser plugins not related to requirements or providing a wide array of\n functionality not required for the mission.\n\n Applications must adhere to the principles of least functionality by\n providing only essential capabilities.\n\n DBMS's may spawn additional external processes to execute procedures that\n are defined in the DBMS, but stored in external host files (external\n procedures). The spawned process used to execute the external procedure may\n operate within a different OS security context than the DBMS and provide\n unauthorized access to the host system.", "descriptions": { - "default": "This requirement is intended to limit exposure due to operating from\n within a privileged account or role. The inclusion of role is intended to\n address those situations where an access control policy, such as Role Based\n Access Control (RBAC), is being implemented and where a change of role provides\n the same degree of assurance in the change of access authorizations for both\n the user and all processes acting on behalf of the user as would be provided by\n a change between a privileged and non-privileged account.\n\n Audit of privileged activity may require physical separation employing\n information systems on which the user does not have privileged access.\n\n To limit exposure and provide forensic history of activity when operating\n from within a privileged account or role, the application must support\n organizational requirements that users of information system accounts, or\n roles, with access to organization-defined lists of security functions or\n security-relevant information, use non-privileged accounts, or roles, when\n accessing other (non-security) system functions.\n\n If feasible, applications must provide access logging that ensures users\n who are granted a privileged role (or roles) have their privileged activity\n logged.\n\n DBAs, if assigned excessive privileges, could perform actions that endanger\n the information system or hide evidence of malicious activity." + "default": "Information systems are capable of providing a wide variety of\n functions and services. Some of the functions and services, provided by\n default, may not be necessary to support essential organizational operations\n (e.g., key missions, functions).\n\n It is detrimental for applications to provide, or install by default,\n functionality exceeding requirements or mission objectives. Examples include,\n but are not limited to, installing advertising software, demonstrations, or\n browser plugins not related to requirements or providing a wide array of\n functionality not required for the mission.\n\n Applications must adhere to the principles of least functionality by\n providing only essential capabilities.\n\n DBMS's may spawn additional external processes to execute procedures that\n are defined in the DBMS, but stored in external host files (external\n procedures). The spawned process used to execute the external procedure may\n operate within a different OS security context than the DBMS and provide\n unauthorized access to the host system." }, "impact": 0, "refs": [], "tags": { - "gtitle": "SRG-APP-000063-DB-000019", - "gid": "V-61599", - "rid": "SV-76089r2_rule", - "stig_id": "O121-C2-004300", - "fix_id": "F-67515r1_fix", + "gtitle": "SRG-APP-000141-DB-000093", + "gid": "V-61683", + "rid": "SV-76173r1_rule", + "stig_id": "O121-C2-011800", + "fix_id": "F-67597r1_fix", "cci": [ - "CCI-000366" + "CCI-000381" ], "nist": [ - "CM-6 b", + "CM-7 a", "Rev_4" ], "false_negatives": null, @@ -1615,35 +1659,39 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Review access permissions for objects owned by application\n owners or other non-administrative users.\n\n If DBA or administrative accounts have unauthorized application roles or\n permissions beyond those needed for administration, this is a finding.\n\n To obtain a list of privileges assigned to the DBMS user accounts, run the\n query:\n SELECT * from dba_sys_privs where grantee='DBA' order by privilege;\n\n To check to see what roles are assigned to a user, run the query:\n SELECT * from dba_role_privs where grantee = '';\n\n To check to see what privileges are assigned to a role, run the query:\n SELECT * from role_sys_privs;\n\n To show privileges by object, run the query:\n SELECT table_name, grantee,\n MAX(DECODE(privilege, 'SELECT', 'SELECT')) AS select_priv,\n MAX(DECODE(privilege, 'DELETE', 'DELETE')) AS delete_priv,\n MAX(DECODE(privilege, 'UPDATE', 'UPDATE')) AS update_priv,\n MAX(DECODE(privilege, 'INSERT', 'INSERT')) AS insert_priv\n FROM dba_tab_privs\n WHERE grantee IN (SELECT role FROM dba_roles)\n GROUP BY table_name, grantee\n ORDER BY table_name, grantee;\n\n This query will list the system privileges assigned to a specific user:\n SELECT LPAD(' ', 2*level) || granted_role \"USER PRIVS\"\n FROM\n (\n SELECT NULL grantee, username granted_role\n FROM dba_users\n WHERE username LIKE UPPER('%&uname%')\n UNION\n SELECT grantee, granted_role\n FROM dba_role_privs\n UNION\n SELECT grantee, privilege\n FROM dba_sys_privs\n )\n START WITH grantee IS NULL\n CONNECT BY grantee = prior granted_role;\n\n To list all administrative privileges granted to users via roles, run the query:\n SELECT\n username,\n rp.granted_role,\n privilege\n FROM\n dba_users u,\n dba_role_privs rp,\n dba_sys_privs sp\n WHERE username = rp.grantee\n AND rp.granted_role = sp.grantee\n AND privilege NOT IN\n (\n 'CREATE SEQUENCE', 'CREATE TRIGGER',\n 'SET CONTAINER', 'CREATE CLUSTER',\n 'CREATE PROCEDURE', 'CREATE TYPE',\n 'CREATE SESSION', 'CREATE OPERATOR',\n 'CREATE TABLE', 'CREATE INDEXTYPE'\n )\n AND username NOT IN\n (\n 'XDB', 'SYSTEM', 'SYS', 'LBACSYS',\n 'DVSYS', 'DVF', 'SYSMAN_RO', 'SYSMAN_BIPLATFORM',\n 'SYSMAN_MDS', 'SYSMAN_OPSS', 'SYSMAN_STB', 'DBSNMP',\n 'SYSMAN', 'APEX_040200', 'WMSYS', 'SYSDG',\n 'SYSBACKUP', 'SPATIAL_WFS_ADMIN_USR',\n 'SPATIAL_CSW_ADMIN_US','GSMCATUSER',\n 'OLAPSYS', 'SI_INFORMTN_SCHEMA', 'OUTLN', 'ORDSYS',\n 'ORDDATA', 'OJVMSYS', 'ORACLE_OCM', 'MDSYS',\n 'ORDPLUGINS', 'GSMADMIN_INTERNAL', 'MDDATA',\n 'FLOWS_FILES', 'DIP', 'CTXSYS', 'AUDSYS', 'APPQOSSYS',\n 'APEX_PUBLIC_USER', 'ANONYMOUS',\n 'SPATIAL_CSW_ADMIN_USR', 'SYSKM',\n 'SYSMAN_TYPES', 'MGMT_VIEW', 'EUS_ENGINE_USER',\n 'EXFSYS', 'SYSMAN_APM','IX','OWBSYS'\n )\n ORDER by 1, 2, 3;\n\n (The list of special accounts that are excluded from this requirement may not\n be complete. It is expected that the DBA will edit the list to suit local\n circumstances, adding other special accounts as necessary, and removing any\n that are not supposed to be in use in the Oracle deployment that is under\n review. Similarly, the list of privileges excluded from the list may be\n modified according to circumstances.)\n\n Data Dictionary Objects Related To System Privileges:\n all_sys_privs\n session_privs\n user_sys_privs\n dba_sys_privs\n system_privilege_map", - "fix": "Remove permissions from DBAs and other administrative users\n beyond those required for administrative functions." + "check": "Review the database for definitions of application executable\n objects stored external to the database.\n\n Determine if there are methods to disable use or access, or to remove\n definitions for external executable objects.\n\n Verify any application executable objects listed are authorized by the ISSO.\n\n If any are not, this is a finding.\n\n - - - - -\n To check for external procedures, execute the following query which will\n provide the libraries containing external procedures, the owners of those\n libraries, users that have been granted access to those libraries, and the\n privileges they have been granted. If there are owners other than the owners\n that Oracle provides, then there may be executable objects stored either in the\n database or external to the database that are called by objects in the\n database. Check to see that those owners are authorized to access those\n libraries. If there are users that have been granted access to libraries\n provided by Oracle, check to see that they are authorized to access those\n libraries.\n\n (connect as sysdba)\n set linesize 130\n column library_name format a25\n column name format a15\n column owner format a15\n column grantee format a15\n column privilege format a15\n select library_name,owner, '' grantee, '' privilege\n from dba_libraries where file_spec is not null\n minus\n (\n select library_name,o.name owner, '' grantee, '' privilege\n from dba_libraries l,\n sys.user$ o,\n sys.user$ ge,\n sys.obj$ obj,\n sys.objauth$ oa\n where l.owner=o.name\n and obj.owner#=o.user#\n and obj.name=l.library_name\n and oa.obj#=obj.obj#\n and ge.user#=oa.grantee#\n and l.file_spec is not null\n )\n union all\n select library_name,o.name owner, --obj.obj#,oa.privilege#,\n ge.name grantee,\n tpm.name privilege\n from dba_libraries l,\n sys.user$ o,\n sys.user$ ge,\n sys.obj$ obj,\n sys.objauth$ oa,\n sys.table_privilege_map tpm\n where l.owner=o.name\n and obj.owner#=o.user#\n and obj.name=l.library_name\n and oa.obj#=obj.obj#\n and ge.user#=oa.grantee#\n and tpm.privilege=oa.privilege#\n and l.file_spec is not null;\n /", + "fix": "Disable use of or remove any external application executable\n object definitions that are not authorized.\n\n Revoke privileges granted to users that are not authorized access to external\n applications." }, - "code": "control 'V-61599' do\n title \"The DBA role must not be assigned excessive or unauthorized\n privileges.\"\n desc \"This requirement is intended to limit exposure due to operating from\n within a privileged account or role. The inclusion of role is intended to\n address those situations where an access control policy, such as Role Based\n Access Control (RBAC), is being implemented and where a change of role provides\n the same degree of assurance in the change of access authorizations for both\n the user and all processes acting on behalf of the user as would be provided by\n a change between a privileged and non-privileged account.\n\n Audit of privileged activity may require physical separation employing\n information systems on which the user does not have privileged access.\n\n To limit exposure and provide forensic history of activity when operating\n from within a privileged account or role, the application must support\n organizational requirements that users of information system accounts, or\n roles, with access to organization-defined lists of security functions or\n security-relevant information, use non-privileged accounts, or roles, when\n accessing other (non-security) system functions.\n\n If feasible, applications must provide access logging that ensures users\n who are granted a privileged role (or roles) have their privileged activity\n logged.\n\n DBAs, if assigned excessive privileges, could perform actions that endanger\n the information system or hide evidence of malicious activity.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000063-DB-000019'\n tag \"gid\": 'V-61599'\n tag \"rid\": 'SV-76089r2_rule'\n tag \"stig_id\": 'O121-C2-004300'\n tag \"fix_id\": 'F-67515r1_fix'\n tag \"cci\": ['CCI-000366']\n tag \"nist\": ['CM-6 b', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Review access permissions for objects owned by application\n owners or other non-administrative users.\n\n If DBA or administrative accounts have unauthorized application roles or\n permissions beyond those needed for administration, this is a finding.\n\n To obtain a list of privileges assigned to the DBMS user accounts, run the\n query:\n SELECT * from dba_sys_privs where grantee='DBA' order by privilege;\n\n To check to see what roles are assigned to a user, run the query:\n SELECT * from dba_role_privs where grantee = '';\n\n To check to see what privileges are assigned to a role, run the query:\n SELECT * from role_sys_privs;\n\n To show privileges by object, run the query:\n SELECT table_name, grantee,\n MAX(DECODE(privilege, 'SELECT', 'SELECT')) AS select_priv,\n MAX(DECODE(privilege, 'DELETE', 'DELETE')) AS delete_priv,\n MAX(DECODE(privilege, 'UPDATE', 'UPDATE')) AS update_priv,\n MAX(DECODE(privilege, 'INSERT', 'INSERT')) AS insert_priv\n FROM dba_tab_privs\n WHERE grantee IN (SELECT role FROM dba_roles)\n GROUP BY table_name, grantee\n ORDER BY table_name, grantee;\n\n This query will list the system privileges assigned to a specific user:\n SELECT LPAD(' ', 2*level) || granted_role \\\"USER PRIVS\\\"\n FROM\n (\n SELECT NULL grantee, username granted_role\n FROM dba_users\n WHERE username LIKE UPPER('%&uname%')\n UNION\n SELECT grantee, granted_role\n FROM dba_role_privs\n UNION\n SELECT grantee, privilege\n FROM dba_sys_privs\n )\n START WITH grantee IS NULL\n CONNECT BY grantee = prior granted_role;\n\n To list all administrative privileges granted to users via roles, run the query:\n SELECT\n username,\n rp.granted_role,\n privilege\n FROM\n dba_users u,\n dba_role_privs rp,\n dba_sys_privs sp\n WHERE username = rp.grantee\n AND rp.granted_role = sp.grantee\n AND privilege NOT IN\n (\n 'CREATE SEQUENCE', 'CREATE TRIGGER',\n 'SET CONTAINER', 'CREATE CLUSTER',\n 'CREATE PROCEDURE', 'CREATE TYPE',\n 'CREATE SESSION', 'CREATE OPERATOR',\n 'CREATE TABLE', 'CREATE INDEXTYPE'\n )\n AND username NOT IN\n (\n 'XDB', 'SYSTEM', 'SYS', 'LBACSYS',\n 'DVSYS', 'DVF', 'SYSMAN_RO', 'SYSMAN_BIPLATFORM',\n 'SYSMAN_MDS', 'SYSMAN_OPSS', 'SYSMAN_STB', 'DBSNMP',\n 'SYSMAN', 'APEX_040200', 'WMSYS', 'SYSDG',\n 'SYSBACKUP', 'SPATIAL_WFS_ADMIN_USR',\n 'SPATIAL_CSW_ADMIN_US','GSMCATUSER',\n 'OLAPSYS', 'SI_INFORMTN_SCHEMA', 'OUTLN', 'ORDSYS',\n 'ORDDATA', 'OJVMSYS', 'ORACLE_OCM', 'MDSYS',\n 'ORDPLUGINS', 'GSMADMIN_INTERNAL', 'MDDATA',\n 'FLOWS_FILES', 'DIP', 'CTXSYS', 'AUDSYS', 'APPQOSSYS',\n 'APEX_PUBLIC_USER', 'ANONYMOUS',\n 'SPATIAL_CSW_ADMIN_USR', 'SYSKM',\n 'SYSMAN_TYPES', 'MGMT_VIEW', 'EUS_ENGINE_USER',\n 'EXFSYS', 'SYSMAN_APM','IX','OWBSYS'\n )\n ORDER by 1, 2, 3;\n\n (The list of special accounts that are excluded from this requirement may not\n be complete. It is expected that the DBA will edit the list to suit local\n circumstances, adding other special accounts as necessary, and removing any\n that are not supposed to be in use in the Oracle deployment that is under\n review. Similarly, the list of privileges excluded from the list may be\n modified according to circumstances.)\n\n Data Dictionary Objects Related To System Privileges:\n all_sys_privs\n session_privs\n user_sys_privs\n dba_sys_privs\n system_privilege_map\"\n tag \"fix\": \"Remove permissions from DBAs and other administrative users\n beyond those required for administrative functions.\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n users_with_admin_privs = sql.query(\"SELECT\n username,\n rp.granted_role,\n privilege\n FROM\n dba_users u,\n dba_role_privs rp,\n dba_sys_privs sp\n WHERE username = rp.grantee\n AND rp.granted_role = sp.grantee\n AND privilege NOT IN\n (\n 'CREATE SEQUENCE', 'CREATE TRIGGER',\n 'SET CONTAINER', 'CREATE CLUSTER',\n 'CREATE PROCEDURE', 'CREATE TYPE',\n 'CREATE SESSION', 'CREATE OPERATOR',\n 'CREATE TABLE', 'CREATE INDEXTYPE'\n )\n AND username NOT IN\n (\n 'XDB', 'SYSTEM', 'SYS', 'LBACSYS',\n 'DVSYS', 'DVF', 'SYSMAN_RO', 'SYSMAN_BIPLATFORM',\n 'SYSMAN_MDS', 'SYSMAN_OPSS', 'SYSMAN_STB', 'DBSNMP',\n 'SYSMAN', 'APEX_040200', 'WMSYS', 'SYSDG',\n 'SYSBACKUP', 'SPATIAL_WFS_ADMIN_USR',\n 'SPATIAL_CSW_ADMIN_US','GSMCATUSER',\n 'OLAPSYS', 'SI_INFORMTN_SCHEMA', 'OUTLN', 'ORDSYS',\n 'ORDDATA', 'OJVMSYS', 'ORACLE_OCM', 'MDSYS',\n 'ORDPLUGINS', 'GSMADMIN_INTERNAL', 'MDDATA',\n 'FLOWS_FILES', 'DIP', 'CTXSYS', 'AUDSYS', 'APPQOSSYS',\n 'APEX_PUBLIC_USER', 'ANONYMOUS',\n 'SPATIAL_CSW_ADMIN_USR', 'SYSKM',\n 'SYSMAN_TYPES', 'MGMT_VIEW', 'EUS_ENGINE_USER',\n 'EXFSYS', 'SYSMAN_APM','IX','OWBSYS'\n )\n ORDER by 1, 2, 3;\").column('username').uniq\n if users_with_admin_privs.empty?\n impact 0.0\n describe 'There are no oracle database users with administative privileges, control N/A' do\n skip 'There are no oracle database users with administative privileges, control N/A'\n end\n else\n users_with_admin_privs.each do |user|\n describe \"oracle database users: #{user} with administative privileges\" do\n subject { user }\n it { should be_in input('allowed_users_with_admin_privs')}\n end\n end\n end\nend\n", + "code": "control 'V-61683' do\n title 'Use of external executables must be authorized.'\n desc \"Information systems are capable of providing a wide variety of\n functions and services. Some of the functions and services, provided by\n default, may not be necessary to support essential organizational operations\n (e.g., key missions, functions).\n\n It is detrimental for applications to provide, or install by default,\n functionality exceeding requirements or mission objectives. Examples include,\n but are not limited to, installing advertising software, demonstrations, or\n browser plugins not related to requirements or providing a wide array of\n functionality not required for the mission.\n\n Applications must adhere to the principles of least functionality by\n providing only essential capabilities.\n\n DBMS's may spawn additional external processes to execute procedures that\n are defined in the DBMS, but stored in external host files (external\n procedures). The spawned process used to execute the external procedure may\n operate within a different OS security context than the DBMS and provide\n unauthorized access to the host system.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000141-DB-000093'\n tag \"gid\": 'V-61683'\n tag \"rid\": 'SV-76173r1_rule'\n tag \"stig_id\": 'O121-C2-011800'\n tag \"fix_id\": 'F-67597r1_fix'\n tag \"cci\": ['CCI-000381']\n tag \"nist\": ['CM-7 a', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Review the database for definitions of application executable\n objects stored external to the database.\n\n Determine if there are methods to disable use or access, or to remove\n definitions for external executable objects.\n\n Verify any application executable objects listed are authorized by the ISSO.\n\n If any are not, this is a finding.\n\n - - - - -\n To check for external procedures, execute the following query which will\n provide the libraries containing external procedures, the owners of those\n libraries, users that have been granted access to those libraries, and the\n privileges they have been granted. If there are owners other than the owners\n that Oracle provides, then there may be executable objects stored either in the\n database or external to the database that are called by objects in the\n database. Check to see that those owners are authorized to access those\n libraries. If there are users that have been granted access to libraries\n provided by Oracle, check to see that they are authorized to access those\n libraries.\n\n (connect as sysdba)\n set linesize 130\n column library_name format a25\n column name format a15\n column owner format a15\n column grantee format a15\n column privilege format a15\n select library_name,owner, '' grantee, '' privilege\n from dba_libraries where file_spec is not null\n minus\n (\n select library_name,o.name owner, '' grantee, '' privilege\n from dba_libraries l,\n sys.user$ o,\n sys.user$ ge,\n sys.obj$ obj,\n sys.objauth$ oa\n where l.owner=o.name\n and obj.owner#=o.user#\n and obj.name=l.library_name\n and oa.obj#=obj.obj#\n and ge.user#=oa.grantee#\n and l.file_spec is not null\n )\n union all\n select library_name,o.name owner, --obj.obj#,oa.privilege#,\n ge.name grantee,\n tpm.name privilege\n from dba_libraries l,\n sys.user$ o,\n sys.user$ ge,\n sys.obj$ obj,\n sys.objauth$ oa,\n sys.table_privilege_map tpm\n where l.owner=o.name\n and obj.owner#=o.user#\n and obj.name=l.library_name\n and oa.obj#=obj.obj#\n and ge.user#=oa.grantee#\n and tpm.privilege=oa.privilege#\n and l.file_spec is not null;\n /\"\n tag \"fix\": \"Disable use of or remove any external application executable\n object definitions that are not authorized.\n\n Revoke privileges granted to users that are not authorized access to external\n applications.\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n dba_users = sql.query(\"select library_name,owner, '' grantee, '' privilege\n from dba_libraries where file_spec is not null\n minus\n (\n select library_name,o.name owner, '' grantee, '' privilege\n from dba_libraries l,\n sys.user$ o,\n sys.user$ ge,\n sys.obj$ obj,\n sys.objauth$ oa\n where l.owner=o.name\n and obj.owner#=o.user#\n and obj.name=l.library_name\n and oa.obj#=obj.obj#\n and ge.user#=oa.grantee#\n and l.file_spec is not null\n )\n union all\n select library_name,o.name owner, --obj.obj#,oa.privilege#,\n ge.name grantee,\n tpm.name privilege\n from dba_libraries l,\n sys.user$ o,\n sys.user$ ge,\n sys.obj$ obj,\n sys.objauth$ oa,\n sys.table_privilege_map tpm\n where l.owner=o.name\n and obj.owner#=o.user#\n and obj.name=l.library_name\n and oa.obj#=obj.obj#\n and ge.user#=oa.grantee#\n and tpm.privilege=oa.privilege#\n and l.file_spec is not null;\").column('owner').uniq\n if dba_users.empty?\n impact 0.0\n describe 'There are no oracle DBA users, control N/A' do\n skip 'There are no oracle DBA users, control N/A'\n end\n else\n dba_users.each do |user|\n describe \"oracle DBA users: #{user}\" do\n subject { user }\n it { should be_in input('allowed_dbadmin_users') }\n end\n end\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61599.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61683.rb", "line": 1 }, - "id": "V-61599" + "id": "V-61683" }, { - "title": "The system must alert designated organizational officials in the event\n of an audit processing failure.", - "desc": "It is critical for the appropriate personnel to be aware if a system\n is at risk of failing to process audit logs as required. Audit processing\n failures include: software/hardware errors, failures in the audit capturing\n mechanisms, and audit storage capacity being reached or exceeded.\n\n A failure of database auditing will result in either the database\n continuing to function without auditing or in a complete halt to database\n operations. When audit processing fails, appropriate personnel must be alerted\n immediately to avoid further downtime or unaudited transactions.\n\n If Oracle Enterprise Manager is in use, the capability to issue such an\n alert is built in and configurable via the console so an alert can be sent to a\n designated administrator.", + "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.", "descriptions": { - "default": "It is critical for the appropriate personnel to be aware if a system\n is at risk of failing to process audit logs as required. Audit processing\n failures include: software/hardware errors, failures in the audit capturing\n mechanisms, and audit storage capacity being reached or exceeded.\n\n A failure of database auditing will result in either the database\n continuing to function without auditing or in a complete halt to database\n operations. When audit processing fails, appropriate personnel must be alerted\n immediately to avoid further downtime or unaudited transactions.\n\n If Oracle Enterprise Manager is in use, the capability to issue such an\n alert is built in and configurable via the console so an alert can be sent to a\n designated administrator." + "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." }, "impact": 0.5, - "refs": [], + "refs": [ + { + "ref": [] + } + ], "tags": { - "gtitle": "SRG-APP-000108-DB-000048", - "gid": "V-61647", - "rid": "SV-76137r2_rule", - "stig_id": "O121-C2-008500", - "fix_id": "F-67561r3_fix", + "gtitle": "SRG-APP-000065-DB-000025", + "gid": "V-61605", + "rid": "SV-76095r2_rule", + "stig_id": "O121-C2-005000", + "fix_id": "F-67521r3_fix", "cci": [ - "CCI-000139" + "CCI-000044" ], "nist": [ - "AU-5 a", + "AC-7 a", "Rev_4" ], "false_negatives": null, @@ -1656,39 +1704,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Review OS or third-party logging application settings to\n determine whether an alert will be sent to the designated organizational\n personnel when auditing fails for any reason.\n\n If no alert will be sent, this is a finding.", - "fix": "Modify OS or third-party logging application settings to alert\n designated organizational personnel when auditing fails for any reason.\n\n If Oracle Enterprise Manager is in use, the capability to issue such an alert\n is built in and configurable via the console so an alert can be sent to a\n designated administrator." + "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.)" }, - "code": "control 'V-61647' do\n title \"The system must alert designated organizational officials in the event\n of an audit processing failure.\"\n desc \"It is critical for the appropriate personnel to be aware if a system\n is at risk of failing to process audit logs as required. Audit processing\n failures include: software/hardware errors, failures in the audit capturing\n mechanisms, and audit storage capacity being reached or exceeded.\n\n A failure of database auditing will result in either the database\n continuing to function without auditing or in a complete halt to database\n operations. When audit processing fails, appropriate personnel must be alerted\n immediately to avoid further downtime or unaudited transactions.\n\n If Oracle Enterprise Manager is in use, the capability to issue such an\n alert is built in and configurable via the console so an alert can be sent to a\n designated administrator.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000108-DB-000048'\n tag \"gid\": 'V-61647'\n tag \"rid\": 'SV-76137r2_rule'\n tag \"stig_id\": 'O121-C2-008500'\n tag \"fix_id\": 'F-67561r3_fix'\n tag \"cci\": ['CCI-000139']\n tag \"nist\": ['AU-5 a', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Review OS or third-party logging application settings to\n determine whether an alert will be sent to the designated organizational\n personnel when auditing fails for any reason.\n\n If no alert will be sent, this is a finding.\"\n tag \"fix\": \"Modify OS or third-party logging application settings to alert\n designated organizational personnel when auditing fails for any reason.\n\n If Oracle Enterprise Manager is in use, the capability to issue such an alert\n is built in and configurable via the console so an alert can be sent to a\n designated administrator.\"\n describe 'A manual review is required to ensure the system alerts designated organizational officials in the event\n of an audit processing failure' do\n skip 'A manual review is required to ensure the system alerts designated organizational officials in the event\n of an audit processing failure'\n end\nend\n", + "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", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61647.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61605.rb", "line": 1 }, - "id": "V-61647" + "id": "V-61605" }, { - "title": "The DBMS must implement required cryptographic protections using\n cryptographic modules complying with applicable federal laws, Executive Orders,\n directives, policies, regulations, standards, and guidance.", - "desc": "Use of cryptography to provide confidentiality and non-repudiation is\n not effective unless strong methods are employed. Many earlier encryption\n methods and modules have been broken and/or overtaken by increasing computing\n power. The NIST FIPS 140-2 cryptographic standards provide proven methods and\n strengths to employ cryptography effectively.\n\n Detailed information on the NIST Cryptographic Module Validation Program\n (CMVP) is available at http://csrc.nist.gov/groups/STM/cmvp/index.html\n\n Note: this does not require that all databases be encrypted. It specifies\n that if encryption is required, then the implementation of the encryption must\n satisfy the prevailing standards.", + "title": "The DBMS must preserve any organization-defined system state\n information in the event of a system failure.", + "desc": "Failure in a known state can address safety or security in accordance\n with the mission/business needs of the organization. Failure in a known secure\n state helps prevent a loss of confidentiality, integrity, or availability in\n the event of a failure of the information system or a component of the system.\n\n Preserving information system state information helps to facilitate system\n restart and return to the operational mode of the organization with less\n disruption of mission/business processes.", "descriptions": { - "default": "Use of cryptography to provide confidentiality and non-repudiation is\n not effective unless strong methods are employed. Many earlier encryption\n methods and modules have been broken and/or overtaken by increasing computing\n power. The NIST FIPS 140-2 cryptographic standards provide proven methods and\n strengths to employ cryptography effectively.\n\n Detailed information on the NIST Cryptographic Module Validation Program\n (CMVP) is available at http://csrc.nist.gov/groups/STM/cmvp/index.html\n\n Note: this does not require that all databases be encrypted. It specifies\n that if encryption is required, then the implementation of the encryption must\n satisfy the prevailing standards." + "default": "Failure in a known state can address safety or security in accordance\n with the mission/business needs of the organization. Failure in a known secure\n state helps prevent a loss of confidentiality, integrity, or availability in\n the event of a failure of the information system or a component of the system.\n\n Preserving information system state information helps to facilitate system\n restart and return to the operational mode of the organization with less\n disruption of mission/business processes." }, - "impact": 0, - "refs": [ - { - "ref": [] - } - ], + "impact": 0.5, + "refs": [], "tags": { - "gtitle": "SRG-APP-000196-DB-000140", - "gid": "V-61759", - "rid": "SV-76249r3_rule", - "stig_id": "O121-C2-016600", - "fix_id": "F-67675r2_fix", + "gtitle": "SRG-APP-000226-DB-000147", + "gid": "V-61769", + "rid": "SV-76259r3_rule", + "stig_id": "O121-C2-018200", + "fix_id": "F-67685r5_fix", "cci": [ - "CCI-002450" + "CCI-001665" ], "nist": [ - "SC-13", + "SC-24", "Rev_4" ], "false_negatives": null, @@ -1701,39 +1745,36 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "If encryption is not required for the database, this is not a\n finding.\n\n If the DBMS has not implemented federally required cryptographic protections\n for the level of classification of the data it contains, this is a finding.\n\n Check the following settings to see if FIPS 140-2 encryption is configured. If\n encryption is not configured, check with the DBA and SYSTEM Administrator to\n see if other mechanisms or third-party products are deployed to encrypt data\n during the transmission or storage of data.\n\n For Transparent Data Encryption and DBMS_CRYPTO:\n\n To see if Oracle is configured for FIPS 140-2 Transparent Data Encryption\n and/or DBMS_CRYPTO, enter the following SQL*Plus command:\n SHOW PARAMETER DBFIPS_140\n or the following SQL query:\n SELECT * FROM SYS.V$PARAMETER WHERE NAME = 'DBFIPS_140';\n\n If Oracle returns the value 'FALSE', or returns no rows, this is a finding.\n\n To see if Oracle is configured for FIPS 140-2 SSL/TLS authentication and/or\n Encryption:\n\n Verify the DBMS version:\n select * from V_$VERSION;\n\n If the version displayed for Oracle Database is lower than 12.1.0.2, this is a\n finding.\n\n If the operating system is Windows and the DBMS version is 12.1.0.2, use the\n opatch command to display the patches applied to the DBMS.\n\n If the patches listed do not include \"WINDOWS DB BUNDLE PATCH 12.1.0.2.7\",\n this is a finding.\n\n Open the fips.ora file in a browser or editor. (The default location for\n fips.ora is $ORACLE_HOME/ldap/admin/ but alternate locations are possible. An\n alternate location, if it is in use, is specified in the FIPS_HOME environment\n variable.)\n\n If the line \"SSLFIPS_140=TRUE\" is not found in fips.ora, or the file does not\n exist, this is a finding.\n\n For (Native) Network Data Encryption:\n If the line, SQLNET.FIPS_140=TRUE is not found in\n $ORACLE_HOME/network/admin/sqlnet.ora, this is a finding. (Note: This assumes\n that a single sqlnet.ora file, in the default location, is in use. Please see\n the supplemental file \"Non-default sqlnet.ora configurations.pdf\" for how to\n find multiple and/or differently located sqlnet.ora files.)\n\n Note: For the Solaris platform, when DBFIPS_140 is FALSE, TDE (but not\n DBMS_CRYPTO) can still operate in a FIPS 140-compliant manner if FIPS 140\n operation is enabled for the Solaris Cryptographic Framework.", - "fix": "Implement required cryptographic protections using cryptographic\n modules complying with applicable federal laws, Executive Orders, directives,\n policies, regulations, standards, and guidance.\n\n Where not already in effect, upgrade the DBMS to version 12.1.0.2 or higher.\n\n Where the operating system is Windows and the DBMS version is 12.1.0.2, install\n patch \"WINDOWS DB BUNDLE PATCH 12.1.0.2.7\" if not already deployed.\n\n Open the fips.ora file in an editor. (The default location for fips.ora is\n $ORACLE_HOME/ldap/admin/ but alternate locations are possible. An alternate\n location, if it is in use, is specified in the FIPS_HOME environment variable.)\n\n Create or modify fips.ora to include the line \"SSLFIPS_140=TRUE\".\n\n - - - - -\n The strength requirements are dependent upon data classification.\n\n For unclassified data, where cryptography is required:\n AES 128 for encryption\n SHA 256 for hashing\n\n NSA has established the suite B encryption requirements for protecting National\n Security Systems (NSS) as follows:\n AES 128 for Secret\n AES 256 for Top Secret\n SHA 256 for Secret\n SHA 384 for Top Secret\n\n National Security System is defined as:\n (OMB Circular A-130) Any telecommunications or information system operated by\n the United States Government, the function, operation, or use of which (1)\n involves intelligence activities; (2) involves cryptologic activities related\n to national security; (3) involves command and control of military forces; (4)\n involves equipment that is an integral part of a weapon or weapons system; or\n (5) is critical to the direct fulfillment of military or intelligence missions,\n but excluding any system that is to be used for routine administrative and\n business applications (including payroll, finance, logistics, and personnel\n management applications)." + "check": "If the database is used solely for transient data (such as one\n dedicated to Extract-Transform-Load (ETL)), and a clear plan exists for the\n recovery of the database by means other than archiving, this is not a finding.\n\n If it has been determined that up-to-the second recovery is not necessary and\n this fact is recorded in the system documentation, with appropriate approval,\n this is not a finding.\n\n Check DBMS settings to determine whether system state information is being\n preserved in the event of a system failure.\n\n The necessary state information is defined as \"information necessary to\n determine cause of failure and to return to operations with least disruption to\n mission/business processes\".\n\n Oracle creates what is known as archive logs. Archive logs contain information\n required to replay a transaction should something happen. The redo logs are\n also used to copy transactions or pieces of transactions.\n\n Issue the following commands to check the status of archive log mode:\n\n $ sqlplus connect as sysdba --Check current archivelog mode in database\n\n SQL> archive log list\n Database log mode Archive Mode\n Automatic archival Enabled\n Archive destination /home/oracle/app/oracle/arc2/ORCL\n Oldest online log sequence 433\n Next log sequence to archive 435\n Current log sequence 435\n\n If archive log mode is not enabled, this is a finding.", + "fix": "Configure DBMS settings to preserve all required system state\n information in the event of a system failure.\n\n If the database is not in archive log mode, issue the following commands to put\n the database in archive log mode. The database must be normally shutdown and\n restarted before it can be placed in archive log mode.\n\n $ sqlplus connect as sysdba -- stop and dismount database and shutdown instance.\n SQL> shutdown immediate;\n\n Database closed.\n Database dismounted.\n ORACLE instance shut down.\n\n SQL> startup mount; -- Restart instance.\n\n ORACLE instance started.\n Total System Global Area 1653518336 bytes\n Fixed Size 2228904 bytes\n Variable Size 1325403480 bytes\n Database Buffers 318767104 bytes\n Redo Buffers 7118848 bytes\n Database mounted.\n\n SQL> alter database archivelog; -- Enable ArchiveLog\n Database altered.\n\n SQL> alter database open; -- Re-open database\n Database altered.\n\n Issue the following command to see the new status:\n SQL> select log_mode from v$database;\n\n LOG_MODE\n ------------\n ARCHIVELOG\n\n SQL> archive log list;\n\n Database log mode Archive Mode\n Automatic archival Enabled\n Archive destination USE_DB_RECOVERY_FILE_DEST\n Oldest online log sequence 294\n Next log sequence to archive 296\n Current log sequence 296\n\n The database is now in archive log mode, and transactions are either being\n recorded to transport to another database or being re-applied if the database\n becomes corrupt and needs to be restored from the last backup. Use the redo\n logs to replay transactions not captured in the backup." }, - "code": " control 'V-61759' do\n impact 0.0\n describe 'This control is not applicable on oracle within aws rds, as aws manages the operating system in which the oracle database is running on' do\n skip 'This control is not applicable on oracle within aws rds, as aws manages the operating system in which the oracle database is running on'\n end\n end\n", + "code": "control 'V-61769' do\n title \"The DBMS must preserve any organization-defined system state\n information in the event of a system failure.\"\n desc \"Failure in a known state can address safety or security in accordance\n with the mission/business needs of the organization. Failure in a known secure\n state helps prevent a loss of confidentiality, integrity, or availability in\n the event of a failure of the information system or a component of the system.\n\n Preserving information system state information helps to facilitate system\n restart and return to the operational mode of the organization with less\n disruption of mission/business processes.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000226-DB-000147'\n tag \"gid\": 'V-61769'\n tag \"rid\": 'SV-76259r3_rule'\n tag \"stig_id\": 'O121-C2-018200'\n tag \"fix_id\": 'F-67685r5_fix'\n tag \"cci\": ['CCI-001665']\n tag \"nist\": ['SC-24', '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 is used solely for transient data (such as one\n dedicated to Extract-Transform-Load (ETL)), and a clear plan exists for the\n recovery of the database by means other than archiving, this is not a finding.\n\n If it has been determined that up-to-the second recovery is not necessary and\n this fact is recorded in the system documentation, with appropriate approval,\n this is not a finding.\n\n Check DBMS settings to determine whether system state information is being\n preserved in the event of a system failure.\n\n The necessary state information is defined as \\\"information necessary to\n determine cause of failure and to return to operations with least disruption to\n mission/business processes\\\".\n\n Oracle creates what is known as archive logs. Archive logs contain information\n required to replay a transaction should something happen. The redo logs are\n also used to copy transactions or pieces of transactions.\n\n Issue the following commands to check the status of archive log mode:\n\n $ sqlplus connect as sysdba --Check current archivelog mode in database\n\n SQL> archive log list\n Database log mode Archive Mode\n Automatic archival Enabled\n Archive destination /home/oracle/app/oracle/arc2/ORCL\n Oldest online log sequence 433\n Next log sequence to archive 435\n Current log sequence 435\n\n If archive log mode is not enabled, this is a finding.\"\n tag \"fix\": \"Configure DBMS settings to preserve all required system state\n information in the event of a system failure.\n\n If the database is not in archive log mode, issue the following commands to put\n the database in archive log mode. The database must be normally shutdown and\n restarted before it can be placed in archive log mode.\n\n $ sqlplus connect as sysdba -- stop and dismount database and shutdown instance.\n SQL> shutdown immediate;\n\n Database closed.\n Database dismounted.\n ORACLE instance shut down.\n\n SQL> startup mount; -- Restart instance.\n\n ORACLE instance started.\n Total System Global Area 1653518336 bytes\n Fixed Size 2228904 bytes\n Variable Size 1325403480 bytes\n Database Buffers 318767104 bytes\n Redo Buffers 7118848 bytes\n Database mounted.\n\n SQL> alter database archivelog; -- Enable ArchiveLog\n Database altered.\n\n SQL> alter database open; -- Re-open database\n Database altered.\n\n Issue the following command to see the new status:\n SQL> select log_mode from v$database;\n\n LOG_MODE\n ------------\n ARCHIVELOG\n\n SQL> archive log list;\n\n Database log mode Archive Mode\n Automatic archival Enabled\n Archive destination USE_DB_RECOVERY_FILE_DEST\n Oldest online log sequence 294\n Next log sequence to archive 296\n Current log sequence 296\n\n The database is now in archive log mode, and transactions are either being\n recorded to transport to another database or being re-applied if the database\n becomes corrupt and needs to be restored from the last backup. Use the redo\n logs to replay transactions not captured in the backup.\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n log_mode = sql.query('select log_mode from v$database;').column('log_mode')\n\n describe 'The list of oracle database log mode' do\n subject { log_mode }\n it { should cmp 'ARCHIVELOG' }\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61759.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61769.rb", "line": 1 }, - "id": "V-61759" + "id": "V-61769" }, { - "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.", + "title": "The DBMS must protect the audit records generated, as a result of\n remote access to privileged accounts, and the execution of privileged\n functions.", + "desc": "Protection of audit records and audit data is of critical importance.\n Care must be taken to ensure privileged users cannot circumvent audit\n protections put in place.\n\n Auditing might not be reliable when performed by an information system\n which the user being audited has privileged access to.\n\n The privileged user could inhibit auditing or directly modify audit\n records. To prevent this from occurring, privileged access shall be further\n defined between audit-related privileges and other privileges, thus limiting\n the users with audit-related privileges.\n\n Reducing the risk of audit compromises by privileged users can also be\n achieved, for example, by performing audit activity on a separate information\n system where the user in question has limited access or by using storage media\n that cannot be modified (e.g., write-once recording devices).\n\n If an attacker were to gain access to audit tools he could analyze audit\n logs for system weaknesses or weaknesses in the auditing itself. An attacker\n could also manipulate logs to hide evidence of malicious activity.", "descriptions": { - "default": "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." + "default": "Protection of audit records and audit data is of critical importance.\n Care must be taken to ensure privileged users cannot circumvent audit\n protections put in place.\n\n Auditing might not be reliable when performed by an information system\n which the user being audited has privileged access to.\n\n The privileged user could inhibit auditing or directly modify audit\n records. To prevent this from occurring, privileged access shall be further\n defined between audit-related privileges and other privileges, thus limiting\n the users with audit-related privileges.\n\n Reducing the risk of audit compromises by privileged users can also be\n achieved, for example, by performing audit activity on a separate information\n system where the user in question has limited access or by using storage media\n that cannot be modified (e.g., write-once recording devices).\n\n If an attacker were to gain access to audit tools he could analyze audit\n logs for system weaknesses or weaknesses in the auditing itself. An attacker\n could also manipulate logs to hide evidence of malicious activity." }, "impact": 0, - "refs": [ - { - "ref": [] - } - ], + "refs": [], "tags": { - "gtitle": "SRG-APP-000516-DB-999900", - "gid": "V-61493", - "rid": "SV-75983r1_rule", - "stig_id": "O121-BP-024400", - "fix_id": "F-67409r1_fix", + "gtitle": "SRG-APP-000127-DB-000172", + "gid": "V-61669", + "rid": "SV-76159r1_rule", + "stig_id": "O121-C2-010200", + "fix_id": "F-67583r1_fix", "cci": [ - "CCI-000366" + "CCI-000366", + "CCI-001351" ], "nist": [ - "CM-6 b", + "AU-9 (4)", "Rev_4" ], "false_negatives": null, @@ -1746,21 +1787,21 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "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." + "check": "If Standard Auditing is used:\n For table-based auditing (DB or DB,EXTENDED), review the DBMS permissions on\n the views and base tables holding the audit data.\n\n For file-based auditing (OS, XML, or XML,EXTENDED), review the operating\n system/file system permissions on the audit file(s).\n\n If permissions exist that enable unauthorized users to view audit data, this is\n a finding.\n\n If permissions exist that enable any user (other than an account created\n specifically to manage log space and off-load audit records to a log management\n system) to modify or delete audit records, or create spurious audit records,\n this is a finding.\n\n If Unified Auditing is used:\n AUDIT_ADMIN role. This role enables the creation of unified and fine-grained\n audit policies, use the AUDIT and NOAUDIT SQL statements, view audit data, and\n manage the audit trail administration. Grant this role only to trusted users.\n\n\n\n\n AUDIT_VIEWER role. This role enables users to view and analyze audit data. The\n kind of user who needs this role is typically an external auditor.\n\n Check to ensure the authorized users have the correct roles. If permissions\n exist that enable unauthorized users to view audit data, this is a finding.\n\n If permissions exist that enable any user (other than an account created\n specifically to manage log space and off-load audit records to a log management\n system) to modify or delete audit records, or create spurious audit records,\n this is a finding.", + "fix": "If Standard Auditing is used:\n Add controls and modify permissions to protect database audit log records from\n modification, deletion, spurious creation, or unauthorized viewing.\n\n If Unified Auditing is used:\n Grant the correct Audit roles to authorized users." }, - "code": " control 'V-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", + "code": "control 'V-61669' do\n title \"The DBMS must protect the audit records generated, as a result of\n remote access to privileged accounts, and the execution of privileged\n functions.\"\n desc \"Protection of audit records and audit data is of critical importance.\n Care must be taken to ensure privileged users cannot circumvent audit\n protections put in place.\n\n Auditing might not be reliable when performed by an information system\n which the user being audited has privileged access to.\n\n The privileged user could inhibit auditing or directly modify audit\n records. To prevent this from occurring, privileged access shall be further\n defined between audit-related privileges and other privileges, thus limiting\n the users with audit-related privileges.\n\n Reducing the risk of audit compromises by privileged users can also be\n achieved, for example, by performing audit activity on a separate information\n system where the user in question has limited access or by using storage media\n that cannot be modified (e.g., write-once recording devices).\n\n If an attacker were to gain access to audit tools he could analyze audit\n logs for system weaknesses or weaknesses in the auditing itself. An attacker\n could also manipulate logs to hide evidence of malicious activity.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000127-DB-000172'\n tag \"gid\": 'V-61669'\n tag \"rid\": 'SV-76159r1_rule'\n tag \"stig_id\": 'O121-C2-010200'\n tag \"fix_id\": 'F-67583r1_fix'\n tag \"cci\": ['CCI-000366', 'CCI-001351']\n tag \"nist\": ['CM-6 b', 'Rev_4']\n tag \"nist\": ['AU-9 (4)', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"If Standard Auditing is used:\n For table-based auditing (DB or DB,EXTENDED), review the DBMS permissions on\n the views and base tables holding the audit data.\n\n For file-based auditing (OS, XML, or XML,EXTENDED), review the operating\n system/file system permissions on the audit file(s).\n\n If permissions exist that enable unauthorized users to view audit data, this is\n a finding.\n\n If permissions exist that enable any user (other than an account created\n specifically to manage log space and off-load audit records to a log management\n system) to modify or delete audit records, or create spurious audit records,\n this is a finding.\n\n If Unified Auditing is used:\n AUDIT_ADMIN role. This role enables the creation of unified and fine-grained\n audit policies, use the AUDIT and NOAUDIT SQL statements, view audit data, and\n manage the audit trail administration. Grant this role only to trusted users.\n\n\n\n\n AUDIT_VIEWER role. This role enables users to view and analyze audit data. The\n kind of user who needs this role is typically an external auditor.\n\n Check to ensure the authorized users have the correct roles. If permissions\n exist that enable unauthorized users to view audit data, this is a finding.\n\n If permissions exist that enable any user (other than an account created\n specifically to manage log space and off-load audit records to a log management\n system) to modify or delete audit records, or create spurious audit records,\n this is a finding.\"\n tag \"fix\": \"If Standard Auditing is used:\n Add controls and modify permissions to protect database audit log records from\n modification, deletion, spurious creation, or unauthorized viewing.\n\n If Unified Auditing is used:\n Grant the correct Audit roles to authorized users.\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n users_allowed_access_to_audit_info = sql.query(\"SELECT GRANTEE, TABLE_NAME, PRIVILEGE\n FROM DBA_TAB_PRIVS where owner='AUDSYS';\").column('grantee').uniq\n if users_allowed_access_to_audit_info.empty?\n impact 0.0\n describe 'There are no oracle users allowed access to audit information, control N/A' do\n skip 'There are no oracle users allowed access to audit information'\n end\n else\n users_allowed_access_to_audit_info.each do |user|\n describe \"oracle users: #{user} allowed access to audit information\" do\n subject { user }\n it { should be_in input('allowed_audit_users') }\n end\n end\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61493.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61669.rb", "line": 1 }, - "id": "V-61493" + "id": "V-61669" }, { - "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.", + "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": "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." + "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": [ @@ -1769,16 +1810,17 @@ } ], "tags": { - "gtitle": "SRG-APP-000246-DB-000133", - "gid": "V-61815", - "rid": "SV-76305r4_rule", - "stig_id": "O121-C3-019200", - "fix_id": "F-67731r10_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-001094" + "CCI-002890", + "CCI-003123" ], "nist": [ - "SC-5 (1)", + "MA-4 (6)", "Rev_4" ], "false_negatives": null, @@ -1791,39 +1833,80 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "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." + "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-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", + "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-61815.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61749.rb", "line": 1 }, - "id": "V-61815" + "id": "V-61749" }, { - "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": "The DBMS must include organization-defined additional, more detailed\n information in the audit records for audit events identified by type, location,\n or subject.", + "desc": "Information system auditing capability is critical for accurate\n forensic analysis. Audit record content that may be necessary to satisfy the\n requirement of this control includes: timestamps, source and destination\n addresses, user/process identifiers, event descriptions, success/fail\n indications, file names involved, and access control or flow control rules\n invoked.\n\n In addition, the application must have the capability to include\n organization-defined additional, more detailed information in the audit records\n for audit events. These events may be identified by type, location, or subject.\n\n An example of detailed information the organization may require in audit\n records is full-text recording of privileged commands or the individual\n identities of shared account users.\n\n Some organizations may determine that more detailed information is required\n for specific database event types. If this information is not available, it\n could negatively impact forensic investigations into user actions or other\n malicious events.", "descriptions": { - "default": "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 system auditing capability is critical for accurate\n forensic analysis. Audit record content that may be necessary to satisfy the\n requirement of this control includes: timestamps, source and destination\n addresses, user/process identifiers, event descriptions, success/fail\n indications, file names involved, and access control or flow control rules\n invoked.\n\n In addition, the application must have the capability to include\n organization-defined additional, more detailed information in the audit records\n for audit events. These events may be identified by type, location, or subject.\n\n An example of detailed information the organization may require in audit\n records is full-text recording of privileged commands or the individual\n identities of shared account users.\n\n Some organizations may determine that more detailed information is required\n for specific database event types. If this information is not available, it\n could negatively impact forensic investigations into user actions or other\n malicious events." }, "impact": 0.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", + "cci": [ + "CCI-000135" + ], + "nist": [ + "AU-3 (1)", + "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": "Verify, using vendor and system documentation if necessary,\n that the DBMS is configured to use Oracle's auditing features, or that a\n third-party product or custom code is deployed and configured to satisfy this\n requirement.\n\n If a third-party product or custom code is used, compare its current\n configuration with the audit requirements. If any of the requirements is not\n covered by the configuration, this is a finding.\n\n The remainder of this Check is applicable specifically where Oracle auditing is\n in use.\n\n If Standard Auditing is used:\n To see if Oracle is configured to capture audit data, enter the following\n SQL*Plus command:\n\n SHOW PARAMETER AUDIT_TRAIL\n\n or the following SQL query:\n\n SELECT * FROM SYS.V$PARAMETER WHERE NAME = 'audit_trail';\n\n If Oracle returns the value \"NONE\", this is a finding.\n\n Compare the organization-defined auditable events with the Oracle documentation\n to determine whether standard auditing covers all the requirements.\n\n If it does, this is not a finding.\n\n Compare those organization-defined auditable events that are not covered by the\n standard auditing, with the existing Fine-Grained Auditing (FGA) specifications\n returned by the following query:\n\n SELECT * FROM SYS.DBA_FGA_AUDIT_TRAIL;\n\n If any such auditable event is not covered by the existing FGA specifications,\n this is a finding.\n\n If Unified Auditing is used:\n To see if Oracle is configured to capture audit data, enter the following\n SQL*Plus command:\n\n SELECT * FROM V$OPTION WHERE PARAMETER = 'Unified Auditing';\n\n If Oracle returns the value \"TRUE\", this is not a finding.\n\n Compare the organization-defined auditable events with the Oracle documentation\n to determine whether standard auditing covers all the requirements.\n\n If it does, this is not a finding.\n\n Compare those organization-defined auditable events that are not covered by the\n standard auditing, with the existing Fine-Grained Auditing (FGA) specifications\n returned by the following query:\n\n SELECT * FROM SYS.UNIFIED_AUDIT_TRAIL WHERE AUDIT_TYPE = 'FineGrainedAudit';\n\n If any such auditable event is not covered by the existing FGA specifications,\n this is a finding.", + "fix": "Either configure the DBMS's auditing to audit\n organization-defined auditable events, or, if preferred, use a third-party or\n custom tool. The tool must provide the minimum capability to audit the required\n events.\n\n If using a third-party product, proceed in accordance with the product\n documentation. If using Oracle's capabilities, proceed as follows.\n\n If Standard Auditing is used:\n Use this process to ensure auditable events are captured:\n\n ALTER SYSTEM SET AUDIT_TRAIL= SCOPE=SPFILE;\n\n Audit trail type can be \"OS\", \"DB\", \"DB,EXTENDED\", \"XML\" or\n \"XML,EXTENDED\".\n\n After executing this statement, it may be necessary to shut down and restart\n the Oracle database.\n\n If the organization-defined additional audit requirements are not covered by\n the default audit options, deploy and configure Fine-Grained Auditing. For\n details, refer to Oracle documentation at the location below.\n\n If the site-specific audit requirements are not covered by the default audit\n options, deploy and configure Fine-Grained Auditing. For details, refer to\n Oracle documentation, at the location below.\n\n If Unified Auditing is used:\n Use this process to ensure auditable events are captured:\n\n SELECT * FROM V$OPTION WHERE PARAMETER = 'Unified Auditing';\n\n If Oracle returns the value \"TRUE\", this is not a finding.\n\n Otherwise,\n Link the oracle binary with uniaud_on, and then restart the database. Oracle\n Database Upgrade Guide describes how to enable unified auditing.\n\n If the organization-defined additional audit requirements are not covered by\n the default audit options, deploy and configure Fine-Grained Auditing. For\n details, refer to Oracle documentation at the location below.\n\n If the site-specific audit requirements are not covered by the default audit\n options, deploy and configure Fine-Grained Auditing. For details, refer to\n Oracle documentation, at the location below.\n\n For more information on the configuration of auditing, refer to the following\n documents:\n \"Auditing Database Activity\" in the Oracle Database 2 Day + Security Guide:\n http://docs.oracle.com/database/121/TDPSG/tdpsg_auditing.htm#TDPSG50000\n \"Monitoring Database Activity with Auditing\" in the Oracle Database Security\n Guide:\n http://docs.oracle.com/database/121/DBSEG/part_6.htm#CCHEHCGI\n \"DBMS_AUDIT_MGMT\" in the Oracle Database PL/SQL Packages and Types Reference:\n http://docs.oracle.com/database/121/ARPLS/d_audit_mgmt.htm#ARPLS241\n Oracle Database Upgrade Guide:\n http://docs.oracle.com/database/121/UPGRD/afterup.htm#UPGRD52810" + }, + "code": "control 'V-61641' do\n title \"The DBMS must include organization-defined additional, more detailed\n information in the audit records for audit events identified by type, location,\n or subject.\"\n desc \"Information system auditing capability is critical for accurate\n forensic analysis. Audit record content that may be necessary to satisfy the\n requirement of this control includes: timestamps, source and destination\n addresses, user/process identifiers, event descriptions, success/fail\n indications, file names involved, and access control or flow control rules\n invoked.\n\n In addition, the application must have the capability to include\n organization-defined additional, more detailed information in the audit records\n for audit events. These events may be identified by type, location, or subject.\n\n An example of detailed information the organization may require in audit\n records is full-text recording of privileged commands or the individual\n identities of shared account users.\n\n Some organizations may determine that more detailed information is required\n for specific database event types. If this information is not available, it\n could negatively impact forensic investigations into user actions or other\n malicious events.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000101-DB-000044'\n tag \"gid\": 'V-61641'\n tag \"rid\": 'SV-76131r1_rule'\n tag \"stig_id\": 'O121-C2-008000'\n tag \"fix_id\": 'F-67553r2_fix'\n tag \"cci\": ['CCI-000135']\n tag \"nist\": ['AU-3 (1)', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Verify, using vendor and system documentation if necessary,\n that the DBMS is configured to use Oracle's auditing features, or that a\n third-party product or custom code is deployed and configured to satisfy this\n requirement.\n\n If a third-party product or custom code is used, compare its current\n configuration with the audit requirements. If any of the requirements is not\n covered by the configuration, this is a finding.\n\n The remainder of this Check is applicable specifically where Oracle auditing is\n in use.\n\n If Standard Auditing is used:\n To see if Oracle is configured to capture audit data, enter the following\n SQL*Plus command:\n\n SHOW PARAMETER AUDIT_TRAIL\n\n or the following SQL query:\n\n SELECT * FROM SYS.V$PARAMETER WHERE NAME = 'audit_trail';\n\n If Oracle returns the value \\\"NONE\\\", this is a finding.\n\n Compare the organization-defined auditable events with the Oracle documentation\n to determine whether standard auditing covers all the requirements.\n\n If it does, this is not a finding.\n\n Compare those organization-defined auditable events that are not covered by the\n standard auditing, with the existing Fine-Grained Auditing (FGA) specifications\n returned by the following query:\n\n SELECT * FROM SYS.DBA_FGA_AUDIT_TRAIL;\n\n If any such auditable event is not covered by the existing FGA specifications,\n this is a finding.\n\n If Unified Auditing is used:\n To see if Oracle is configured to capture audit data, enter the following\n SQL*Plus command:\n\n SELECT * FROM V$OPTION WHERE PARAMETER = 'Unified Auditing';\n\n If Oracle returns the value \\\"TRUE\\\", this is not a finding.\n\n Compare the organization-defined auditable events with the Oracle documentation\n to determine whether standard auditing covers all the requirements.\n\n If it does, this is not a finding.\n\n Compare those organization-defined auditable events that are not covered by the\n standard auditing, with the existing Fine-Grained Auditing (FGA) specifications\n returned by the following query:\n\n SELECT * FROM SYS.UNIFIED_AUDIT_TRAIL WHERE AUDIT_TYPE = 'FineGrainedAudit';\n\n If any such auditable event is not covered by the existing FGA specifications,\n this is a finding.\"\n tag \"fix\": \"Either configure the DBMS's auditing to audit\n organization-defined auditable events, or, if preferred, use a third-party or\n custom tool. The tool must provide the minimum capability to audit the required\n events.\n\n If using a third-party product, proceed in accordance with the product\n documentation. If using Oracle's capabilities, proceed as follows.\n\n If Standard Auditing is used:\n Use this process to ensure auditable events are captured:\n\n ALTER SYSTEM SET AUDIT_TRAIL= SCOPE=SPFILE;\n\n Audit trail type can be \\\"OS\\\", \\\"DB\\\", \\\"DB,EXTENDED\\\", \\\"XML\\\" or\n \\\"XML,EXTENDED\\\".\n\n After executing this statement, it may be necessary to shut down and restart\n the Oracle database.\n\n If the organization-defined additional audit requirements are not covered by\n the default audit options, deploy and configure Fine-Grained Auditing. For\n details, refer to Oracle documentation at the location below.\n\n If the site-specific audit requirements are not covered by the default audit\n options, deploy and configure Fine-Grained Auditing. For details, refer to\n Oracle documentation, at the location below.\n\n If Unified Auditing is used:\n Use this process to ensure auditable events are captured:\n\n SELECT * FROM V$OPTION WHERE PARAMETER = 'Unified Auditing';\n\n If Oracle returns the value \\\"TRUE\\\", this is not a finding.\n\n Otherwise,\n Link the oracle binary with uniaud_on, and then restart the database. Oracle\n Database Upgrade Guide describes how to enable unified auditing.\n\n If the organization-defined additional audit requirements are not covered by\n the default audit options, deploy and configure Fine-Grained Auditing. For\n details, refer to Oracle documentation at the location below.\n\n If the site-specific audit requirements are not covered by the default audit\n options, deploy and configure Fine-Grained Auditing. For details, refer to\n Oracle documentation, at the location below.\n\n For more information on the configuration of auditing, refer to the following\n documents:\n \\\"Auditing Database Activity\\\" in the Oracle Database 2 Day + Security Guide:\n http://docs.oracle.com/database/121/TDPSG/tdpsg_auditing.htm#TDPSG50000\n \\\"Monitoring Database Activity with Auditing\\\" in the Oracle Database Security\n Guide:\n http://docs.oracle.com/database/121/DBSEG/part_6.htm#CCHEHCGI\n \\\"DBMS_AUDIT_MGMT\\\" in the Oracle Database PL/SQL Packages and Types Reference:\n http://docs.oracle.com/database/121/ARPLS/d_audit_mgmt.htm#ARPLS241\n Oracle Database Upgrade Guide:\n http://docs.oracle.com/database/121/UPGRD/afterup.htm#UPGRD52810\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n standard_auditing_used = input('standard_auditing_used')\n unified_auditing_used = input('unified_auditing_used')\n\n describe.one do\n describe 'Standard auditing is in use for audit purposes' do\n subject { standard_auditing_used }\n it { should be true }\n end\n\n describe 'Unified auditing is in use for audit purposes' do\n subject { unified_auditing_used }\n it { should be true }\n end\n end\n\n audit_trail = sql.query(\"select value from v$parameter where name = 'audit_trail';\").column('value')\n audit_info_captured = sql.query('SELECT EVENT_TIMESTAMP FROM UNIFIED_AUDIT_TRAIL ORDER BY EVENT_TIMESTAMP DESC FETCH FIRST 10 ROWS ONLY;').column('event_timestamp')\n fga_audit_events = sql.query(\" SELECT * FROM SYS.UNIFIED_AUDIT_TRAIL WHERE AUDIT_TYPE = 'FineGrainedAudit';\").column('TIMESTAMP')\n\n if standard_auditing_used\n describe 'The oracle database audit_trail parameter' do\n subject { audit_trail }\n it { should_not cmp 'NONE' }\n end\n end\n\n unified_auditing = sql.query(\"SELECT value FROM V$OPTION WHERE PARAMETER = 'Unified Auditing';\").column('value')\n\n if unified_auditing_used\n describe 'The oracle database unified auditing parameter' do\n subject { unified_auditing }\n it { should_not cmp 'FALSE' }\n end\n\n describe 'The oracle database unified auditing events captured' do\n subject { audit_info_captured }\n it { should_not be_empty }\n end\n\n describe 'The oracle database fine grained auditing events captured' do\n subject { fga_audit_events }\n it { should_not be_empty }\n end\n\n end\nend\n", + "source_location": { + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61641.rb", + "line": 1 + }, + "id": "V-61641" + }, + { + "title": "The DBMS must implement required cryptographic protections using\n cryptographic modules complying with applicable federal laws, Executive Orders,\n directives, policies, regulations, standards, and guidance.", + "desc": "Use of cryptography to provide confidentiality and non-repudiation is\n not effective unless strong methods are employed. Many earlier encryption\n methods and modules have been broken and/or overtaken by increasing computing\n power. The NIST FIPS 140-2 cryptographic standards provide proven methods and\n strengths to employ cryptography effectively.\n\n Detailed information on the NIST Cryptographic Module Validation Program\n (CMVP) is available at http://csrc.nist.gov/groups/STM/cmvp/index.html\n\n Note: this does not require that all databases be encrypted. It specifies\n that if encryption is required, then the implementation of the encryption must\n satisfy the prevailing standards.", + "descriptions": { + "default": "Use of cryptography to provide confidentiality and non-repudiation is\n not effective unless strong methods are employed. Many earlier encryption\n methods and modules have been broken and/or overtaken by increasing computing\n power. The NIST FIPS 140-2 cryptographic standards provide proven methods and\n strengths to employ cryptography effectively.\n\n Detailed information on the NIST Cryptographic Module Validation Program\n (CMVP) is available at http://csrc.nist.gov/groups/STM/cmvp/index.html\n\n Note: this does not require that all databases be encrypted. It specifies\n that if encryption is required, then the implementation of the encryption must\n satisfy the prevailing standards." + }, + "impact": 0, "refs": [ { "ref": [] } ], "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-000196-DB-000140", + "gid": "V-61759", + "rid": "SV-76249r3_rule", + "stig_id": "O121-C2-016600", + "fix_id": "F-67675r2_fix", "cci": [ - "CCI-000194" + "CCI-002450" ], "nist": [ - "IA-5 (1) (a)", + "SC-13", "Rev_4" ], "false_negatives": null, @@ -1836,39 +1919,39 @@ "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": "If encryption is not required for the database, this is not a\n finding.\n\n If the DBMS has not implemented federally required cryptographic protections\n for the level of classification of the data it contains, this is a finding.\n\n Check the following settings to see if FIPS 140-2 encryption is configured. If\n encryption is not configured, check with the DBA and SYSTEM Administrator to\n see if other mechanisms or third-party products are deployed to encrypt data\n during the transmission or storage of data.\n\n For Transparent Data Encryption and DBMS_CRYPTO:\n\n To see if Oracle is configured for FIPS 140-2 Transparent Data Encryption\n and/or DBMS_CRYPTO, enter the following SQL*Plus command:\n SHOW PARAMETER DBFIPS_140\n or the following SQL query:\n SELECT * FROM SYS.V$PARAMETER WHERE NAME = 'DBFIPS_140';\n\n If Oracle returns the value 'FALSE', or returns no rows, this is a finding.\n\n To see if Oracle is configured for FIPS 140-2 SSL/TLS authentication and/or\n Encryption:\n\n Verify the DBMS version:\n select * from V_$VERSION;\n\n If the version displayed for Oracle Database is lower than 12.1.0.2, this is a\n finding.\n\n If the operating system is Windows and the DBMS version is 12.1.0.2, use the\n opatch command to display the patches applied to the DBMS.\n\n If the patches listed do not include \"WINDOWS DB BUNDLE PATCH 12.1.0.2.7\",\n this is a finding.\n\n Open the fips.ora file in a browser or editor. (The default location for\n fips.ora is $ORACLE_HOME/ldap/admin/ but alternate locations are possible. An\n alternate location, if it is in use, is specified in the FIPS_HOME environment\n variable.)\n\n If the line \"SSLFIPS_140=TRUE\" is not found in fips.ora, or the file does not\n exist, this is a finding.\n\n For (Native) Network Data Encryption:\n If the line, SQLNET.FIPS_140=TRUE is not found in\n $ORACLE_HOME/network/admin/sqlnet.ora, this is a finding. (Note: This assumes\n that a single sqlnet.ora file, in the default location, is in use. Please see\n the supplemental file \"Non-default sqlnet.ora configurations.pdf\" for how to\n find multiple and/or differently located sqlnet.ora files.)\n\n Note: For the Solaris platform, when DBFIPS_140 is FALSE, TDE (but not\n DBMS_CRYPTO) can still operate in a FIPS 140-compliant manner if FIPS 140\n operation is enabled for the Solaris Cryptographic Framework.", + "fix": "Implement required cryptographic protections using cryptographic\n modules complying with applicable federal laws, Executive Orders, directives,\n policies, regulations, standards, and guidance.\n\n Where not already in effect, upgrade the DBMS to version 12.1.0.2 or higher.\n\n Where the operating system is Windows and the DBMS version is 12.1.0.2, install\n patch \"WINDOWS DB BUNDLE PATCH 12.1.0.2.7\" if not already deployed.\n\n Open the fips.ora file in an editor. (The default location for fips.ora is\n $ORACLE_HOME/ldap/admin/ but alternate locations are possible. An alternate\n location, if it is in use, is specified in the FIPS_HOME environment variable.)\n\n Create or modify fips.ora to include the line \"SSLFIPS_140=TRUE\".\n\n - - - - -\n The strength requirements are dependent upon data classification.\n\n For unclassified data, where cryptography is required:\n AES 128 for encryption\n SHA 256 for hashing\n\n NSA has established the suite B encryption requirements for protecting National\n Security Systems (NSS) as follows:\n AES 128 for Secret\n AES 256 for Top Secret\n SHA 256 for Secret\n SHA 384 for Top Secret\n\n National Security System is defined as:\n (OMB Circular A-130) Any telecommunications or information system operated by\n the United States Government, the function, operation, or use of which (1)\n involves intelligence activities; (2) involves cryptologic activities related\n to national security; (3) involves command and control of military forces; (4)\n involves equipment that is an integral part of a weapon or weapons system; or\n (5) is critical to the direct fulfillment of military or intelligence missions,\n but excluding any system that is to be used for routine administrative and\n business applications (including payroll, finance, logistics, and personnel\n management applications)." }, - "code": "control 'V-61727' do\n title \"The DBMS must support organizational requirements to enforce password\n complexity by the number of numeric 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-000168-DB-000072'\n tag \"gid\": 'V-61727'\n tag \"rid\": 'SV-76217r1_rule'\n tag \"stig_id\": 'O121-C2-014300'\n tag \"fix_id\": 'F-67643r1_fix'\n tag \"cci\": ['CCI-000194']\n tag \"nist\": ['IA-5 (1) (a)', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"If all user accounts are managed and authenticated by the OS or\n an enterprise-level authentication/access mechanism, and not by Oracle, this is\n not a finding.\n\n For each profile that can be applied to accounts where authentication is under\n Oracle's control, determine the password verification function, if any, that is\n in use:\n\n SELECT * FROM SYS.DBA_PROFILES\n WHERE RESOURCE_NAME = 'PASSWORD_VERIFY_FUNCTION'\n [AND PROFILE NOT IN ()]\n ORDER BY PROFILE;\n Bearing in mind that a profile can inherit from another profile, and the root\n profile is called DEFAULT, determine the name of the password verification\n function effective for each profile.\n\n If, for any profile, the function name is null, this is a finding.\n\n For each password verification function, examine its source code.\n\n If it does not enforce the organization-defined minimum number of numeric\n characters (1 unless otherwise specified), this is a finding.\"\n tag \"fix\": \"If all user accounts are authenticated by the OS or an\n enterprise-level authentication/access mechanism, and not by Oracle, no fix to\n the DBMS is required.\n\n If any user accounts are managed by Oracle: Develop, test and implement a\n password verification function that enforces DoD requirements.\n\n (Oracle supplies a sample function called ORA12C_STRONG_VERIFY_FUNCTION, in the\n script file\n /RDBMS/ADMIN/utlpwdmg.sql. This can be used as the starting point\n for a customized function.)\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n query = %{\n SELECT PROFILE, RESOURCE_NAME, LIMIT FROM DBA_PROFILES WHERE PROFILE =\n '%s' AND RESOURCE_NAME = 'PASSWORD_VERIFY_FUNCTION'\n }\n\n user_profiles = sql.query('SELECT profile FROM dba_users;').column('profile').uniq\n\n user_profiles.each do |profile|\n next if profile == \"RDSADMIN\"\n password_verify_function = sql.query(format(query, profile: profile)).column('limit')\n\n describe \"The oracle database account password verify function for profile: #{profile}\" do\n subject { password_verify_function }\n it { should_not eq ['NULL'] }\n end\n end\n if user_profiles.empty?\n describe 'There are no user profiles, therefore this control is NA' do\n skip 'There are no user profiles, therefore this control is NA'\n end\n end\nend\n", + "code": " control 'V-61759' do\n impact 0.0\n describe 'This control is not applicable on oracle within aws rds, as aws manages the operating system in which the oracle database is running on' do\n skip 'This control is not applicable on oracle within aws rds, as aws manages the operating system in which the oracle database is running on'\n end\n end\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61727.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61759.rb", "line": 1 }, - "id": "V-61727" + "id": "V-61759" }, { - "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": "The DBMS must disable user accounts after 35 days of inactivity.", + "desc": "Password complexity, or strength, is a measure of the effectiveness of\n a password in resisting attempts at guessing and brute-force attacks.\n\n To meet password policy requirements, passwords need to be changed at\n specific policy-based intervals.\n\n If the information system or application allows the user to consecutively\n reuse their password when that password has exceeded its defined lifetime, the\n end result is a password that is not changed as per policy requirements.\n\n Unused or expired DBMS accounts provide a means for undetected,\n unauthorized access to the database.\n\n Note that user authentication and account management must be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP This requirement applies to cases where it is necessary to\n have accounts directly managed by Oracle.", "descriptions": { - "default": "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": "Password complexity, or strength, is a measure of the effectiveness of\n a password in resisting attempts at guessing and brute-force attacks.\n\n To meet password policy requirements, passwords need to be changed at\n specific policy-based intervals.\n\n If the information system or application allows the user to consecutively\n reuse their password when that password has exceeded its defined lifetime, the\n end result is a password that is not changed as per policy requirements.\n\n Unused or expired DBMS accounts provide a means for undetected,\n unauthorized access to the database.\n\n Note that user authentication and account management must be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP This requirement applies to cases where it is necessary to\n have accounts directly managed by Oracle." }, - "impact": 0, + "impact": 0.5, "refs": [ { "ref": [] } ], "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-000163-DB-000113", + "gid": "V-61717", + "rid": "SV-76207r2_rule", + "stig_id": "O121-C2-013800", + "fix_id": "F-67633r3_fix", "cci": [ - "CCI-000196" + "CCI-000795" ], "nist": [ - "IA-5 (1) (c)", + "IA-4 e)", "Rev_4" ], "false_negatives": null, @@ -1881,35 +1964,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": "If all user accounts are managed and authenticated by the OS or\n an enterprise-level authentication/access mechanism, and not by Oracle, this is\n not a finding.\n\n For accounts managed by Oracle, check DBMS settings to determine if accounts\n can be automatically disabled by the system after 35 days of inactivity. Also,\n ask the DBA if an alternative method, such as a stored procedure run daily, to\n disable Oracle-managed accounts inactive for more than 35 days, has been\n deployed.\n\n If the ability to disable accounts after 35 days of inactivity, by either of\n these means, does not exist, this is a finding.\n\n - - - - -\n\n Check to see what profile each user is associated with, if any, with this query:\n\n select username, profile from dba_users order by 1,2;\n\n Then check the profile to see what the password_life_time is set to in the\n table dba_profiles; the password_life_time is a value stored in the LIMIT\n column, and identified by the value PASSWORD_LIFE_TIME in the RESOURCE_NAME\n column.\n\n SQL>select profile, resource_name, resource_type, limit from dba_profiles where\n upper(resource_name) = 'PASSWORD_LIFE_TIME';", + "fix": "For accounts managed by Oracle, determine if it is practical and\n acceptable to require a password change every 35 days or fewer, rather than the\n standard 60 days (as specified in SRG-APP-000174-DB-000080). If it is, issue\n the statement:\n\n ALTER PROFILE PPPPPP LIMIT PASSWORD_LIFE_TIME 35;\n (See the Oracle-provided $ORACLE_HOME/rdbms/admin/secconf.sql script for\n examples.)\n\n If password changes every 35 days or fewer are unacceptable or impractical,\n implement an alternative method, such as a stored procedure run daily, to\n disable accounts inactive for more than 35 days." }, - "code": " control 'V-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-61717' do\n title 'The DBMS must disable user accounts after 35 days of inactivity.'\n desc \"Password complexity, or strength, is a measure of the effectiveness of\n a password in resisting attempts at guessing and brute-force attacks.\n\n To meet password policy requirements, passwords need to be changed at\n specific policy-based intervals.\n\n If the information system or application allows the user to consecutively\n reuse their password when that password has exceeded its defined lifetime, the\n end result is a password that is not changed as per policy requirements.\n\n Unused or expired DBMS accounts provide a means for undetected,\n unauthorized access to the database.\n\n Note that user authentication and account management must be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP This requirement applies to cases where it is necessary to\n have accounts directly managed by Oracle.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000163-DB-000113'\n tag \"gid\": 'V-61717'\n tag \"rid\": 'SV-76207r2_rule'\n tag \"stig_id\": 'O121-C2-013800'\n tag \"fix_id\": 'F-67633r3_fix'\n tag \"cci\": ['CCI-000795']\n tag \"nist\": ['IA-4 e)', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"If all user accounts are managed and authenticated by the OS or\n an enterprise-level authentication/access mechanism, and not by Oracle, this is\n not a finding.\n\n For accounts managed by Oracle, check DBMS settings to determine if accounts\n can be automatically disabled by the system after 35 days of inactivity. Also,\n ask the DBA if an alternative method, such as a stored procedure run daily, to\n disable Oracle-managed accounts inactive for more than 35 days, has been\n deployed.\n\n If the ability to disable accounts after 35 days of inactivity, by either of\n these means, does not exist, this is a finding.\n\n - - - - -\n\n Check to see what profile each user is associated with, if any, with this query:\n\n select username, profile from dba_users order by 1,2;\n\n Then check the profile to see what the password_life_time is set to in the\n table dba_profiles; the password_life_time is a value stored in the LIMIT\n column, and identified by the value PASSWORD_LIFE_TIME in the RESOURCE_NAME\n column.\n\n SQL>select profile, resource_name, resource_type, limit from dba_profiles where\n upper(resource_name) = 'PASSWORD_LIFE_TIME';\"\n tag \"fix\": \"For accounts managed by Oracle, determine if it is practical and\n acceptable to require a password change every 35 days or fewer, rather than the\n standard 60 days (as specified in SRG-APP-000174-DB-000080). If it is, issue\n the statement:\n\n ALTER PROFILE PPPPPP LIMIT PASSWORD_LIFE_TIME 35;\n (See the Oracle-provided $ORACLE_HOME/rdbms/admin/secconf.sql script for\n examples.)\n\n If password changes every 35 days or fewer are unacceptable or impractical,\n implement an alternative method, such as a stored procedure run daily, to\n disable accounts inactive for more than 35 days.\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n query = %{\n SELECT PROFILE, RESOURCE_NAME, LIMIT FROM DBA_PROFILES WHERE PROFILE =\n '%s' AND RESOURCE_NAME = 'PASSWORD_LIFE_TIME'\n }\n\n user_profiles = sql.query('SELECT profile FROM dba_users;').column('profile').uniq\n\n user_profiles.each do |profile|\n next if profile == \"RDSADMIN\"\n password_life_time = sql.query(format(query, profile: profile)).column('limit')\n\n describe \"The oracle database account password life time for profile: #{profile}\" do\n subject { password_life_time }\n it { should cmp <= input('account_inactivity_age') }\n end\n end\n if user_profiles.empty?\n describe 'There are no user profiles, therefore this control is NA' do\n skip 'There are no user profiles, therefore this control is NA'\n end\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61733.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61717.rb", "line": 1 }, - "id": "V-61733" + "id": "V-61717" }, { - "title": "DBMS must conduct backups of system-level information per\n organization-defined frequency that is consistent with recovery time and\n recovery point objectives.", - "desc": "Information system backup is a critical step in maintaining data\n assurance and availability.\n\n System-level information includes: system-state information, operating\n system and application software, and licenses.\n\n Backups shall be consistent with organizational recovery time and recovery\n point objectives.\n\n Databases that do not back up information regularly risk the loss of that\n information in the event of a system failure. Most databases contain\n functionality to allow regular backups; it is important that this functionality\n is enabled and configured correctly to prevent data loss.", + "title": "Processes (services, applications, etc.) that connect to the DBMS\n independently of individual users, must use valid, current DoD-issued PKI\n certificates for authentication to the DBMS.", + "desc": "Just as individual users must be authenticated, and just as they must\n use PKI-based authentication, so must any processes that connect to the DBMS.\n\n The DoD standard for authentication of a process or device communicating\n with another process or device is the presentation of a valid, current,\n DoD-issued Public Key Infrastructure (PKI) certificate that has previously been\n verified as Trusted by an administrator of the other process or device.\n\n This applies both to processes that run on the same server as the DBMS and\n to processes running on other computers.\n\n The Oracle-supplied accounts, SYS, SYSBACKUP, SYSDG, and SYSKM, are\n exceptions. These cannot currently use certificate-based authentication. For\n this reason among others, use of these accounts should be restricted to where\n it is truly needed.", "descriptions": { - "default": "Information system backup is a critical step in maintaining data\n assurance and availability.\n\n System-level information includes: system-state information, operating\n system and application software, and licenses.\n\n Backups shall be consistent with organizational recovery time and recovery\n point objectives.\n\n Databases that do not back up information regularly risk the loss of that\n information in the event of a system failure. Most databases contain\n functionality to allow regular backups; it is important that this functionality\n is enabled and configured correctly to prevent data loss." + "default": "Just as individual users must be authenticated, and just as they must\n use PKI-based authentication, so must any processes that connect to the DBMS.\n\n The DoD standard for authentication of a process or device communicating\n with another process or device is the presentation of a valid, current,\n DoD-issued Public Key Infrastructure (PKI) certificate that has previously been\n verified as Trusted by an administrator of the other process or device.\n\n This applies both to processes that run on the same server as the DBMS and\n to processes running on other computers.\n\n The Oracle-supplied accounts, SYS, SYSBACKUP, SYSDG, and SYSKM, are\n exceptions. These cannot currently use certificate-based authentication. For\n this reason among others, use of these accounts should be restricted to where\n it is truly needed." }, "impact": 0.5, "refs": [], "tags": { - "gtitle": "SRG-APP-000146-DB-000099", - "gid": "V-61701", - "rid": "SV-76191r1_rule", - "stig_id": "O121-C2-012600", - "fix_id": "F-67617r1_fix", + "gtitle": "SRG-APP-000177-DB-000069", + "gid": "V-61745", + "rid": "SV-76235r2_rule", + "stig_id": "O121-C2-015501", + "fix_id": "F-67661r1_fix", "cci": [ - "CCI-000537" + "CCI-000366" ], "nist": [ - "CP-9 (b)", + "CM-6 b", "Rev_4" ], "false_negatives": null, @@ -1922,39 +2005,36 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Review DBMS and OS backup configuration to determine that\n system-level data is backed up in according with organization-defined frequency.\n\n If the system-level data of the DBMS is not backed up to the\n organization-defined frequency, this is a finding.", - "fix": "Utilize DBMS, OS, or third-party product(s) to meet the\n requirement of backing up system data according to the organization-defined\n frequency." + "check": "Review configuration to confirm that accounts used by processes\n to connect to the DBMS are authenticated using valid, current DoD-issued PKI\n certificates.\n\n If any such account (other than SYS, SYSBACKUP, SYSDG, and SYSKM) is not\n certificate-based, this is a finding.", + "fix": "For each such account, use DoD certificate-based authentication." }, - "code": "control 'V-61701' do\n title \"DBMS must conduct backups of system-level information per\n organization-defined frequency that is consistent with recovery time and\n recovery point objectives.\"\n desc \"Information system backup is a critical step in maintaining data\n assurance and availability.\n\n System-level information includes: system-state information, operating\n system and application software, and licenses.\n\n Backups shall be consistent with organizational recovery time and recovery\n point objectives.\n\n Databases that do not back up information regularly risk the loss of that\n information in the event of a system failure. Most databases contain\n functionality to allow regular backups; it is important that this functionality\n is enabled and configured correctly to prevent data loss.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000146-DB-000099'\n tag \"gid\": 'V-61701'\n tag \"rid\": 'SV-76191r1_rule'\n tag \"stig_id\": 'O121-C2-012600'\n tag \"fix_id\": 'F-67617r1_fix'\n tag \"cci\": ['CCI-000537']\n tag \"nist\": ['CP-9 (b)', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Review DBMS and OS backup configuration to determine that\n system-level data is backed up in according with organization-defined frequency.\n\n If the system-level data of the DBMS is not backed up to the\n organization-defined frequency, this is a finding.\"\n tag \"fix\": \"Utilize DBMS, OS, or third-party product(s) to meet the\n requirement of backing up system data according to the organization-defined\n frequency.\"\n describe 'A manual is required to ensure the DBMS conducts backups of system-level information per\n organization-defined frequency that is consistent with recovery time and\n recovery point objectives' do\n skip 'A manual is required to ensure the DBMS conducts backups of system-level information per\n organization-defined frequency that is consistent with recovery time and\n recovery point objectives'\n end\nend\n", + "code": "control 'V-61745' do\n title \"Processes (services, applications, etc.) that connect to the DBMS\n independently of individual users, must use valid, current DoD-issued PKI\n certificates for authentication to the DBMS.\"\n desc \"Just as individual users must be authenticated, and just as they must\n use PKI-based authentication, so must any processes that connect to the DBMS.\n\n The DoD standard for authentication of a process or device communicating\n with another process or device is the presentation of a valid, current,\n DoD-issued Public Key Infrastructure (PKI) certificate that has previously been\n verified as Trusted by an administrator of the other process or device.\n\n This applies both to processes that run on the same server as the DBMS and\n to processes running on other computers.\n\n The Oracle-supplied accounts, SYS, SYSBACKUP, SYSDG, and SYSKM, are\n exceptions. These cannot currently use certificate-based authentication. For\n this reason among others, use of these accounts should be restricted to where\n it is truly needed.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000177-DB-000069'\n tag \"gid\": 'V-61745'\n tag \"rid\": 'SV-76235r2_rule'\n tag \"stig_id\": 'O121-C2-015501'\n tag \"fix_id\": 'F-67661r1_fix'\n tag \"cci\": ['CCI-000366']\n tag \"nist\": ['CM-6 b', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Review configuration to confirm that accounts used by processes\n to connect to the DBMS are authenticated using valid, current DoD-issued PKI\n certificates.\n\n If any such account (other than SYS, SYSBACKUP, SYSDG, and SYSKM) is not\n certificate-based, this is a finding.\"\n tag \"fix\": 'For each such account, use DoD certificate-based authentication.'\n describe 'A manual review is required to ensure processes (services, applications, etc.) that connect to the DBMS\n independently of individual users, must use valid, current DoD-issued PKI\n certificates for authentication to the DBMS' do\n skip 'A manual review is required to ensure processes (services, applications, etc.) that connect to the DBMS\n independently of individual users, must use valid, current DoD-issued PKI\n certificates for authentication to the DBMS'\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61701.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61745.rb", "line": 1 }, - "id": "V-61701" + "id": "V-61745" }, { - "title": "Database software, applications, and configuration files must be\n monitored to discover unauthorized changes.", - "desc": "Any changes to the hardware, software, and/or firmware components of\n the information system and/or application can potentially have significant\n effects on the overall security of the system.\n\n If the system were to allow any user to make changes to software libraries,\n then those changes might be implemented without undergoing the appropriate\n testing and approvals that are part of a robust change management process.\n\n Accordingly, only qualified and authorized individuals shall be allowed to\n obtain access to information system components for purposes of initiating\n changes, including upgrades and modifications.\n\n Unmanaged changes that occur to the database software libraries or\n configuration can lead to unauthorized or compromised installations.", + "title": "The DBMS must be protected from unauthorized access by developers.", + "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 production databases can affect the operation and/or security of the database\n system. Operating system and database privileges assigned to developers on\n production systems must not be allowed.", "descriptions": { - "default": "Any changes to the hardware, software, and/or firmware components of\n the information system and/or application can potentially have significant\n effects on the overall security of the system.\n\n If the system were to allow any user to make changes to software libraries,\n then those changes might be implemented without undergoing the appropriate\n testing and approvals that are part of a robust change management process.\n\n Accordingly, only qualified and authorized individuals shall be allowed to\n obtain access to information system components for purposes of initiating\n changes, including upgrades and modifications.\n\n Unmanaged changes that occur to the database software libraries or\n configuration can lead to unauthorized or compromised installations." + "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 production databases can affect the operation and/or security of the database\n system. Operating system and database privileges assigned to developers on\n production systems must not be allowed." }, - "impact": 0, - "refs": [ - { - "ref": [] - } - ], + "impact": 0.5, + "refs": [], "tags": { - "gtitle": "SRG-APP-000133-DB-000179", - "gid": "V-61867", - "rid": "SV-76357r2_rule", - "stig_id": "O121-OS-010700", - "fix_id": "F-67783r2_fix", + "gtitle": "SRG-APP-000062-DB-000014", + "gid": "V-61585", + "rid": "SV-76075r1_rule", + "stig_id": "O121-C2-003700", + "fix_id": "F-67501r1_fix", "cci": [ - "CCI-001499" + "CCI-000366", + "CCI-002220" ], "nist": [ - "CM-5 (6)", + "AC-5 c", "Rev_4" ], "false_negatives": null, @@ -1967,35 +2047,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Review monitoring procedures and implementation evidence to\n verify that monitoring of changes to database software libraries, related\n applications, and configuration files is done.\n\n Verify that the list of files and directories being monitored is complete. If\n monitoring does not occur or is not complete, this is a finding.", - "fix": "Implement procedures to monitor for unauthorized changes to DBMS\n software libraries, related software application libraries, and configuration\n files. If a third-party automated tool is not employed, an automated job that\n reports file information on the directories and files of interest and compares\n them to the baseline report for the same will meet the requirement.\n\n File hashes or checksums should be used for comparisons since file dates may be\n manipulated by malicious users." + "check": "Check the production system to ensure no developer accounts\n have rights to modify the production database structure or alter production\n data.\n\n If developer accounts with these rights exist, ask for documentation that shows\n these accounts have formal approval and risk acceptance. If this documentation\n does not exist, 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.", + "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." }, - "code": " control 'V-61867' 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-61585' do\n title 'The DBMS must be protected from unauthorized access by developers.'\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 production databases can affect the operation and/or security of the database\n system. Operating system and database privileges assigned to developers on\n production systems must not be allowed.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000062-DB-000014'\n tag \"gid\": 'V-61585'\n tag \"rid\": 'SV-76075r1_rule'\n tag \"stig_id\": 'O121-C2-003700'\n tag \"fix_id\": 'F-67501r1_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\": \"Check the production system to ensure no developer accounts\n have rights to modify the production database structure or alter production\n data.\n\n If developer accounts with these rights exist, ask for documentation that shows\n these accounts have formal approval and risk acceptance. If this documentation\n does not exist, 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 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' do\n skip 'A manual review is required to ensure the DBMS is protected from unauthorized access by developers'\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61867.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61585.rb", "line": 1 }, - "id": "V-61867" + "id": "V-61585" }, { - "title": "DBMS production application and data directories must be protected\n from developers on shared production/development DBMS host systems.", - "desc": "Developer roles must not be assigned DBMS administrative privileges to\n production DBMS application and data directories. The separation of production\n DBA and developer roles helps protect the production system from unauthorized,\n malicious or unintentional interruption due to development activities.", + "title": "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": "Developer roles must not be assigned DBMS administrative privileges to\n production DBMS application and data directories. The separation of production\n DBA and developer roles helps protect the production system from unauthorized,\n malicious or unintentional interruption due to development activities." + "default": "Information 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.5, "refs": [], "tags": { - "gtitle": "SRG-APP-000516-DB-999900", - "gid": "V-61487", - "rid": "SV-75977r1_rule", - "stig_id": "O121-BP-024100", - "fix_id": "F-67403r1_fix", + "gtitle": "SRG-APP-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, @@ -2008,35 +2088,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "If the DBMS or DBMS host is not shared by production and\n development activities, this check is not a finding.\n\n Review OS DBA group membership.\n\n If any developer accounts, as identified in the System Security Plan, have been\n assigned DBA privileges, this is a finding.\n\n Note: Though shared production/non-production DBMS installations was allowed\n under previous database STIG guidance, doing so may place it in violation of\n OS, Application, Network or Enclave STIG guidance. Ensure that any shared\n production/non-production DBMS installation meets STIG guidance requirements at\n all levels or mitigate any conflicts in STIG guidance with the AO.", - "fix": "Create separate DBMS host OS groups for developer and production\n DBAs.\n\n Do not assign production DBA OS group membership to accounts used for\n development.\n\n Remove development accounts from production DBA OS group membership.\n\n Recommend establishing a dedicated DBMS host for production DBMS installations.\n A dedicated host system in this case refers to an instance of the operating\n system at a minimum. The operating system may reside on a virtual host machine\n where supported by the DBMS vendor." + "check": "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-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", + "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-61487.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61627.rb", "line": 1 }, - "id": "V-61487" + "id": "V-61627" }, { - "title": "Fixed user and public database links must be authorized for use.", - "desc": "Database links define connections that may be used by the local\n database to access remote Oracle databases. These links provide a means for a\n compromise to the local database to spread to remote databases in the\n distributed database environment. Limiting or eliminating use of database links\n where they are not required to support the operational system can help isolate\n compromises to the local or a limited number of databases.", + "title": "The DBMS must protect audit data records and integrity by using\n cryptographic mechanisms.", + "desc": "Protection of audit records and audit data is of critical importance.\n Cryptographic mechanisms are the industry-established standard used to protect\n the integrity of audit data. An example of a cryptographic mechanism is the\n computation and application of a cryptographic-signed hash using asymmetric\n cryptography.\n\n Non-repudiation protects individuals against later claims by an author of\n not having performed a particular action, a sender of not having transmitted a\n message, a receiver of not having received a message, or a signatory of not\n having signed a document.", "descriptions": { - "default": "Database links define connections that may be used by the local\n database to access remote Oracle databases. These links provide a means for a\n compromise to the local database to spread to remote databases in the\n distributed database environment. Limiting or eliminating use of database links\n where they are not required to support the operational system can help isolate\n compromises to the local or a limited number of databases." + "default": "Protection of audit records and audit data is of critical importance.\n Cryptographic mechanisms are the industry-established standard used to protect\n the integrity of audit data. An example of a cryptographic mechanism is the\n computation and application of a cryptographic-signed hash using asymmetric\n cryptography.\n\n Non-repudiation protects individuals against later claims by an author of\n not having performed a particular action, a sender of not having transmitted a\n message, a receiver of not having received a message, or a signatory of not\n having signed a document." }, - "impact": 0, + "impact": 0.5, "refs": [], "tags": { - "gtitle": "SRG-APP-000516-DB-999900", - "gid": "V-61415", - "rid": "SV-75905r2_rule", - "stig_id": "O121-BP-021400", - "fix_id": "F-67331r1_fix", + "gtitle": "SRG-APP-000126-DB-000171", + "gid": "V-61667", + "rid": "SV-76157r2_rule", + "stig_id": "O121-C2-010100", + "fix_id": "F-67581r5_fix", "cci": [ - "CCI-000366" + "CCI-001350" ], "nist": [ - "CM-6 b", + "AU-9 (3)", "Rev_4" ], "false_negatives": null, @@ -2049,35 +2129,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "From SQL*Plus:\n\n select owner||': '||db_link from dba_db_links;\n\n If no records are returned from the first SQL statement, this check is not a\n finding.\n\n Confirm the public and fixed user database links listed are documented in the\n System Security Plan, are authorized by the ISSO, and are used for replication\n or operational system requirements.\n\n If any are not, this is a finding.\n ", - "fix": "Document all authorized connections from the database to remote\n databases in the System Security Plan.\n\n Remove all unauthorized remote database connection definitions from the\n database.\n\n From SQL*Plus:\n\n drop database link [link name];\n OR\n drop public database link [link name];\n\n Review remote database connection definitions periodically and confirm their\n use is still required and authorized." + "check": "Review the DBMS settings to determine whether audit logging is\n configured to produce logs consistent with the amount of space allocated for\n logging.\n\n If auditing will generate excessive logs so that they may outgrow the space\n reserved for logging, this is a finding.\n\n If file-based auditing is in use, check that the file(s) is/are encrypted by\n the operating system/file system.\n\n If not, this is a finding\n\n If standard, table-based auditing is used: The audit logs are written to a\n table called AUD$, and if a Virtual Private Database is deployed, we also\n create a table called FGA_LOG$. First check the current location of the audit\n trail tables.\n\n CONN / AS SYSDBA\n\n SELECT table_name, tablespace_name\n FROM dba_tables\n WHERE table_name IN ('AUD$', 'FGA_LOG$')\n ORDER BY table_name;\n\n TABLE_NAME TABLESPACE_NAME\n ------------------------------ ------------------------------\n AUD$ SYSTEM\n FGA_LOG$ SYSTEM\n\n If the tablespace name is SYSTEM, the table needs to be relocated to its own\n tablespace. Ensure that adequate space is allocated to that tablespace.\n\n If Unified Auditing is used:\n Audit logs are written to tables in the AUDSYS schema. The default tablespace\n for AUDSYS is USERS. A separate tablespace should be created to contain audit\n data. Ensure that adequate space is allocated to that tablespace.", + "fix": "For file-based auditing (OS, XML, or XML,EXTENDED), implement\n operating system/file system encryption for the audit file.\n\n For table-based auditing, deploy the audit tables in an encrypted tablespace.\n\n - - - - -\n If auditing is not enabled, use the following steps to enable auditing.\n\n sqlplus connect as sysdba\n\n Turn on Oracle audit\n\n a. If the database uses an spfile\n\n SQL> alter system set audit_trail=DB,EXTENDED scope=spfile ;\n System altered.\n\n b. if database uses pfile, modify init.ora directly.\n For these changes to take place, the database must be restarted.\n\n Next we create an encrypted tablespace. Before tablespaces can be encrypted or\n decrypted, a master encryption key must be generated or set. The tablespace\n master encryption key is stored in an external security module and is used to\n encrypt the TDE tablespace encryption keys.\n\n - - - - -\n\n Caution: Do not attempt to encrypt Oracle internal objects such as the SYSTEM,\n SYSAUX, UNDO, or TEMP tablespaces. Oracle does not support this with TDE.\n When moving AUD$ to a new tablespace, be aware that associated LOB objects will\n also need to be moved. Finally, when upgrading, the AUD$ table and LOBs will\n need to be moved back to the SYSTEM tablespace or the upgrade will fail.\n\n - - - - -\n\n Check to ensure that the ENCRYPTION_WALLET_LOCATION (or WALLET_LOCATION)\n parameter in the sqlnet.ora file points to the correct software wallet\n location. (Note: This assumes that a single sqlnet.ora file, in the default\n location, is 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.) For example:\n\n ENCRYPTION_WALLET_LOCATION=\n (SOURCE=(METHOD=FILE)(METHOD_DATA=\n (DIRECTORY=/app/wallet)))\n\n If the ENCRYPTION_WALLET_LOCATION parameter is not set, then it attempts to use\n the keystore in the location that is specified by the parameter WALLET_LOCATION.\n\n If the WALLET_LOCATION parameter is also not set, then Oracle Database looks\n for a keystore at the default database location, which is\n ORACLE_BASE/admin/DB_UNIQUE_NAME/wallet or\n ORACLE_HOME/admin/DB_UNIQUE_NAME/wallet. (DB_UNIQUE_NAME is the unique name of\n the database specified in the initialization parameter file.) When the keystore\n location is not set in the sqlnet.ora file, then the V$ENCRYPTION_WALLET view\n displays the default location. Can check the location and status of the\n keystore in the V$ENCRYPTION_WALLET view.\n\n Oracle Database 12c Release 1 (12.1) uses the same master encryption key for\n both TDE column encryption and TDE tablespace encryption. When issuing the\n ALTER SYSTEM SET ENCRYPTION KEY command, a unified master encryption key is\n created for both TDE column encryption and TDE tablespace encryption.\n\n Resetting the Tablespace Master Encryption Key\n\n Oracle Database 12c Release 1 (12.1) uses a unified master encryption key for\n both TDE column encryption and TDE tablespace encryption. When resetting\n (rekeying) the master encryption key for TDE column encryption, the master\n encryption key for TDE tablespace encryption also gets reset. The ALTER SYSTEM\n SET ENCRYPTION KEY command resets the tablespace master encryption key. Before\n creating an encrypted tablespace, the Oracle wallet containing the tablespace\n master encryption key must be open. The wallet must also be open before\n accessing data in an encrypted tablespace. The security administrator needs to\n open the Oracle wallet after starting the Oracle instance. A restart of the\n Oracle instance requires the security administrator to open the wallet again.\n The security administrator also needs to open the wallet before performing\n database recovery operations. This is because background processes may require\n access to encrypted redo and undo logs. When performing database recovery, the\n wallet must be opened before opening the database. This is illustrated in the\n following statements:\n\n SQL> STARTUP MOUNT;\n SQL> ALTER SYSTEM SET ENCRYPTION WALLET OPEN IDENTIFIED BY \"password\";\n SQL> ALTER DATABASE OPEN;\n\n Can also choose to use auto logon wallets if the environment does not require\n the extra security provided by a wallet that needs to be explicitly opened;\n however, this is not the recommended practice.\n\n Creating the wallet/keystore\n\n SQL> ADMINISTER KEY MANAGEMENT CREATE KEYSTORE '/app/wallet' IDENTIFIED BY\n password;\n\n keystore altered.\n\n Set the TDE Master Encryption Key in the Software Keystore\n\n SQL> ADMINISTER KEY MANAGEMENT SET KEY IDENTIFIED BY password WITH BACKUP USING\n 'backup_identifier';\n\n keystore altered.\n\n Creating an Encrypted Tablespace\n\n The CREATE TABLESPACE command enables the creation of an encrypted tablespace.\n The permanent_tablespace_clause enables choosing the encryption algorithm and\n the key length for encryption. The ENCRYPT keyword in the storage_clause\n encrypts the tablespace. The following syntax illustrates this:\n\n CREATE\n [ BIGFILE | SMALLFILE ]\n { permanent_tablespace_clause\n | temporary_tablespace_clause\n | undo_tablespace_clause\n } ;\n\n Where, permanent_tablespace_clause=TABLESPACE , ENCRYPTION [USING algorithm]\n storage_clause\n Where, storage_clause=[ENCRYPT] where:\n\n The encryption algorithm can have one of the following values:\n\n 3DES168\n AES128\n AES192\n AES256\n\n The key lengths are included in the names of the algorithms themselves. If no\n encryption algorithm is specified, the default encryption algorithm is used.\n The default encryption algorithm is AES128.\n\n Note: The ENCRYPTION keyword in the permanent_tablespace_clause is used to\n specify the encryption algorithm. The ENCRYPT keyword in the storage_clause\n actually encrypts the tablespace. For security reasons, a tablespace cannot be\n encrypted with the NO SALT option.\n\n Commands to create Encrypted Tablespace\n\n CREATE TABLESPACE securespace\n DATAFILE '/home/user/oradata/secure01.dbf'\n SIZE 150M\n ENCRYPTION USING '3DES168'\n DEFAULT STORAGE(ENCRYPT);\n\n This creates a tablespace called securespace2 using an algorithm of 3DES168.\n\n Cannot encrypt an existing tablespace. However, can import data into an\n encrypted tablespace using the Oracle Data Pump utility. Can also use SQL\n commands like CREATE TABLE...AS SELECT...or ALTER TABLE...MOVE... to move data\n into an encrypted tablespace. The CREATE TABLE...AS SELECT... command enables\n the creation of a table from an existing table. The ALTER TABLE...MOVE...\n command enables the move of a table into the encrypted tablespace.\n\n Then we move the sys.aud$ from system tablespace to securespace tablespace.\n\n SQL> exec DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_LOCATION(audit_trail_type =>\n DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD, audit_trail_location_value =>\n 'securespace');\n\n PL/SQL procedure successfully completed.\n\n Then check the tablespace the table is stored in.\n\n SQL> SELECT table_name, tablespace_name FROM dba_tables WHERE table_name\n ='AUD$';\n\n TABLE_NAME TABLESPACE_NAME\n ---------------------------- ------------------------\n AUD$ SECURESPACE" }, - "code": "control 'V-61415' do\n title 'Fixed user and public database links must be authorized for use.'\n desc \"Database links define connections that may be used by the local\n database to access remote Oracle databases. These links provide a means for a\n compromise to the local database to spread to remote databases in the\n distributed database environment. Limiting or eliminating use of database links\n where they are not required to support the operational system can help isolate\n compromises to the local or a limited number of databases.\"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000516-DB-999900'\n tag \"gid\": 'V-61415'\n tag \"rid\": 'SV-75905r2_rule'\n tag \"stig_id\": 'O121-BP-021400'\n tag \"fix_id\": 'F-67331r1_fix'\n tag \"cci\": ['CCI-000366']\n tag \"nist\": ['CM-6 b', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"From SQL*Plus:\n\n select owner||': '||db_link from dba_db_links;\n\n If no records are returned from the first SQL statement, this check is not a\n finding.\n\n Confirm the public and fixed user database links listed are documented in the\n System Security Plan, are authorized by the ISSO, and are used for replication\n or operational system requirements.\n\n If any are not, this is a finding.\n \"\n tag \"fix\": \"Document all authorized connections from the database to remote\n databases in the System Security Plan.\n\n Remove all unauthorized remote database connection definitions from the\n database.\n\n From SQL*Plus:\n\n drop database link [link name];\n OR\n drop public database link [link name];\n\n Review remote database connection definitions periodically and confirm their\n use is still required and authorized.\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n db_links = sql.query('SELECT DB_LINK FROM DBA_DB_LINKS;').column('db_link').uniq\n if db_links.empty?\n impact 0.0\n describe 'There are no oracle database links defined, control N/A' do\n skip 'There are no oracle database links defined, control N/A'\n end\n else\n db_links.each do |link|\n describe \"The defined oracle database link: #{link}\" do\n subject { link }\n it { should be_in input('allowed_db_links') }\n end\n end\n end\nend\n", + "code": "control 'V-61667' do\n title \"The DBMS must protect audit data records and integrity by using\n cryptographic mechanisms.\"\n desc \"Protection of audit records and audit data is of critical importance.\n Cryptographic mechanisms are the industry-established standard used to protect\n the integrity of audit data. An example of a cryptographic mechanism is the\n computation and application of a cryptographic-signed hash using asymmetric\n cryptography.\n\n Non-repudiation protects individuals against later claims by an author of\n not having performed a particular action, a sender of not having transmitted a\n message, a receiver of not having received a message, or a signatory of not\n having signed a document.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000126-DB-000171'\n tag \"gid\": 'V-61667'\n tag \"rid\": 'SV-76157r2_rule'\n tag \"stig_id\": 'O121-C2-010100'\n tag \"fix_id\": 'F-67581r5_fix'\n tag \"cci\": ['CCI-001350']\n tag \"nist\": ['AU-9 (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\": \"Review the DBMS settings to determine whether audit logging is\n configured to produce logs consistent with the amount of space allocated for\n logging.\n\n If auditing will generate excessive logs so that they may outgrow the space\n reserved for logging, this is a finding.\n\n If file-based auditing is in use, check that the file(s) is/are encrypted by\n the operating system/file system.\n\n If not, this is a finding\n\n If standard, table-based auditing is used: The audit logs are written to a\n table called AUD$, and if a Virtual Private Database is deployed, we also\n create a table called FGA_LOG$. First check the current location of the audit\n trail tables.\n\n CONN / AS SYSDBA\n\n SELECT table_name, tablespace_name\n FROM dba_tables\n WHERE table_name IN ('AUD$', 'FGA_LOG$')\n ORDER BY table_name;\n\n TABLE_NAME TABLESPACE_NAME\n ------------------------------ ------------------------------\n AUD$ SYSTEM\n FGA_LOG$ SYSTEM\n\n If the tablespace name is SYSTEM, the table needs to be relocated to its own\n tablespace. Ensure that adequate space is allocated to that tablespace.\n\n If Unified Auditing is used:\n Audit logs are written to tables in the AUDSYS schema. The default tablespace\n for AUDSYS is USERS. A separate tablespace should be created to contain audit\n data. Ensure that adequate space is allocated to that tablespace.\"\n tag \"fix\": \"For file-based auditing (OS, XML, or XML,EXTENDED), implement\n operating system/file system encryption for the audit file.\n\n For table-based auditing, deploy the audit tables in an encrypted tablespace.\n\n - - - - -\n If auditing is not enabled, use the following steps to enable auditing.\n\n sqlplus connect as sysdba\n\n Turn on Oracle audit\n\n a. If the database uses an spfile\n\n SQL> alter system set audit_trail=DB,EXTENDED scope=spfile ;\n System altered.\n\n b. if database uses pfile, modify init.ora directly.\n For these changes to take place, the database must be restarted.\n\n Next we create an encrypted tablespace. Before tablespaces can be encrypted or\n decrypted, a master encryption key must be generated or set. The tablespace\n master encryption key is stored in an external security module and is used to\n encrypt the TDE tablespace encryption keys.\n\n - - - - -\n\n Caution: Do not attempt to encrypt Oracle internal objects such as the SYSTEM,\n SYSAUX, UNDO, or TEMP tablespaces. Oracle does not support this with TDE.\n When moving AUD$ to a new tablespace, be aware that associated LOB objects will\n also need to be moved. Finally, when upgrading, the AUD$ table and LOBs will\n need to be moved back to the SYSTEM tablespace or the upgrade will fail.\n\n - - - - -\n\n Check to ensure that the ENCRYPTION_WALLET_LOCATION (or WALLET_LOCATION)\n parameter in the sqlnet.ora file points to the correct software wallet\n location. (Note: This assumes that a single sqlnet.ora file, in the default\n location, is 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.) For example:\n\n ENCRYPTION_WALLET_LOCATION=\n (SOURCE=(METHOD=FILE)(METHOD_DATA=\n (DIRECTORY=/app/wallet)))\n\n If the ENCRYPTION_WALLET_LOCATION parameter is not set, then it attempts to use\n the keystore in the location that is specified by the parameter WALLET_LOCATION.\n\n If the WALLET_LOCATION parameter is also not set, then Oracle Database looks\n for a keystore at the default database location, which is\n ORACLE_BASE/admin/DB_UNIQUE_NAME/wallet or\n ORACLE_HOME/admin/DB_UNIQUE_NAME/wallet. (DB_UNIQUE_NAME is the unique name of\n the database specified in the initialization parameter file.) When the keystore\n location is not set in the sqlnet.ora file, then the V$ENCRYPTION_WALLET view\n displays the default location. Can check the location and status of the\n keystore in the V$ENCRYPTION_WALLET view.\n\n Oracle Database 12c Release 1 (12.1) uses the same master encryption key for\n both TDE column encryption and TDE tablespace encryption. When issuing the\n ALTER SYSTEM SET ENCRYPTION KEY command, a unified master encryption key is\n created for both TDE column encryption and TDE tablespace encryption.\n\n Resetting the Tablespace Master Encryption Key\n\n Oracle Database 12c Release 1 (12.1) uses a unified master encryption key for\n both TDE column encryption and TDE tablespace encryption. When resetting\n (rekeying) the master encryption key for TDE column encryption, the master\n encryption key for TDE tablespace encryption also gets reset. The ALTER SYSTEM\n SET ENCRYPTION KEY command resets the tablespace master encryption key. Before\n creating an encrypted tablespace, the Oracle wallet containing the tablespace\n master encryption key must be open. The wallet must also be open before\n accessing data in an encrypted tablespace. The security administrator needs to\n open the Oracle wallet after starting the Oracle instance. A restart of the\n Oracle instance requires the security administrator to open the wallet again.\n The security administrator also needs to open the wallet before performing\n database recovery operations. This is because background processes may require\n access to encrypted redo and undo logs. When performing database recovery, the\n wallet must be opened before opening the database. This is illustrated in the\n following statements:\n\n SQL> STARTUP MOUNT;\n SQL> ALTER SYSTEM SET ENCRYPTION WALLET OPEN IDENTIFIED BY \\\"password\\\";\n SQL> ALTER DATABASE OPEN;\n\n Can also choose to use auto logon wallets if the environment does not require\n the extra security provided by a wallet that needs to be explicitly opened;\n however, this is not the recommended practice.\n\n Creating the wallet/keystore\n\n SQL> ADMINISTER KEY MANAGEMENT CREATE KEYSTORE '/app/wallet' IDENTIFIED BY\n password;\n\n keystore altered.\n\n Set the TDE Master Encryption Key in the Software Keystore\n\n SQL> ADMINISTER KEY MANAGEMENT SET KEY IDENTIFIED BY password WITH BACKUP USING\n 'backup_identifier';\n\n keystore altered.\n\n Creating an Encrypted Tablespace\n\n The CREATE TABLESPACE command enables the creation of an encrypted tablespace.\n The permanent_tablespace_clause enables choosing the encryption algorithm and\n the key length for encryption. The ENCRYPT keyword in the storage_clause\n encrypts the tablespace. The following syntax illustrates this:\n\n CREATE\n [ BIGFILE | SMALLFILE ]\n { permanent_tablespace_clause\n | temporary_tablespace_clause\n | undo_tablespace_clause\n } ;\n\n Where, permanent_tablespace_clause=TABLESPACE , ENCRYPTION [USING algorithm]\n storage_clause\n Where, storage_clause=[ENCRYPT] where:\n\n The encryption algorithm can have one of the following values:\n\n 3DES168\n AES128\n AES192\n AES256\n\n The key lengths are included in the names of the algorithms themselves. If no\n encryption algorithm is specified, the default encryption algorithm is used.\n The default encryption algorithm is AES128.\n\n Note: The ENCRYPTION keyword in the permanent_tablespace_clause is used to\n specify the encryption algorithm. The ENCRYPT keyword in the storage_clause\n actually encrypts the tablespace. For security reasons, a tablespace cannot be\n encrypted with the NO SALT option.\n\n Commands to create Encrypted Tablespace\n\n CREATE TABLESPACE securespace\n DATAFILE '/home/user/oradata/secure01.dbf'\n SIZE 150M\n ENCRYPTION USING '3DES168'\n DEFAULT STORAGE(ENCRYPT);\n\n This creates a tablespace called securespace2 using an algorithm of 3DES168.\n\n Cannot encrypt an existing tablespace. However, can import data into an\n encrypted tablespace using the Oracle Data Pump utility. Can also use SQL\n commands like CREATE TABLE...AS SELECT...or ALTER TABLE...MOVE... to move data\n into an encrypted tablespace. The CREATE TABLE...AS SELECT... command enables\n the creation of a table from an existing table. The ALTER TABLE...MOVE...\n command enables the move of a table into the encrypted tablespace.\n\n Then we move the sys.aud$ from system tablespace to securespace tablespace.\n\n SQL> exec DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_LOCATION(audit_trail_type =>\n DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD, audit_trail_location_value =>\n 'securespace');\n\n PL/SQL procedure successfully completed.\n\n Then check the tablespace the table is stored in.\n\n SQL> SELECT table_name, tablespace_name FROM dba_tables WHERE table_name\n ='AUD$';\n\n TABLE_NAME TABLESPACE_NAME\n ---------------------------- ------------------------\n AUD$ SECURESPACE\"\n describe 'A manual review is required to ensure the DBMS must protect audit data records and integrity by using\n cryptographic mechanisms' do\n skip 'A manual review is required to ensure the DBMS must protect audit data records and integrity by using\n cryptographic mechanisms'\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61415.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61667.rb", "line": 1 }, - "id": "V-61415" + "id": "V-61667" }, { - "title": "The DBMS must automatically audit account termination.", - "desc": "When application accounts are terminated, user accessibility is\n affected. Accounts are utilized for identifying individual application users\n or for identifying the application processes themselves.\n\n In order to detect and respond to events affecting user accessibility and\n application processing, applications must audit account terminating actions and\n notify the appropriate individuals so they can investigate the event. Such a\n capability greatly reduces the risk that application accessibility will be\n negatively affected for extended periods of time and provides logging that can\n be used for forensic purposes.\n\n Note that user authentication and account management should be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP.\n\n However, notwithstanding how accounts are managed, Oracle auditing should\n always be configured to capture account termination.", + "title": "Audit trail data must be retained for at least one year.", + "desc": "Without preservation, a complete discovery of an attack or suspicious\n activity may not be determined. DBMS audit data also contributes to the\n complete investigation of unauthorized activity and needs to be included in\n audit retention plans and procedures.", "descriptions": { - "default": "When application accounts are terminated, user accessibility is\n affected. Accounts are utilized for identifying individual application users\n or for identifying the application processes themselves.\n\n In order to detect and respond to events affecting user accessibility and\n application processing, applications must audit account terminating actions and\n notify the appropriate individuals so they can investigate the event. Such a\n capability greatly reduces the risk that application accessibility will be\n negatively affected for extended periods of time and provides logging that can\n be used for forensic purposes.\n\n Note that user authentication and account management should be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP.\n\n However, notwithstanding how accounts are managed, Oracle auditing should\n always be configured to capture account termination." + "default": "Without preservation, a complete discovery of an attack or suspicious\n activity may not be determined. DBMS audit data also contributes to the\n complete investigation of unauthorized activity and needs to be included in\n audit retention plans and procedures." }, "impact": 0.5, "refs": [], "tags": { - "gtitle": "SRG-APP-000029-DB-000188", - "gid": "V-61573", - "rid": "SV-76063r2_rule", - "stig_id": "O121-C2-002500", - "fix_id": "F-67489r2_fix", + "gtitle": "SRG-APP-000516-DB-999900", + "gid": "V-61409", + "rid": "SV-75899r1_rule", + "stig_id": "O121-BP-021100", + "fix_id": "F-67325r1_fix", "cci": [ - "CCI-001405" + "CCI-000366" ], "nist": [ - "AC-2 (4)", + "CM-6 b", "Rev_4" ], "false_negatives": null, @@ -2090,36 +2170,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Check Oracle settings (and also OS settings and/or\n enterprise-level authentication/access mechanisms settings) to determine if\n account termination actions are being audited. If account termination actions\n are not being audited by Oracle, this is a finding.\n\n If Standard Auditing is used:\n To see if Oracle is configured to capture audit data, enter the following\n SQL*Plus command:\n SHOW PARAMETER AUDIT_TRAIL\n or the following SQL query:\n SELECT * FROM SYS.V$PARAMETER WHERE NAME = 'audit_trail';\n If Oracle returns the value 'NONE', this is a finding.\n\n If Unified Auditing is used:\n To see if Oracle is configured to capture audit data including account\n termination, enter the following SQL*Plus command:\n SELECT ' Account termination 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 = 'DROP USER'\n and policy_name in (select policy_name from\n audit_unified_enabled_policies where user_name='ALL USERS'))) = 0\n OR (SELECT value\n FROM v$option\n WHERE parameter = 'Unified Auditing') != 'TRUE';\n\n If Oracle returns \"no rows selected\", this is not a finding.", - "fix": "Configure Oracle to audit account termination actions.\n\n If Standard Auditing is used:\n Use this process to ensure auditable events are captured:\n ALTER SYSTEM SET AUDIT_TRAIL= SCOPE=SPFILE;\n Audit trail type can be 'OS', 'DB', 'DB,EXTENDED', 'XML' or 'XML,EXTENDED'.\n After executing this statement, it may be necessary to shut down and restart\n the Oracle database.\n\n If Unified Auditing is used:\n To ensure auditable events are captured:\n Link the oracle binary with uniaud_on, and then restart the database. Oracle\n Database Upgrade Guide describes how to enable unified auditing. Reference\n V-61625 for information on how to configure a policy to audit account\n termination.\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 and verify the implementation of an audit trail\n retention policy.\n\n Verify that audit data is maintained for a minimum of one year.\n\n If audit data is not maintained for a minimum of one year, this is a finding.", + "fix": "Develop, document and implement an audit retention policy and\n procedures.\n\n It is recommended that the most recent thirty days of audit logs remain\n available online.\n\n After thirty days, the audit logs may be maintained off-line.\n\n Online maintenance provides for a more timely capability and inclination to\n investigate suspicious activity." }, - "code": "control 'V-61573' do\n title 'The DBMS must automatically audit account termination.'\n desc \"When application accounts are terminated, user accessibility is\n affected. Accounts are utilized for identifying individual application users\n or for identifying the application processes themselves.\n\n In order to detect and respond to events affecting user accessibility and\n application processing, applications must audit account terminating actions and\n notify the appropriate individuals so they can investigate the event. Such a\n capability greatly reduces the risk that application accessibility will be\n negatively affected for extended periods of time and provides logging that can\n be used for forensic purposes.\n\n Note that user authentication and account management should be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP.\n\n However, notwithstanding how accounts are managed, Oracle auditing should\n always be configured to capture account termination.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000029-DB-000188'\n tag \"gid\": 'V-61573'\n tag \"rid\": 'SV-76063r2_rule'\n tag \"stig_id\": 'O121-C2-002500'\n tag \"fix_id\": 'F-67489r2_fix'\n tag \"cci\": ['CCI-001405']\n tag \"nist\": ['AC-2 (4)', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Check Oracle settings (and also OS settings and/or\n enterprise-level authentication/access mechanisms settings) to determine if\n account termination actions are being audited. If account termination actions\n are not being audited by Oracle, this is a finding.\n\n If Standard Auditing is used:\n To see if Oracle is configured to capture audit data, enter the following\n SQL*Plus command:\n SHOW PARAMETER AUDIT_TRAIL\n or the following SQL query:\n SELECT * FROM SYS.V$PARAMETER WHERE NAME = 'audit_trail';\n If Oracle returns the value 'NONE', this is a finding.\n\n If Unified Auditing is used:\n To see if Oracle is configured to capture audit data including account\n termination, enter the following SQL*Plus command:\n SELECT ' Account termination 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 = 'DROP USER'\n and policy_name in (select policy_name from\n audit_unified_enabled_policies where user_name='ALL USERS'))) = 0\n OR (SELECT value\n FROM v$option\n WHERE parameter = 'Unified Auditing') != 'TRUE';\n\n If Oracle returns \\\"no rows selected\\\", this is not a finding.\"\n tag \"fix\": \"Configure Oracle to audit account termination actions.\n\n If Standard Auditing is used:\n Use this process to ensure auditable events are captured:\n ALTER SYSTEM SET AUDIT_TRAIL= SCOPE=SPFILE;\n Audit trail type can be 'OS', 'DB', 'DB,EXTENDED', 'XML' or 'XML,EXTENDED'.\n After executing this statement, it may be necessary to shut down and restart\n the Oracle database.\n\n If Unified Auditing is used:\n To ensure auditable events are captured:\n Link the oracle binary with uniaud_on, and then restart the database. Oracle\n Database Upgrade Guide describes how to enable unified auditing. Reference\n V-61625 for information on how to configure a policy to audit account\n termination.\n\n For more information on the configuration of auditing, refer to the following\n documents:\n \\\"Auditing Database Activity\\\" in the Oracle Database 2 Day + Security Guide:\n http://docs.oracle.com/database/121/TDPSG/tdpsg_auditing.htm#TDPSG50000\n \\\"Monitoring Database Activity with Auditing\\\" in the Oracle Database Security\n Guide:\n http://docs.oracle.com/database/121/DBSEG/part_6.htm#CCHEHCGI\n \\\"DBMS_AUDIT_MGMT\\\" in the Oracle Database PL/SQL Packages and Types Reference:\n http://docs.oracle.com/database/121/ARPLS/d_audit_mgmt.htm#ARPLS241\n Oracle Database Upgrade Guide:\n http://docs.oracle.com/database/121/UPGRD/afterup.htm#UPGRD52810\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n standard_auditing_used = input('standard_auditing_used')\n unified_auditing_used = input('unified_auditing_used')\n\n describe.one do\n describe 'Standard auditing is in use for audit purposes' do\n subject { standard_auditing_used }\n it { should be true }\n end\n\n describe 'Unified auditing is in use for audit purposes' do\n subject { unified_auditing_used }\n it { should be true }\n end\n end\n\n audit_trail = sql.query(\"select value from v$parameter where name = 'audit_trail';\").column('value')\n\n if standard_auditing_used\n describe 'The oracle database audit_trail parameter' do\n subject { audit_trail }\n it { should_not cmp 'NONE' }\n end\n end\n\n unified_auditing = sql.query(\"SELECT value FROM V$OPTION WHERE PARAMETER = 'Unified Auditing';\").column('value')\n\n if unified_auditing_used\n describe 'The oracle database unified auditing parameter' do\n subject { unified_auditing }\n it { should_not cmp 'FALSE' }\n end\n\n unified_auditing_events = sql.query(\"SELECT ' Account termination 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 = 'DROP USER'\n and policy_name in (select policy_name from\n audit_unified_enabled_policies where user_name='ALL USERS'))) = 0\n OR (SELECT value\n FROM v$option\n WHERE parameter = 'Unified Auditing') != 'TRUE';\").column('Account termination is not being audited').uniq\n\n describe 'The unified auditing data capture for account termination' do\n subject { unified_auditing_events.to_s }\n it { should_not cmp '[nil]' }\n end\n end\nend\n", + "code": "control 'V-61409' do\n title 'Audit trail data must be retained for at least one year.'\n desc \"Without preservation, a complete discovery of an attack or suspicious\n activity may not be determined. DBMS audit data also contributes to the\n complete investigation of unauthorized activity and needs to be included in\n audit retention plans and procedures.\"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000516-DB-999900'\n tag \"gid\": 'V-61409'\n tag \"rid\": 'SV-75899r1_rule'\n tag \"stig_id\": 'O121-BP-021100'\n tag \"fix_id\": 'F-67325r1_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 and verify the implementation of an audit trail\n retention policy.\n\n Verify that audit data is maintained for a minimum of one year.\n\n If audit data is not maintained for a minimum of one year, this is a finding.\"\n tag \"fix\": \"Develop, document and implement an audit retention policy and\n procedures.\n\n It is recommended that the most recent thirty days of audit logs remain\n available online.\n\n After thirty days, the audit logs may be maintained off-line.\n\n Online maintenance provides for a more timely capability and inclination to\n investigate suspicious activity.\"\n describe 'A manual review is required to ensure audit trail data is retained for at least one year' do\n skip 'A manual review is required to ensure audit trail data is retained for at least one year'\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61573.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61409.rb", "line": 1 }, - "id": "V-61573" + "id": "V-61409" }, { - "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": "The system must provide a real-time alert when organization-defined\n audit failure events occur.", + "desc": "It is critical for the appropriate personnel to be aware if a system\n is at risk of failing to process audit logs as required. Audit processing\n failures include: software/hardware errors, failures in the audit capturing\n mechanisms, and audit storage capacity being reached or exceeded.\n\n If audit log capacity were to be exceeded, then events subsequently\n occurring would not be recorded. Organizations shall define a maximum allowable\n percentage of storage capacity serving as an alarming threshold (e.g.,\n application has exceeded 80% of log storage capacity allocated) at which time\n the application or the logging mechanism the application utilizes will provide\n a warning to the appropriate personnel.\n\n A failure of database auditing will result in either the database\n continuing to function without auditing or in a complete halt to database\n operations. When audit processing fails, appropriate personnel must be alerted\n immediately to avoid further downtime or unaudited transactions. This can be\n an alert provided by the database, a log repository, or the OS when a\n designated log directory is nearing capacity.\n\n If Oracle Enterprise Manager is in use, the capability to issue such an\n alert is built in and configurable via the console so an alert can be sent to a\n designated administrator.", "descriptions": { - "default": "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": "It is critical for the appropriate personnel to be aware if a system\n is at risk of failing to process audit logs as required. Audit processing\n failures include: software/hardware errors, failures in the audit capturing\n mechanisms, and audit storage capacity being reached or exceeded.\n\n If audit log capacity were to be exceeded, then events subsequently\n occurring would not be recorded. Organizations shall define a maximum allowable\n percentage of storage capacity serving as an alarming threshold (e.g.,\n application has exceeded 80% of log storage capacity allocated) at which time\n the application or the logging mechanism the application utilizes will provide\n a warning to the appropriate personnel.\n\n A failure of database auditing will result in either the database\n continuing to function without auditing or in a complete halt to database\n operations. When audit processing fails, appropriate personnel must be alerted\n immediately to avoid further downtime or unaudited transactions. This can be\n an alert provided by the database, a log repository, or the OS when a\n designated log directory is nearing capacity.\n\n If Oracle Enterprise Manager is in use, the capability to issue such an\n alert is built in and configurable via the console so an alert can be sent to a\n designated administrator." }, "impact": 0.5, "refs": [], "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-000104-DB-000051", + "gid": "V-61645", + "rid": "SV-76135r2_rule", + "stig_id": "O121-C2-008300", + "fix_id": "F-67559r3_fix", "cci": [ - "CCI-000366", - "CCI-002220" + "CCI-001858" ], "nist": [ - "AC-5 c", + "AU-5 (2)", "Rev_4" ], "false_negatives": null, @@ -2132,30 +2211,30 @@ "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": "Review Oracle Corp., OS, or third-party logging software\n settings to determine whether a real-time alert will be sent to the appropriate\n personnel when auditing fails for any reason.\n\n If real-time alerts are not sent upon auditing failure, this is a finding.", + "fix": "Configure logging software to send a real-time alert to\n appropriate personnel when auditing fails for any reason.\n\n (Oracle recommends the use of Oracle Enterprise Manager.)" }, - "code": "control 'V-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-61645' do\n title \"The system must provide a real-time alert when organization-defined\n audit failure events occur.\"\n desc \"It is critical for the appropriate personnel to be aware if a system\n is at risk of failing to process audit logs as required. Audit processing\n failures include: software/hardware errors, failures in the audit capturing\n mechanisms, and audit storage capacity being reached or exceeded.\n\n If audit log capacity were to be exceeded, then events subsequently\n occurring would not be recorded. Organizations shall define a maximum allowable\n percentage of storage capacity serving as an alarming threshold (e.g.,\n application has exceeded 80% of log storage capacity allocated) at which time\n the application or the logging mechanism the application utilizes will provide\n a warning to the appropriate personnel.\n\n A failure of database auditing will result in either the database\n continuing to function without auditing or in a complete halt to database\n operations. When audit processing fails, appropriate personnel must be alerted\n immediately to avoid further downtime or unaudited transactions. This can be\n an alert provided by the database, a log repository, or the OS when a\n designated log directory is nearing capacity.\n\n If Oracle Enterprise Manager is in use, the capability to issue such an\n alert is built in and configurable via the console so an alert can be sent to a\n designated administrator.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000104-DB-000051'\n tag \"gid\": 'V-61645'\n tag \"rid\": 'SV-76135r2_rule'\n tag \"stig_id\": 'O121-C2-008300'\n tag \"fix_id\": 'F-67559r3_fix'\n tag \"cci\": ['CCI-001858']\n tag \"nist\": ['AU-5 (2)', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Review Oracle Corp., OS, or third-party logging software\n settings to determine whether a real-time alert will be sent to the appropriate\n personnel when auditing fails for any reason.\n\n If real-time alerts are not sent upon auditing failure, this is a finding.\"\n tag \"fix\": \"Configure logging software to send a real-time alert to\n appropriate personnel when auditing fails for any reason.\n\n (Oracle recommends the use of Oracle Enterprise Manager.)\"\n describe 'A manual review is required to ensure the system provides a real-time alert when organization-defined\n audit failure events occur' do\n skip 'A manual review is required to ensure the system provides a real-time alert when organization-defined\n audit failure events occur'\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61587.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61645.rb", "line": 1 }, - "id": "V-61587" + "id": "V-61645" }, { - "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": "Application object owner accounts must be disabled when not performing\n installation or maintenance actions.", + "desc": "Object ownership provides all database object permissions to the owned\n object. Access to the application object owner accounts requires special\n protection to prevent unauthorized access and use of the object ownership\n privileges. In addition to the high privileges to application objects assigned\n to this account, it is also an account that, by definition, is not accessed\n interactively except for application installation and maintenance. This reduced\n access to the account means that unauthorized access to the account could go\n undetected. To help protect the account, it must be enabled only when access is\n required.", "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": "Object ownership provides all database object permissions to the owned\n object. Access to the application object owner accounts requires special\n protection to prevent unauthorized access and use of the object ownership\n privileges. In addition to the high privileges to application objects assigned\n to this account, it is also an account that, by definition, is not accessed\n interactively except for application installation and maintenance. This reduced\n access to the account means that unauthorized access to the account could go\n undetected. To help protect the account, it must be enabled only when access is\n required." }, "impact": 0, "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-61467", + "rid": "SV-75957r4_rule", + "stig_id": "O121-BP-024000", + "fix_id": "F-67383r1_fix", "cci": [ "CCI-000366" ], @@ -2173,35 +2252,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": "Run the SQL query:\n\n select distinct o.owner from dba_objects o, dba_users u\n where o.owner not in\n (\n \n )\n and o.object_type <> 'SYNONYM'\n and o.owner = username\n and upper(account_status) not like '%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 To obtain a list of users assigned DBA privileges, run the query:\n\n select grantee from dba_role_privs where granted_role = 'DBA';\n\n If any records are returned, then verify the account is an authorized\n application object owner account or a default account installed to support an\n Oracle product.\n\n Verify that any objects owned by custom DBA accounts are for the personal use\n of that DBA.\n\n If any objects are used to support applications or any functions other than DBA\n functions, this is a finding.\n\n Any unauthorized object owner accounts are not a finding under this check as\n they are noted as findings under check O121-C2-011000.\n\n Any other accounts listed are a finding.", + "fix": "Disable any application object owner accounts.\n\n From SQL*Plus:\n alter user [username] account lock;\n\n Enable application object owner accounts only for installation and maintenance.\n\n DBAs are special purpose accounts and do not require disabling although they\n may own objects.\n\n For application objects that require routine maintenance, e.g. index objects,\n to maintain performance, consider allowing a special purpose account to own the\n index or enable the application owner account for the duration of the routine\n maintenance function only." }, - "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-61467' do\n title \"Application object owner accounts must be disabled when not performing\n installation or maintenance actions.\"\n desc \"Object ownership provides all database object permissions to the owned\n object. Access to the application object owner accounts requires special\n protection to prevent unauthorized access and use of the object ownership\n privileges. In addition to the high privileges to application objects assigned\n to this account, it is also an account that, by definition, is not accessed\n interactively except for application installation and maintenance. This reduced\n access to the account means that unauthorized access to the account could go\n undetected. To help protect the account, it must be enabled only when access is\n required.\"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000516-DB-999900'\n tag \"gid\": 'V-61467'\n tag \"rid\": 'SV-75957r4_rule'\n tag \"stig_id\": 'O121-BP-024000'\n tag \"fix_id\": 'F-67383r1_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 distinct o.owner from dba_objects o, dba_users u\n where o.owner not in\n (\n \n )\n and o.object_type <> 'SYNONYM'\n and o.owner = username\n and upper(account_status) not like '%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 To obtain a list of users assigned DBA privileges, run the query:\n\n select grantee from dba_role_privs where granted_role = 'DBA';\n\n If any records are returned, then verify the account is an authorized\n application object owner account or a default account installed to support an\n Oracle product.\n\n Verify that any objects owned by custom DBA accounts are for the personal use\n of that DBA.\n\n If any objects are used to support applications or any functions other than DBA\n functions, this is a finding.\n\n Any unauthorized object owner accounts are not a finding under this check as\n they are noted as findings under check O121-C2-011000.\n\n Any other accounts listed are a finding.\"\n tag \"fix\": \"Disable any application object owner accounts.\n\n From SQL*Plus:\n alter user [username] account lock;\n\n Enable application object owner accounts only for installation and maintenance.\n\n DBAs are special purpose accounts and do not require disabling although they\n may own objects.\n\n For application objects that require routine maintenance, e.g. index objects,\n to maintain performance, consider allowing a special purpose account to own the\n index or enable the application owner account for the duration of the routine\n maintenance function only.\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n dba_users = sql.query(\"select grantee from dba_sys_privs\n where admin_option = 'YES' and grantee not in (select grantee from dba_role_privs where granted_role = 'DBA');\").column('grantee').uniq\n if dba_users.empty?\n impact 0.0\n describe 'There are no oracle DBA users, control N/A' do\n skip 'There are no oracle DBA users, control N/A'\n end\n else\n dba_users.each do |user|\n describe \"oracle DBA users: #{user}\" do\n subject { user }\n it { should be_in input('allowed_dbadmin_users') }\n end\n end\n end\n\n unlocked_accounts = sql.query(\"select distinct o.owner from dba_objects o, dba_users u\n where\n o.object_type <> 'SYNONYM'\n and o.owner = username\n and upper(account_status) not like '%LOCKED%';\").column('owner').uniq\n if unlocked_accounts.empty?\n impact 0.0\n describe 'There are no unlocked oracle accounts, control N/A' do\n skip 'There are no unlocked oracle accounts, control N/A'\n end\n else\n unlocked_accounts.each do |user|\n describe \"oracle user: #{user}\" do\n subject { user }\n it { should be_in input('allowed_unlocked_oracledb_accounts') }\n end\n end\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61445.rb", - "line": 3 + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61467.rb", + "line": 1 }, - "id": "V-61445" + "id": "V-61467" }, { - "title": "Replication accounts must not be granted DBA privileges.", - "desc": "Replication accounts may be used to access databases defined for the\n replication architecture. An exploit of a replication on one database could\n lead to the compromise of any database participating in the replication that\n uses the same account name and credentials. If the replication account is\n compromised and it has DBA privileges, the database is at additional risk to\n unauthorized or malicious action.", + "title": "The DBMS software libraries must be periodically backed up.", + "desc": "Information system backup is a critical step in maintaining data\n assurance and availability.\n\n System-level information includes: system-state information, operating\n system and application software, and licenses.\n\n Backups shall be consistent with organizational recovery time and recovery\n point objectives.\n\n The DBMS application depends upon the availability and integrity of its\n software libraries. Without backups, compromise or loss of the software\n libraries can prevent a successful recovery of DBMS operations.", "descriptions": { - "default": "Replication accounts may be used to access databases defined for the\n replication architecture. An exploit of a replication on one database could\n lead to the compromise of any database participating in the replication that\n uses the same account name and credentials. If the replication account is\n compromised and it has DBA privileges, the database is at additional risk to\n unauthorized or malicious action." + "default": "Information system backup is a critical step in maintaining data\n assurance and availability.\n\n System-level information includes: system-state information, operating\n system and application software, and licenses.\n\n Backups shall be consistent with organizational recovery time and recovery\n point objectives.\n\n The DBMS application depends upon the availability and integrity of its\n software libraries. Without backups, compromise or loss of the software\n libraries can prevent a successful recovery of DBMS operations." }, "impact": 0.5, "refs": [], "tags": { - "gtitle": "SRG-APP-000516-DB-999900", - "gid": "V-61513", - "rid": "SV-76003r1_rule", - "stig_id": "O121-BP-025500", - "fix_id": "F-67429r1_fix", + "gtitle": "SRG-APP-000146-DB-000100", + "gid": "V-61877", + "rid": "SV-76367r1_rule", + "stig_id": "O121-P2-012700", + "fix_id": "F-67793r1_fix", "cci": [ - "CCI-000366" + "CCI-000537" ], "nist": [ - "CM-6 b", + "CP-9 (b)", "Rev_4" ], "false_negatives": null, @@ -2214,35 +2293,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "If a review of the System Security Plan confirms the use of\n replication is not required, not permitted and the database is not configured\n for replication, this check is not a finding.\n\n If any replication accounts are assigned DBA roles or roles with DBA\n privileges, this is a finding.", - "fix": "Restrict privileges assigned to replication accounts to the\n fewest possible privileges.\n\n Remove DBA roles from replication accounts.\n\n Create and use custom replication accounts assigned least privileges for\n supporting replication operations." + "check": "Review evidence of inclusion of the DBMS libraries in current\n backup records.\n\n If any DBMS library files are not included in regular backups, this is a\n finding.", + "fix": "Configure backups to include all DBMS application and third-party\n database application software libraries." }, - "code": "control 'V-61513' do\n title 'Replication accounts must not be granted DBA privileges.'\n desc \"Replication accounts may be used to access databases defined for the\n replication architecture. An exploit of a replication on one database could\n lead to the compromise of any database participating in the replication that\n uses the same account name and credentials. If the replication account is\n compromised and it has DBA privileges, the database is at additional risk to\n unauthorized or malicious action.\"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000516-DB-999900'\n tag \"gid\": 'V-61513'\n tag \"rid\": 'SV-76003r1_rule'\n tag \"stig_id\": 'O121-BP-025500'\n tag \"fix_id\": 'F-67429r1_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 a review of the System Security Plan confirms the use of\n replication is not required, not permitted and the database is not configured\n for replication, this check is not a finding.\n\n If any replication accounts are assigned DBA roles or roles with DBA\n privileges, this is a finding.\"\n tag \"fix\": \"Restrict privileges assigned to replication accounts to the\n fewest possible privileges.\n\n Remove DBA roles from replication accounts.\n\n Create and use custom replication accounts assigned least privileges for\n supporting replication operations.\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n is_oracle_replication_used = sql.query(\"select count(*) from all_tables\n where table_name like 'REPCAT%';\").column('count(*)')\n\n oracle_replication_accounts = sql.query('select * from sys.dba_repcatlog;').column('gname')\n\n if !is_oracle_replication_used.include?('0')\n describe \"The ISSO or DBA must manually ensure the following replication accounts are justified and are not granted DBA privileges: #{oracle_replication_accounts}\" do\n skip \"The ISSO or DBA must manually ensure the following replication accounts are justified and are not granted DBA privileges: #{oracle_replication_accounts}\"\n end\n else\n describe 'The number of replication accounts defined' do\n subject { is_oracle_replication_used }\n it { should cmp 0 }\n end\n end\nend\n", + "code": "control 'V-61877' do\n title 'The DBMS software libraries must be periodically backed up.'\n desc \"Information system backup is a critical step in maintaining data\n assurance and availability.\n\n System-level information includes: system-state information, operating\n system and application software, and licenses.\n\n Backups shall be consistent with organizational recovery time and recovery\n point objectives.\n\n The DBMS application depends upon the availability and integrity of its\n software libraries. Without backups, compromise or loss of the software\n libraries can prevent a successful recovery of DBMS operations.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000146-DB-000100'\n tag \"gid\": 'V-61877'\n tag \"rid\": 'SV-76367r1_rule'\n tag \"stig_id\": 'O121-P2-012700'\n tag \"fix_id\": 'F-67793r1_fix'\n tag \"cci\": ['CCI-000537']\n tag \"nist\": ['CP-9 (b)', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Review evidence of inclusion of the DBMS libraries in current\n backup records.\n\n If any DBMS library files are not included in regular backups, this is a\n finding.\"\n tag \"fix\": \"Configure backups to include all DBMS application and third-party\n database application software libraries.\"\n describe 'A manual review is required to ensure the DBMS software libraries are periodically backed up' do\n skip 'A manual review is required to ensure the DBMS software libraries are periodically backed up'\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61513.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61877.rb", "line": 1 }, - "id": "V-61513" + "id": "V-61877" }, { - "title": "Databases employed to write data to portable digital media must use\n cryptographic mechanisms to protect and restrict access to information on\n portable digital media.", - "desc": "When data is written to portable digital media, such as thumb drives,\n floppy diskettes, compact disks, magnetic tape, etc., there is risk of data\n loss.\n\n An organizational assessment of risk guides the selection of media and\n associated information contained on that media requiring restricted access.\n\n Organizations need to document in policy and procedures the media requiring\n restricted access, individuals authorized to access the media, and the specific\n measures taken to restrict access. Fewer protection measures are needed for\n media containing information determined by the organization to be in the public\n domain, to be publicly releasable, or to have limited or no adverse impact if\n accessed by other than authorized personnel.\n\n In these situations, it is assumed the physical access controls where the\n media resides provide adequate protection. The decision whether to employ\n cryptography is the responsibility of the information owner/steward, who\n exercises discretion within the framework of applicable rules, policies, and\n law.\n\n The selection of the cryptographic mechanisms used is based upon\n maintaining the confidentiality and integrity of the information.\n\n The strength of mechanisms is commensurate with the classification and\n sensitivity of the information.\n\n When the organization has determined the risk warrants it, data written to\n portable digital media must be encrypted. When information written to digital\n media is not encrypted, it can be compromised.", + "title": "The DBMS must protect against an individual who uses a shared account\n falsely denying having performed a particular action.", + "desc": "Non-repudiation of actions taken is required in order to maintain\n application integrity. Examples of particular actions taken by individuals\n include creating information, sending a message, approving information (e.g.,\n indicating concurrence or signing a contract), and receiving a message.\n\n Non-repudiation protects individuals against later claims by an author of\n not having authored a particular document, a sender of not having transmitted a\n message, a receiver of not having received a message, or a signatory of not\n having signed a document.\n\n Authentication via shared accounts does not provide individual\n accountability for actions taken on the DBMS or data. Whenever a single\n database account is used to connect to the database, a secondary authentication\n method that provides individual accountability is required. This scenario most\n frequently occurs when an externally hosted application authenticates\n individual users to the application and the application uses a single account\n to retrieve or update database information on behalf of the individual users.\n\n When shared accounts are utilized without another means of identifying\n individual users, users may deny having performed a particular action.\n\n This calls for inspection of application source code, which will require\n collaboration with the application developers. It is recognized that in many\n cases, the database administrator (DBA) is organizationally separate from the\n application developers and may have limited, if any, access to source code.\n Nevertheless, protections of this type are so important to the secure operation\n of databases that they must not be ignored. At a minimum, the DBA must attempt\n to obtain assurances from the development organization that this issue has been\n addressed and must document what has been discovered.", "descriptions": { - "default": "When data is written to portable digital media, such as thumb drives,\n floppy diskettes, compact disks, magnetic tape, etc., there is risk of data\n loss.\n\n An organizational assessment of risk guides the selection of media and\n associated information contained on that media requiring restricted access.\n\n Organizations need to document in policy and procedures the media requiring\n restricted access, individuals authorized to access the media, and the specific\n measures taken to restrict access. Fewer protection measures are needed for\n media containing information determined by the organization to be in the public\n domain, to be publicly releasable, or to have limited or no adverse impact if\n accessed by other than authorized personnel.\n\n In these situations, it is assumed the physical access controls where the\n media resides provide adequate protection. The decision whether to employ\n cryptography is the responsibility of the information owner/steward, who\n exercises discretion within the framework of applicable rules, policies, and\n law.\n\n The selection of the cryptographic mechanisms used is based upon\n maintaining the confidentiality and integrity of the information.\n\n The strength of mechanisms is commensurate with the classification and\n sensitivity of the information.\n\n When the organization has determined the risk warrants it, data written to\n portable digital media must be encrypted. When information written to digital\n media is not encrypted, it can be compromised." + "default": "Non-repudiation of actions taken is required in order to maintain\n application integrity. Examples of particular actions taken by individuals\n include creating information, sending a message, approving information (e.g.,\n indicating concurrence or signing a contract), and receiving a message.\n\n Non-repudiation protects individuals against later claims by an author of\n not having authored a particular document, a sender of not having transmitted a\n message, a receiver of not having received a message, or a signatory of not\n having signed a document.\n\n Authentication via shared accounts does not provide individual\n accountability for actions taken on the DBMS or data. Whenever a single\n database account is used to connect to the database, a secondary authentication\n method that provides individual accountability is required. This scenario most\n frequently occurs when an externally hosted application authenticates\n individual users to the application and the application uses a single account\n to retrieve or update database information on behalf of the individual users.\n\n When shared accounts are utilized without another means of identifying\n individual users, users may deny having performed a particular action.\n\n This calls for inspection of application source code, which will require\n collaboration with the application developers. It is recognized that in many\n cases, the database administrator (DBA) is organizationally separate from the\n application developers and may have limited, if any, access to source code.\n Nevertheless, protections of this type are so important to the secure operation\n of databases that they must not be ignored. At a minimum, the DBA must attempt\n to obtain assurances from the development organization that this issue has been\n addressed and must document what has been discovered." }, - "impact": 0.5, + "impact": 0.3, "refs": [], "tags": { - "gtitle": "SRG-APP-000187-DB-000120", - "gid": "V-61753", - "rid": "SV-76243r2_rule", - "stig_id": "O121-C2-016300", - "fix_id": "F-67669r1_fix", + "gtitle": "SRG-APP-000080-DB-000063", + "gid": "V-61887", + "rid": "SV-76377r2_rule", + "stig_id": "O121-P3-006200", + "fix_id": "F-67803r2_fix", "cci": [ - "CCI-000366" + "CCI-000166" ], "nist": [ - "CM-6 b", + "AU-10", "Rev_4" ], "false_negatives": null, @@ -2255,35 +2334,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "If data is written to portable media, the data must be\n protected and access restricted via cryptographic mechanisms.\n\n Review system documentation and interview DBA to determine whether data is ever\n written directly from Oracle to portable media.\n\n If this is the case, and cryptographic mechanisms are not used to protect data\n written to portable media, this is a finding.\n\n If all data writing from Oracle to portable media is done via intermediate\n files, pipes, or other non-portable resources under the control of the\n operating system, then this is not a finding with respect to Oracle. (Note,\n however, that if encryption is not in use, it may be a finding with respect to\n the OS or the application that is used to perform the data transfer.)", - "fix": "Reconfigure processes that write to portable digital media so\n that they use cryptographic mechanisms to restrict access and protect the\n information." + "check": "If there are no shared accounts available to more than one\n user, this is not a finding.\n\n If a shared account is used by an application to interact with the database,\n review the System Security Plan, the tables in the database, and the\n application source code/documentation to determine whether the application\n captures the individual user's identity and stores that identity along with all\n data inserted and updated (also with all records of reads and/or deletions, if\n these are required to be logged).\n\n If there are gaps in the application's ability to do this, and the gaps and the\n risk are not defined in the system documentation and accepted by the AO, this\n is a finding.\n\n If users are sharing a group account to log on to Oracle tools or third-party\n products that access the database, this is a finding.\n\n If Standard Auditing is used:\n To ensure that user activities other than SELECT, INSERT, UPDATE, and DELETE\n are also monitored and attributed to individuals, verify that Oracle auditing\n is enabled. To see if Oracle is configured to capture audit data, enter the\n following SQL*Plus command:\n SHOW PARAMETER AUDIT_TRAIL\n or the following SQL query:\n SELECT * FROM SYS.V$PARAMETER WHERE NAME = 'audit_trail';\n If Oracle returns the value 'NONE', this is a finding.\n\n If Unified Auditing is used:\n To ensure that user activities other than SELECT, INSERT, UPDATE, and DELETE\n are also monitored and attributed to individuals, verify that Oracle auditing\n is enabled. To see if Oracle is configured to capture audit data, enter the\n following SQL*Plus command:\n SELECT * FROM V$OPTION WHERE PARAMETER = 'Unified Auditing';\n If Oracle returns the value \"TRUE\", this is not a finding.", + "fix": "Use accounts assigned to individual users where feasible.\n Configure DBMS to provide individual accountability at the DBMS level, and in\n audit logs, for actions performed under a shared database account.\n\n Modify applications and data tables that are not capturing individual user\n identity to do so.\n\n Create and enforce the use of individual user IDs for logging on to Oracle\n tools and third-party products.\n\n If Oracle auditing is not already enabled, enable it.\n\n If Standard Auditing is used:\n If Oracle (or third-party) auditing is not already enabled, enable it. For\n Oracle auditing, use this query:\n ALTER SYSTEM SET AUDIT_TRAIL= SCOPE=SPFILE;\n Audit trail type can be 'OS', 'DB', 'DB,EXTENDED', 'XML' or 'XML,EXTENDED'.\n After executing this statement, it may be necessary to shut down and restart\n the Oracle database.\n\n If Unified Auditing is used:\n Link the oracle binary with uniaud_on, and then restart the database. Oracle\n Database Upgrade Guide describes how to enable unified auditing.\n\n For more information on the configuration of auditing, refer to the following\n documents:\n \"Auditing Database Activity\" in the Oracle Database 2 Day + Security Guide:\n http://docs.oracle.com/database/121/TDPSG/tdpsg_auditing.htm#TDPSG50000\n \"Monitoring Database Activity with Auditing\" in the Oracle Database Security\n Guide:\n http://docs.oracle.com/database/121/DBSEG/part_6.htm#CCHEHCGI\n \"DBMS_AUDIT_MGMT\" in the Oracle Database PL/SQL Packages and Types Reference:\n http://docs.oracle.com/database/121/ARPLS/d_audit_mgmt.htm#ARPLS241\n Oracle Database Upgrade Guide:\n http://docs.oracle.com/database/121/UPGRD/afterup.htm#UPGRD52810\n\n If the site-specific audit requirements are not covered by the default audit\n options, deploy and configure Fine-Grained Auditing. For details, refer to\n Oracle documentation at the locations above.\n\n If this level of auditing does not meet site-specific requirements, consider\n deploying the Oracle Audit Vault. The Audit Vault is a highly configurable\n option from Oracle made specifically for performing the audit functions. It\n has reporting capabilities as well as user-defined rules that provide\n additional flexibility for complex auditing requirements." }, - "code": "control 'V-61753' do\n title \"Databases employed to write data to portable digital media must use\n cryptographic mechanisms to protect and restrict access to information on\n portable digital media.\"\n desc \"When data is written to portable digital media, such as thumb drives,\n floppy diskettes, compact disks, magnetic tape, etc., there is risk of data\n loss.\n\n An organizational assessment of risk guides the selection of media and\n associated information contained on that media requiring restricted access.\n\n Organizations need to document in policy and procedures the media requiring\n restricted access, individuals authorized to access the media, and the specific\n measures taken to restrict access. Fewer protection measures are needed for\n media containing information determined by the organization to be in the public\n domain, to be publicly releasable, or to have limited or no adverse impact if\n accessed by other than authorized personnel.\n\n In these situations, it is assumed the physical access controls where the\n media resides provide adequate protection. The decision whether to employ\n cryptography is the responsibility of the information owner/steward, who\n exercises discretion within the framework of applicable rules, policies, and\n law.\n\n The selection of the cryptographic mechanisms used is based upon\n maintaining the confidentiality and integrity of the information.\n\n The strength of mechanisms is commensurate with the classification and\n sensitivity of the information.\n\n When the organization has determined the risk warrants it, data written to\n portable digital media must be encrypted. When information written to digital\n media is not encrypted, it can be compromised.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000187-DB-000120'\n tag \"gid\": 'V-61753'\n tag \"rid\": 'SV-76243r2_rule'\n tag \"stig_id\": 'O121-C2-016300'\n tag \"fix_id\": 'F-67669r1_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 data is written to portable media, the data must be\n protected and access restricted via cryptographic mechanisms.\n\n Review system documentation and interview DBA to determine whether data is ever\n written directly from Oracle to portable media.\n\n If this is the case, and cryptographic mechanisms are not used to protect data\n written to portable media, this is a finding.\n\n If all data writing from Oracle to portable media is done via intermediate\n files, pipes, or other non-portable resources under the control of the\n operating system, then this is not a finding with respect to Oracle. (Note,\n however, that if encryption is not in use, it may be a finding with respect to\n the OS or the application that is used to perform the data transfer.)\"\n tag \"fix\": \"Reconfigure processes that write to portable digital media so\n that they use cryptographic mechanisms to restrict access and protect the\n information.\"\n describe 'A manual review is required to ensure databases employed to write data to portable digital media use\n cryptographic mechanisms to protect and restrict access to information on\n portable digital media' do\n skip 'A manual review is required to ensure databases employed to write data to portable digital media use\n cryptographic mechanisms to protect and restrict access to information on\n portable digital media'\n end\nend\n", + "code": "control 'V-61887' do\n title \"The DBMS must protect against an individual who uses a shared account\n falsely denying having performed a particular action.\"\n desc \"Non-repudiation of actions taken is required in order to maintain\n application integrity. Examples of particular actions taken by individuals\n include creating information, sending a message, approving information (e.g.,\n indicating concurrence or signing a contract), and receiving a message.\n\n Non-repudiation protects individuals against later claims by an author of\n not having authored a particular document, a sender of not having transmitted a\n message, a receiver of not having received a message, or a signatory of not\n having signed a document.\n\n Authentication via shared accounts does not provide individual\n accountability for actions taken on the DBMS or data. Whenever a single\n database account is used to connect to the database, a secondary authentication\n method that provides individual accountability is required. This scenario most\n frequently occurs when an externally hosted application authenticates\n individual users to the application and the application uses a single account\n to retrieve or update database information on behalf of the individual users.\n\n When shared accounts are utilized without another means of identifying\n individual users, users may deny having performed a particular action.\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.3\n tag \"gtitle\": 'SRG-APP-000080-DB-000063'\n tag \"gid\": 'V-61887'\n tag \"rid\": 'SV-76377r2_rule'\n tag \"stig_id\": 'O121-P3-006200'\n tag \"fix_id\": 'F-67803r2_fix'\n tag \"cci\": ['CCI-000166']\n tag \"nist\": ['AU-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\": \"If there are no shared accounts available to more than one\n user, this is not a finding.\n\n If a shared account is used by an application to interact with the database,\n review the System Security Plan, the tables in the database, and the\n application source code/documentation to determine whether the application\n captures the individual user's identity and stores that identity along with all\n data inserted and updated (also with all records of reads and/or deletions, if\n these are required to be logged).\n\n If there are gaps in the application's ability to do this, and the gaps and the\n risk are not defined in the system documentation and accepted by the AO, this\n is a finding.\n\n If users are sharing a group account to log on to Oracle tools or third-party\n products that access the database, this is a finding.\n\n If Standard Auditing is used:\n To ensure that user activities other than SELECT, INSERT, UPDATE, and DELETE\n are also monitored and attributed to individuals, verify that Oracle auditing\n is enabled. To see if Oracle is configured to capture audit data, enter the\n following SQL*Plus command:\n SHOW PARAMETER AUDIT_TRAIL\n or the following SQL query:\n SELECT * FROM SYS.V$PARAMETER WHERE NAME = 'audit_trail';\n If Oracle returns the value 'NONE', this is a finding.\n\n If Unified Auditing is used:\n To ensure that user activities other than SELECT, INSERT, UPDATE, and DELETE\n are also monitored and attributed to individuals, verify that Oracle auditing\n is enabled. To see if Oracle is configured to capture audit data, enter the\n following SQL*Plus command:\n SELECT * FROM V$OPTION WHERE PARAMETER = 'Unified Auditing';\n If Oracle returns the value \\\"TRUE\\\", this is not a finding.\"\n tag \"fix\": \"Use accounts assigned to individual users where feasible.\n Configure DBMS to provide individual accountability at the DBMS level, and in\n audit logs, for actions performed under a shared database account.\n\n Modify applications and data tables that are not capturing individual user\n identity to do so.\n\n Create and enforce the use of individual user IDs for logging on to Oracle\n tools and third-party products.\n\n If Oracle auditing is not already enabled, enable it.\n\n If Standard Auditing is used:\n If Oracle (or third-party) auditing is not already enabled, enable it. For\n Oracle auditing, use this query:\n ALTER SYSTEM SET AUDIT_TRAIL= SCOPE=SPFILE;\n Audit trail type can be 'OS', 'DB', 'DB,EXTENDED', 'XML' or 'XML,EXTENDED'.\n After executing this statement, it may be necessary to shut down and restart\n the Oracle database.\n\n If Unified Auditing is used:\n Link the oracle binary with uniaud_on, and then restart the database. Oracle\n Database Upgrade Guide describes how to enable unified auditing.\n\n For more information on the configuration of auditing, refer to the following\n documents:\n \\\"Auditing Database Activity\\\" in the Oracle Database 2 Day + Security Guide:\n http://docs.oracle.com/database/121/TDPSG/tdpsg_auditing.htm#TDPSG50000\n \\\"Monitoring Database Activity with Auditing\\\" in the Oracle Database Security\n Guide:\n http://docs.oracle.com/database/121/DBSEG/part_6.htm#CCHEHCGI\n \\\"DBMS_AUDIT_MGMT\\\" in the Oracle Database PL/SQL Packages and Types Reference:\n http://docs.oracle.com/database/121/ARPLS/d_audit_mgmt.htm#ARPLS241\n Oracle Database Upgrade Guide:\n http://docs.oracle.com/database/121/UPGRD/afterup.htm#UPGRD52810\n\n If the site-specific audit requirements are not covered by the default audit\n options, deploy and configure Fine-Grained Auditing. For details, refer to\n Oracle documentation at the locations above.\n\n If this level of auditing does not meet site-specific requirements, consider\n deploying the Oracle Audit Vault. The Audit Vault is a highly configurable\n option from Oracle made specifically for performing the audit functions. It\n has reporting capabilities as well as user-defined rules that provide\n additional flexibility for complex auditing requirements.\"\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 end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61753.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61887.rb", "line": 1 }, - "id": "V-61753" + "id": "V-61887" }, { - "title": "The OS must limit privileges to change the DBMS software resident\n within software libraries (including privileged programs).", - "desc": "When dealing with change control issues, it should be noted, any\n changes to the hardware, software, and/or firmware components of the\n information system and/or application can potentially have significant effects\n on the overall security of the system.\n\n If the application were to allow any user to make changes to software\n libraries, then those changes might be implemented without undergoing the\n appropriate testing and approvals that are part of a robust change management\n process.\n\n This requirement is contingent upon the language in which the application\n is programmed, as many application architectures in use today incorporate their\n software libraries into, and make them inseparable from, their compiled\n distributions, rendering them static and version-dependent. However, this\n requirement does apply to applications with software libraries accessible and\n configurable as in the case of interpreted languages.\n\n Accordingly, only qualified and authorized individuals shall be allowed to\n obtain access to information system components for purposes of initiating\n changes, including upgrades and modifications.\n\n The DBMS software libraries contain the executables used by the DBMS to\n operate. Unauthorized access to the libraries can result in malicious\n alteration. This may in turn jeopardize data stored in the DBMS and/or\n operation of the host system.", + "title": "The Oracle SQL92_SECURITY parameter must be set to TRUE.", + "desc": "The configuration option SQL92_SECURITY specifies whether table-level\n SELECT privileges are required to execute an update or delete that references\n table column values. If this option is disabled (set to FALSE), the UPDATE\n privilege can be used to determine values that should require SELECT privileges.\n\n The SQL92_SECURITY setting of TRUE prevents the exploitation of user\n credentials with only DELETE or UPDATE privileges on a table from being able to\n derive column values in that table by performing a series of update/delete\n statements using a where clause, and rolling back the change. In the following\n example, with SQL92_SECURITY set to FALSE, a user with only delete privilege on\n the scott.emp table is able to derive that there is one employee with a salary\n greater than 3000. With SQL92_SECURITY set to TRUE, that user is prevented from\n attempting to derive a value.\n\n SQL92_SECURITY = FALSE\n SQL> delete from scott.emp where sal > 3000;\n 1 row deleted\n SQL> rollback;\n Rollback complete\n\n SQL92_SECURITY = TRUE\n SQL> delete from scott.emp where sal > 3000;\n delete from scott.emp where sal > 3000\n *\n ERROR at line 1:\n ORA-01031: insufficient privileges", "descriptions": { - "default": "When dealing with change control issues, it should be noted, any\n changes to the hardware, software, and/or firmware components of the\n information system and/or application can potentially have significant effects\n on the overall security of the system.\n\n If the application were to allow any user to make changes to software\n libraries, then those changes might be implemented without undergoing the\n appropriate testing and approvals that are part of a robust change management\n process.\n\n This requirement is contingent upon the language in which the application\n is programmed, as many application architectures in use today incorporate their\n software libraries into, and make them inseparable from, their compiled\n distributions, rendering them static and version-dependent. However, this\n requirement does apply to applications with software libraries accessible and\n configurable as in the case of interpreted languages.\n\n Accordingly, only qualified and authorized individuals shall be allowed to\n obtain access to information system components for purposes of initiating\n changes, including upgrades and modifications.\n\n The DBMS software libraries contain the executables used by the DBMS to\n operate. Unauthorized access to the libraries can result in malicious\n alteration. This may in turn jeopardize data stored in the DBMS and/or\n operation of the host system." + "default": "The configuration option SQL92_SECURITY specifies whether table-level\n SELECT privileges are required to execute an update or delete that references\n table column values. If this option is disabled (set to FALSE), the UPDATE\n privilege can be used to determine values that should require SELECT privileges.\n\n The SQL92_SECURITY setting of TRUE prevents the exploitation of user\n credentials with only DELETE or UPDATE privileges on a table from being able to\n derive column values in that table by performing a series of update/delete\n statements using a where clause, and rolling back the change. In the following\n example, with SQL92_SECURITY set to FALSE, a user with only delete privilege on\n the scott.emp table is able to derive that there is one employee with a salary\n greater than 3000. With SQL92_SECURITY set to TRUE, that user is prevented from\n attempting to derive a value.\n\n SQL92_SECURITY = FALSE\n SQL> delete from scott.emp where sal > 3000;\n 1 row deleted\n SQL> rollback;\n Rollback complete\n\n SQL92_SECURITY = TRUE\n SQL> delete from scott.emp where sal > 3000;\n delete from scott.emp where sal > 3000\n *\n ERROR at line 1:\n ORA-01031: insufficient privileges" }, - "impact": 0, + "impact": 0.5, "refs": [], "tags": { - "gtitle": "SRG-APP-000133-DB-000207", - "gid": "V-61869", - "rid": "SV-76359r1_rule", - "stig_id": "O121-OS-011200", - "fix_id": "F-67785r1_fix", + "gtitle": "SRG-APP-000516-DB-999900", + "gid": "V-61429", + "rid": "SV-75919r1_rule", + "stig_id": "O121-BP-022100", + "fix_id": "F-67345r1_fix", "cci": [ - "CCI-001499" + "CCI-000366" ], "nist": [ - "CM-5 (6)", + "CM-6 b", "Rev_4" ], "false_negatives": null, @@ -2296,39 +2375,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Review permissions that control access to the DBMS software\n libraries. The software library location may be determined from vendor\n documentation or service/process executable paths.\n\n DBA accounts, the DBMS process account, the DBMS software\n installation/maintenance account, SA accounts, if access by them is required\n for some operational level of support such as backups, and the host system\n itself require access. Any others should be scrutinized and a reason for access\n provided by the DBA.\n\n If accounts that are not required and authorized to have access to the software\n library location do have access, this is a finding.\n\n Check to see which users have been granted DBA. Work from a basis of least\n privilege. Provide the least amount of privilege required to accomplish the\n job.\n\n SQL> select * from dba_role_privs where granted_role = 'DBA';", - "fix": "Restrict access to the DBMS software libraries to accounts that\n require access based on job function." + "check": "From SQL*Plus:\n\n select value from v$parameter where name = 'sql92_security';\n\n If the value returned is set to FALSE, this is a finding.\n\n If the parameter is set to TRUE or does not exist, this is not a finding.", + "fix": "Enable SQL92 security.\n\n From SQL*Plus:\n\n alter system set sql92_security = TRUE scope = spfile;\n\n The above SQL*Plus command will set the parameter to take effect at next system\n startup." }, - "code": "control 'V-61869' do\n title \"The OS must limit privileges to change the DBMS software resident\n within software libraries (including privileged programs).\"\n desc \"When dealing with change control issues, it should be noted, any\n changes to the hardware, software, and/or firmware components of the\n information system and/or application can potentially have significant effects\n on the overall security of the system.\n\n If the application were to allow any user to make changes to software\n libraries, then those changes might be implemented without undergoing the\n appropriate testing and approvals that are part of a robust change management\n process.\n\n This requirement is contingent upon the language in which the application\n is programmed, as many application architectures in use today incorporate their\n software libraries into, and make them inseparable from, their compiled\n distributions, rendering them static and version-dependent. However, this\n requirement does apply to applications with software libraries accessible and\n configurable as in the case of interpreted languages.\n\n Accordingly, only qualified and authorized individuals shall be allowed to\n obtain access to information system components for purposes of initiating\n changes, including upgrades and modifications.\n\n The DBMS software libraries contain the executables used by the DBMS to\n operate. Unauthorized access to the libraries can result in malicious\n alteration. This may in turn jeopardize data stored in the DBMS and/or\n operation of the host system.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000133-DB-000207'\n tag \"gid\": 'V-61869'\n tag \"rid\": 'SV-76359r1_rule'\n tag \"stig_id\": 'O121-OS-011200'\n tag \"fix_id\": 'F-67785r1_fix'\n tag \"cci\": ['CCI-001499']\n tag \"nist\": ['CM-5 (6)', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Review permissions that control access to the DBMS software\n libraries. The software library location may be determined from vendor\n documentation or service/process executable paths.\n\n DBA accounts, the DBMS process account, the DBMS software\n installation/maintenance account, SA accounts, if access by them is required\n for some operational level of support such as backups, and the host system\n itself require access. Any others should be scrutinized and a reason for access\n provided by the DBA.\n\n If accounts that are not required and authorized to have access to the software\n library location do have access, this is a finding.\n\n Check to see which users have been granted DBA. Work from a basis of least\n privilege. Provide the least amount of privilege required to accomplish the\n job.\n\n SQL> select * from dba_role_privs where granted_role = 'DBA';\"\n tag \"fix\": \"Restrict access to the DBMS software libraries to accounts that\n require access based on job function.\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n dba_users = sql.query(\"select * from dba_role_privs where granted_role = 'DBA';\").column('grantee').uniq\n if dba_users.empty?\n impact 0.0\n describe \"There are no oracle DBA's, control N/A\" do\n skip \"There are no oracle DBA's, control N/A\"\n end\n else\n dba_users.each do |user|\n describe \"oracle DBA's users: #{user}\" do\n subject { user }\n it { should be_in input('oracle_dbas') }\n end\n end\n end\nend\n", + "code": "control 'V-61429' do\n title 'The Oracle SQL92_SECURITY parameter must be set to TRUE.'\n desc \"The configuration option SQL92_SECURITY specifies whether table-level\n SELECT privileges are required to execute an update or delete that references\n table column values. If this option is disabled (set to FALSE), the UPDATE\n privilege can be used to determine values that should require SELECT privileges.\n\n The SQL92_SECURITY setting of TRUE prevents the exploitation of user\n credentials with only DELETE or UPDATE privileges on a table from being able to\n derive column values in that table by performing a series of update/delete\n statements using a where clause, and rolling back the change. In the following\n example, with SQL92_SECURITY set to FALSE, a user with only delete privilege on\n the scott.emp table is able to derive that there is one employee with a salary\n greater than 3000. With SQL92_SECURITY set to TRUE, that user is prevented from\n attempting to derive a value.\n\n SQL92_SECURITY = FALSE\n SQL> delete from scott.emp where sal > 3000;\n 1 row deleted\n SQL> rollback;\n Rollback complete\n\n SQL92_SECURITY = TRUE\n SQL> delete from scott.emp where sal > 3000;\n delete from scott.emp where sal > 3000\n *\n ERROR at line 1:\n ORA-01031: insufficient privileges\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000516-DB-999900'\n tag \"gid\": 'V-61429'\n tag \"rid\": 'SV-75919r1_rule'\n tag \"stig_id\": 'O121-BP-022100'\n tag \"fix_id\": 'F-67345r1_fix'\n tag \"cci\": ['CCI-000366']\n tag \"nist\": ['CM-6 b', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"From SQL*Plus:\n\n select value from v$parameter where name = 'sql92_security';\n\n If the value returned is set to FALSE, this is a finding.\n\n If the parameter is set to TRUE or does not exist, this is not a finding.\"\n tag \"fix\": \"Enable SQL92 security.\n\n From SQL*Plus:\n\n alter system set sql92_security = TRUE scope = spfile;\n\n The above SQL*Plus command will set the parameter to take effect at next system\n startup.\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n parameter = sql.query(\"select value from v$parameter where name = 'sql92_security';\").column('value')\n\n describe 'The oracle database SQL92_SECURITY parameter' do\n subject { parameter }\n it { should cmp 'TRUE' }\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61869.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61429.rb", "line": 1 }, - "id": "V-61869" + "id": "V-61429" }, { - "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 automatically audit account termination.", + "desc": "When application accounts are terminated, user accessibility is\n affected. Accounts are utilized for identifying individual application users\n or for identifying the application processes themselves.\n\n In order to detect and respond to events affecting user accessibility and\n application processing, applications must audit account terminating actions and\n notify the appropriate individuals so they can investigate the event. Such a\n capability greatly reduces the risk that application accessibility will be\n negatively affected for extended periods of time and provides logging that can\n be used for forensic purposes.\n\n Note that user authentication and account management should be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP.\n\n However, notwithstanding how accounts are managed, Oracle auditing should\n always be configured to capture account termination.", "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": "When application accounts are terminated, user accessibility is\n affected. Accounts are utilized for identifying individual application users\n or for identifying the application processes themselves.\n\n In order to detect and respond to events affecting user accessibility and\n application processing, applications must audit account terminating actions and\n notify the appropriate individuals so they can investigate the event. Such a\n capability greatly reduces the risk that application accessibility will be\n negatively affected for extended periods of time and provides logging that can\n be used for forensic purposes.\n\n Note that user authentication and account management should be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP.\n\n However, notwithstanding how accounts are managed, Oracle auditing should\n always be configured to capture account termination." }, - "impact": 0, - "refs": [ - { - "ref": [] - } - ], + "impact": 0.5, + "refs": [], "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-000029-DB-000188", + "gid": "V-61573", + "rid": "SV-76063r2_rule", + "stig_id": "O121-C2-002500", + "fix_id": "F-67489r2_fix", "cci": [ - "CCI-000366" + "CCI-001405" ], "nist": [ - "CM-6 b", + "AC-2 (4)", "Rev_4" ], "false_negatives": null, @@ -2341,30 +2416,30 @@ "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": "Check Oracle settings (and also OS settings and/or\n enterprise-level authentication/access mechanisms settings) to determine if\n account termination actions are being audited. If account termination actions\n are not being audited by Oracle, this is a finding.\n\n If Standard Auditing is used:\n To see if Oracle is configured to capture audit data, enter the following\n SQL*Plus command:\n SHOW PARAMETER AUDIT_TRAIL\n or the following SQL query:\n SELECT * FROM SYS.V$PARAMETER WHERE NAME = 'audit_trail';\n If Oracle returns the value 'NONE', this is a finding.\n\n If Unified Auditing is used:\n To see if Oracle is configured to capture audit data including account\n termination, enter the following SQL*Plus command:\n SELECT ' Account termination 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 = 'DROP USER'\n and policy_name in (select policy_name from\n audit_unified_enabled_policies where user_name='ALL USERS'))) = 0\n OR (SELECT value\n FROM v$option\n WHERE parameter = 'Unified Auditing') != 'TRUE';\n\n If Oracle returns \"no rows selected\", this is not a finding.", + "fix": "Configure Oracle to audit account termination actions.\n\n If Standard Auditing is used:\n Use this process to ensure auditable events are captured:\n ALTER SYSTEM SET AUDIT_TRAIL= SCOPE=SPFILE;\n Audit trail type can be 'OS', 'DB', 'DB,EXTENDED', 'XML' or 'XML,EXTENDED'.\n After executing this statement, it may be necessary to shut down and restart\n the Oracle database.\n\n If Unified Auditing is used:\n To ensure auditable events are captured:\n Link the oracle binary with uniaud_on, and then restart the database. Oracle\n Database Upgrade Guide describes how to enable unified auditing. Reference\n V-61625 for information on how to configure a policy to audit account\n termination.\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-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-61573' do\n title 'The DBMS must automatically audit account termination.'\n desc \"When application accounts are terminated, user accessibility is\n affected. Accounts are utilized for identifying individual application users\n or for identifying the application processes themselves.\n\n In order to detect and respond to events affecting user accessibility and\n application processing, applications must audit account terminating actions and\n notify the appropriate individuals so they can investigate the event. Such a\n capability greatly reduces the risk that application accessibility will be\n negatively affected for extended periods of time and provides logging that can\n be used for forensic purposes.\n\n Note that user authentication and account management should be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP.\n\n However, notwithstanding how accounts are managed, Oracle auditing should\n always be configured to capture account termination.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000029-DB-000188'\n tag \"gid\": 'V-61573'\n tag \"rid\": 'SV-76063r2_rule'\n tag \"stig_id\": 'O121-C2-002500'\n tag \"fix_id\": 'F-67489r2_fix'\n tag \"cci\": ['CCI-001405']\n tag \"nist\": ['AC-2 (4)', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Check Oracle settings (and also OS settings and/or\n enterprise-level authentication/access mechanisms settings) to determine if\n account termination actions are being audited. If account termination actions\n are not being audited by Oracle, this is a finding.\n\n If Standard Auditing is used:\n To see if Oracle is configured to capture audit data, enter the following\n SQL*Plus command:\n SHOW PARAMETER AUDIT_TRAIL\n or the following SQL query:\n SELECT * FROM SYS.V$PARAMETER WHERE NAME = 'audit_trail';\n If Oracle returns the value 'NONE', this is a finding.\n\n If Unified Auditing is used:\n To see if Oracle is configured to capture audit data including account\n termination, enter the following SQL*Plus command:\n SELECT ' Account termination 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 = 'DROP USER'\n and policy_name in (select policy_name from\n audit_unified_enabled_policies where user_name='ALL USERS'))) = 0\n OR (SELECT value\n FROM v$option\n WHERE parameter = 'Unified Auditing') != 'TRUE';\n\n If Oracle returns \\\"no rows selected\\\", this is not a finding.\"\n tag \"fix\": \"Configure Oracle to audit account termination actions.\n\n If Standard Auditing is used:\n Use this process to ensure auditable events are captured:\n ALTER SYSTEM SET AUDIT_TRAIL= SCOPE=SPFILE;\n Audit trail type can be 'OS', 'DB', 'DB,EXTENDED', 'XML' or 'XML,EXTENDED'.\n After executing this statement, it may be necessary to shut down and restart\n the Oracle database.\n\n If Unified Auditing is used:\n To ensure auditable events are captured:\n Link the oracle binary with uniaud_on, and then restart the database. Oracle\n Database Upgrade Guide describes how to enable unified auditing. Reference\n V-61625 for information on how to configure a policy to audit account\n termination.\n\n For more information on the configuration of auditing, refer to the following\n documents:\n \\\"Auditing Database Activity\\\" in the Oracle Database 2 Day + Security Guide:\n http://docs.oracle.com/database/121/TDPSG/tdpsg_auditing.htm#TDPSG50000\n \\\"Monitoring Database Activity with Auditing\\\" in the Oracle Database Security\n Guide:\n http://docs.oracle.com/database/121/DBSEG/part_6.htm#CCHEHCGI\n \\\"DBMS_AUDIT_MGMT\\\" in the Oracle Database PL/SQL Packages and Types Reference:\n http://docs.oracle.com/database/121/ARPLS/d_audit_mgmt.htm#ARPLS241\n Oracle Database Upgrade Guide:\n http://docs.oracle.com/database/121/UPGRD/afterup.htm#UPGRD52810\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n standard_auditing_used = input('standard_auditing_used')\n unified_auditing_used = input('unified_auditing_used')\n\n describe.one do\n describe 'Standard auditing is in use for audit purposes' do\n subject { standard_auditing_used }\n it { should be true }\n end\n\n describe 'Unified auditing is in use for audit purposes' do\n subject { unified_auditing_used }\n it { should be true }\n end\n end\n\n audit_trail = sql.query(\"select value from v$parameter where name = 'audit_trail';\").column('value')\n\n if standard_auditing_used\n describe 'The oracle database audit_trail parameter' do\n subject { audit_trail }\n it { should_not cmp 'NONE' }\n end\n end\n\n unified_auditing = sql.query(\"SELECT value FROM V$OPTION WHERE PARAMETER = 'Unified Auditing';\").column('value')\n\n if unified_auditing_used\n describe 'The oracle database unified auditing parameter' do\n subject { unified_auditing }\n it { should_not cmp 'FALSE' }\n end\n\n unified_auditing_events = sql.query(\"SELECT ' Account termination 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 = 'DROP USER'\n and policy_name in (select policy_name from\n audit_unified_enabled_policies where user_name='ALL USERS'))) = 0\n OR (SELECT value\n FROM v$option\n WHERE parameter = 'Unified Auditing') != 'TRUE';\").column('Account termination is not being audited').uniq\n\n describe 'The unified auditing data capture for account termination' do\n subject { unified_auditing_events.to_s }\n it { should_not cmp '[nil]' }\n end\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61531.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61573.rb", "line": 1 }, - "id": "V-61531" + "id": "V-61573" }, { - "title": "The Oracle REMOTE_LOGIN_PASSWORDFILE parameter must be set to\n EXCLUSIVE or NONE.", - "desc": "The REMOTE_LOGIN_PASSWORDFILE setting of \"NONE\" disallows remote\n administration of the database. The REMOTE_LOGIN_PASSWORDFILE setting of\n \"EXCLUSIVE\" allows for auditing of individual DBA logons to the SYS account.\n If not set to \"EXCLUSIVE\", remote connections to the database as \"internal\"\n or \"as SYSDBA\" are not logged to an individual account.", + "title": "The database must not be directly accessible from public or\n unauthorized networks.", + "desc": "Databases often store critical and/or sensitive information used by\n the organization. For this reason, databases are targeted for attacks by\n malicious users. Additional protections provided by network defenses that limit\n accessibility help protect the database and its data from unnecessary exposure\n and risk.", "descriptions": { - "default": "The REMOTE_LOGIN_PASSWORDFILE setting of \"NONE\" disallows remote\n administration of the database. The REMOTE_LOGIN_PASSWORDFILE setting of\n \"EXCLUSIVE\" allows for auditing of individual DBA logons to the SYS account.\n If not set to \"EXCLUSIVE\", remote connections to the database as \"internal\"\n or \"as SYSDBA\" are not logged to an individual account." + "default": "Databases often store critical and/or sensitive information used by\n the organization. For this reason, databases are targeted for attacks by\n malicious users. Additional protections provided by network defenses that limit\n accessibility help protect the database and its data from unnecessary exposure\n and risk." }, "impact": 0.5, "refs": [], "tags": { "gtitle": "SRG-APP-000516-DB-999900", - "gid": "V-61431", - "rid": "SV-75921r2_rule", - "stig_id": "O121-BP-022200", - "fix_id": "F-67347r2_fix", + "gid": "V-61495", + "rid": "SV-75985r1_rule", + "stig_id": "O121-BP-024500", + "fix_id": "F-67411r1_fix", "cci": [ "CCI-000366" ], @@ -2382,21 +2457,21 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "From SQL*Plus:\n\n select value from v$parameter where upper(name) = 'REMOTE_LOGIN_PASSWORDFILE';\n\n If the value returned does not equal 'EXCLUSIVE' or 'NONE', this is a finding.", - "fix": "Disable use of the REMOTE_LOGIN_PASSWORDFILE where remote\n administration is not authorized by specifying a value of NONE.\n\n If authorized, restrict use of a password file to exclusive use by each\n database by specifying a value of EXCLUSIVE.\n\n From SQL*Plus:\n\n alter system set REMOTE_LOGIN_PASSWORDFILE = 'EXCLUSIVE' scope = spfile;\n\n OR\n\n alter system set REMOTE_LOGIN_PASSWORDFILE = 'NONE' scope = spfile;\n\n The above SQL*Plus command will set the parameter to take effect at next system\n startup." + "check": "Review the System Security Plan to determine if the DBMS serves\n data to users or applications outside the local enclave.\n\n If the DBMS is not accessed outside of the local enclave, this check is not a\n finding.\n\n If the DBMS serves applications available from a public network (e.g. the\n Internet), then confirm that the application servers are located in a DMZ.\n\n If the DBMS is located inside the local enclave and is directly accessible to\n public users, this is a finding.\n\n If the DBMS serves public-facing applications and is not protected from direct\n client connections and unauthorized networks, this is a finding.\n\n If the DBMS serves public-facing applications and contains sensitive or\n classified information, this is a finding.", + "fix": "Do not allow direct connections from users originating from the\n Internet or other public network to the DBMS.\n\n Include in the System Security Plan for the system whether the DBMS serves\n public-facing applications or applications serving users from other untrusted\n networks.\n\n Do not store sensitive or classified data on a DBMS server that serves\n public-facing applications." }, - "code": "control 'V-61431' do\n title \"The Oracle REMOTE_LOGIN_PASSWORDFILE parameter must be set to\n EXCLUSIVE or NONE.\"\n desc \"The REMOTE_LOGIN_PASSWORDFILE setting of \\\"NONE\\\" disallows remote\n administration of the database. The REMOTE_LOGIN_PASSWORDFILE setting of\n \\\"EXCLUSIVE\\\" allows for auditing of individual DBA logons to the SYS account.\n If not set to \\\"EXCLUSIVE\\\", remote connections to the database as \\\"internal\\\"\n or \\\"as SYSDBA\\\" are not logged to an individual account.\"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000516-DB-999900'\n tag \"gid\": 'V-61431'\n tag \"rid\": 'SV-75921r2_rule'\n tag \"stig_id\": 'O121-BP-022200'\n tag \"fix_id\": 'F-67347r2_fix'\n tag \"cci\": ['CCI-000366']\n tag \"nist\": ['CM-6 b', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"From SQL*Plus:\n\n select value from v$parameter where upper(name) = 'REMOTE_LOGIN_PASSWORDFILE';\n\n If the value returned does not equal 'EXCLUSIVE' or 'NONE', this is a finding.\"\n tag \"fix\": \"Disable use of the REMOTE_LOGIN_PASSWORDFILE where remote\n administration is not authorized by specifying a value of NONE.\n\n If authorized, restrict use of a password file to exclusive use by each\n database by specifying a value of EXCLUSIVE.\n\n From SQL*Plus:\n\n alter system set REMOTE_LOGIN_PASSWORDFILE = 'EXCLUSIVE' scope = spfile;\n\n OR\n\n alter system set REMOTE_LOGIN_PASSWORDFILE = 'NONE' scope = spfile;\n\n The above SQL*Plus command will set the parameter to take effect at next system\n startup.\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n parameter = sql.query(\"select value from v$parameter where upper(name) = 'REMOTE_LOGIN_PASSWORDFILE';\").column('value')\n\n describe.one do\n describe 'The oracle database REMOTE_LOGIN_PASSWORDFILE parameter' do\n subject { parameter }\n it { should cmp 'EXCLUSIVE' }\n end\n\n describe 'The oracle database REMOTE_LOGIN_PASSWORDFILE parameter' do\n subject { parameter }\n it { should cmp 'NONE' }\n end\n end\nend\n", + "code": "control 'V-61495' do\n title \"The database must not be directly accessible from public or\n unauthorized networks.\"\n desc \"Databases often store critical and/or sensitive information used by\n the organization. For this reason, databases are targeted for attacks by\n malicious users. Additional protections provided by network defenses that limit\n accessibility help protect the database and its data from unnecessary exposure\n and risk.\"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000516-DB-999900'\n tag \"gid\": 'V-61495'\n tag \"rid\": 'SV-75985r1_rule'\n tag \"stig_id\": 'O121-BP-024500'\n tag \"fix_id\": 'F-67411r1_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 System Security Plan to determine if the DBMS serves\n data to users or applications outside the local enclave.\n\n If the DBMS is not accessed outside of the local enclave, this check is not a\n finding.\n\n If the DBMS serves applications available from a public network (e.g. the\n Internet), then confirm that the application servers are located in a DMZ.\n\n If the DBMS is located inside the local enclave and is directly accessible to\n public users, this is a finding.\n\n If the DBMS serves public-facing applications and is not protected from direct\n client connections and unauthorized networks, this is a finding.\n\n If the DBMS serves public-facing applications and contains sensitive or\n classified information, this is a finding.\"\n tag \"fix\": \"Do not allow direct connections from users originating from the\n Internet or other public network to the DBMS.\n\n Include in the System Security Plan for the system whether the DBMS serves\n public-facing applications or applications serving users from other untrusted\n networks.\n\n Do not store sensitive or classified data on a DBMS server that serves\n public-facing applications.\"\n describe 'A manual review is required to ensure the database is not directly accessible from public or\n unauthorized networks.' do\n skip 'A manual review is required to ensure the database is not directly accessible from public or\n unauthorized networks.'\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61431.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61495.rb", "line": 1 }, - "id": "V-61431" + "id": "V-61495" }, { - "title": "Connections by mid-tier web and application systems to the Oracle DBMS\n from a DMZ or external network must be encrypted.\n ", - "desc": "Multi-tier systems may be configured with the database and connecting\n middle-tier system located on an internal network, with the database located on\n an internal network behind a firewall and the middle-tier system located in a\n DMZ. In cases where either or both systems are located in the DMZ (or on\n networks external to DoD), network communications between the systems must be\n encrypted.", + "title": "Access to external executables must be disabled or restricted.", + "desc": "The Oracle external procedure capability provides use of the Oracle\n process account outside the operation of the DBMS process. You can use it to\n submit and execute applications stored externally from the database under\n operating system controls. The external procedure process is the subject of\n frequent and successful attacks as it allows unauthenticated use of the Oracle\n process account on the operating system. As of Oracle version 11.1, the\n external procedure agent may be run directly from the database and not require\n use of the Oracle listener. This reduces the risk of unauthorized access to the\n procedure from outside of the database process.", "descriptions": { - "default": "Multi-tier systems may be configured with the database and connecting\n middle-tier system located on an internal network, with the database located on\n an internal network behind a firewall and the middle-tier system located in a\n DMZ. In cases where either or both systems are located in the DMZ (or on\n networks external to DoD), network communications between the systems must be\n encrypted." + "default": "The Oracle external procedure capability provides use of the Oracle\n process account outside the operation of the DBMS process. You can use it to\n submit and execute applications stored externally from the database under\n operating system controls. The external procedure process is the subject of\n frequent and successful attacks as it allows unauthenticated use of the Oracle\n process account on the operating system. As of Oracle version 11.1, the\n external procedure agent may be run directly from the database and not require\n use of the Oracle listener. This reduces the risk of unauthorized access to the\n procedure from outside of the database process." }, "impact": 0, "refs": [ @@ -2405,16 +2480,16 @@ } ], "tags": { - "gtitle": "SRG-APP-000516-DB-999900", - "gid": "V-61447", - "rid": "SV-75937r2_rule", - "stig_id": "O121-BP-023000", - "fix_id": "F-67363r2_fix", + "gtitle": "SRG-APP-000141-DB-000093", + "gid": "V-61685", + "rid": "SV-76175r2_rule", + "stig_id": "O121-C2-011810", + "fix_id": "F-67599r1_fix", "cci": [ - "CCI-000366" + "CCI-000381" ], "nist": [ - "CM-6 b", + "CM-7 a", "Rev_4" ], "false_negatives": null, @@ -2427,35 +2502,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Review the System Security Plan for remote applications that\n access and use the database.\n\n For each remote application or application server, determine whether\n communications between it and the DBMS are encrypted. If any are not encrypted,\n this is a finding.", - "fix": "Configure communications between the DBMS and remote\n applications/application servers to use DoD-approved encryption." + "check": "Review the System Security Plan to determine if the use of the\n external procedure agent is authorized.\n\n Review the ORACLE_HOME/bin directory or search the ORACLE_BASE path for the\n executable extproc (UNIX) or extproc.exe (Windows).\n\n If external procedure agent is not authorized for use in the System Security\n Plan and the executable file does not exist or is restricted, this is not a\n finding.\n\n If external procedure agent is not authorized for use in the System Security\n Plan and the executable file exists and is not restricted, this is a finding.\n\n If use of the external procedure agent is authorized, ensure extproc is\n restricted to execution of authorized applications.\n\n External jobs are run using the account nobody by default.\n\n Review the contents of the file ORACLE_HOME/rdbms/admin/externaljob.ora for the\n lines run_user= and run_group=.\n\n If the user assigned to these parameters is not \"nobody\", this is a finding.\n\n For versions 11.1 and later, the external procedure agent (extproc executable)\n is available directly from the database and does not require definition in the\n listener.ora file for use.\n\n Review the contents of the file ORACLE_HOME/hs/admin/extproc.ora.\n\n If the file does not exist, this is a finding.\n\n If the following entry does not appear in the file, this is a finding:\n\n EXTPROC_DLLS=ONLY:[dll full file name1]:[dll full file name2]:..\n\n [dll full file name] represents a full path and file name.\n\n This list of file names is separated by \":\".\n\n Note: If \"ONLY\" is specified, then the list is restricted to allow execution\n of only the DLLs specified in the list and is not a finding. If \"ANY\" is\n specified, then there are no restrictions for execution except what is\n controlled by operating system permissions and is a finding. If no\n specification is made, any files located in the %ORACLE_HOME%\\bin directory on\n Windows systems or $ORACLE_HOME/lib directory on UNIX systems can be executed\n (the default) and is a finding.\n\n Ensure that EXTPROC is not accessible from the listener.\n\n Review the listener.ora file. If any entries reference \"extproc\", this is a\n finding.\n\n Determine if the external procedure agent is in use per Oracle 10.x conventions.\n\n Review the listener.ora file.\n\n If any entries reference \"extproc\", then the agent is in use.\n\n If external procedure agent is not authorized for use in the System Security\n Plan and references to \"extproc\" exist, this is a finding.\n\n Sample listener.ora entries with extproc included:\n\n LISTENER =\n (DESCRIPTION =\n (ADDRESS = (PROTOCOL = TCP)(HOST = 127.0.0.1)(PORT = 1521))\n )\n EXTLSNR =\n (DESCRIPTION =\n (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC))\n )\n SID_LIST_LISTENER =\n (SID_LIST =\n (SID_DESC =\n (GLOBAL_DBNAME = ORCL)\n (ORACLE_HOME = /home/oracle/app/oracle/product/11.1.0/db_1)\n (SID_NAME = ORCL)\n )\n )\n SID_LIST_EXTLSNR =\n (SID_LIST =\n (SID_DESC =\n (PROGRAM = extproc)\n (SID_NAME = PLSExtProc)\n (ORACLE_HOME = /home/oracle/app/oracle/product/11.1.0/db_1)\n (ENVS=\"EXTPROC_DLLS=ONLY:/home/app1/app1lib.so:/home/app2/app2lib.so,\n LD_LIBRARY_PATH=/private/app2/lib:/private/app1,\n MYPATH=/usr/fso:/usr/local/packages\")\n )\n )\n\n Sample tnsnames.ora entries with extproc included:\n\n ORCL =\n (DESCRIPTION =\n (ADDRESS_LIST =\n (ADDRESS = (PROTOCOL = TCP)(HOST = 127.0.0.1)(PORT = 1521))\n )\n (CONNECT_DATA =\n (SERVICE_NAME = ORCL)\n )\n )\n EXTPROC_CONNECTION_DATA =\n (DESCRIPTION =\n (ADDRESS_LIST =\n (ADDRESS = (PROTOCOL = IPC)(KEY = extproc))\n )\n (CONNECT_DATA =\n (SERVER = DEDICATED)\n (SERVICE_NAME = PLSExtProc)\n )\n )\n\n If EXTPROC is in use, confirm that a listener is dedicated to serving the\n external procedure agent (as shown above).\n\n View the protocols configured for the listener.\n\n For the listener to be dedicated, the only entries will be to specify extproc.\n\n If there is not a dedicated listener in use for the external procedure agent,\n this is a finding.\n\n If the PROTOCOL= specified is other than IPC, this is a finding.\n\n Verify and ensure extproc is restricted executing authorized external\n applications only and extproc is restricted to execution of authorized\n applications.\n\n Review the listener.ora file.\n\n If the following entry does not exist, this is a finding:\n\n EXTPROC_DLLS=ONLY:[dll full file name1]:[dll full file name2]:...\n\n Note: [dll full file name] represents a full path and file name. This list of\n file names is separated by \":\".\n\n Note: If \"ONLY\" is specified, then the list is restricted to allow execution\n of only the DLLs specified in the list and is not a finding. If \"ANY\" is\n specified, then there are no restrictions for execution except what is\n controlled by operating system permissions and is a finding. If no\n specification is made, any files located in the %ORACLE_HOME%\\bin directory on\n Windows systems or $ORACLE_HOME/lib directory on UNIX systems can be executed\n (the default) and is a finding.\n\n View the listener.ora file (usually in ORACLE_HOME/network/admin or directory\n specified by the TNS_ADMIN environment variable).\n\n If multiple listener processes are running, then the listener.ora file for each\n must be viewed.\n\n For each process, determine the directory specified in the ORACLE_HOME or\n TNS_ADMIN environment variable defined for the process account to locate the\n listener.ora file.", + "fix": "If use of the external procedure agent is required, then\n authorize and document the requirement in the System Security Plan.\n\n If the external procedure agent must be accessible to the Oracle listener, then\n specify this and authorize it in the System Security Plan.\n\n If use of the Oracle External Procedure agent is not required:\n\n - Stop the Oracle Listener process\n - Remove all references to extproc in the listener.ora and tnsnames.ora files\n - Alter the permissions on the executable files:\n UNIX - Remove read/write/execute permissions from owner, group and\n world\n Windows - Remove Groups/Users from the executable (except groups\n SYSTEM and ADMINISTRATORS) and allow READ [only] for SYSTEM and ADMINISTRATORS\n groups\n\n If required:\n\n - Restrict extproc execution to only authorized applications.\n - Specify EXTPROC_DLLS=ONLY: [list of authorized DLLS] in the extproc.ora and\n the listener.ora files\n - Create a separate, dedicated listener for use by the external procedure agent\n\n See the Oracle Net Services Administrators Guides, External Procedures section\n for detailed configuration information." }, - "code": " control 'V-61447' do\n impact 0.0\n describe 'This control is not applicable on oracle within aws rds, as aws manages the operating system in which the oracle database is running on' do\n skip 'This control is not applicable on oracle within aws rds, as aws manages the operating system in which the oracle database is running on'\n end\n end\n", + "code": " control 'V-61685' do\n impact 0.0\n describe 'This control is not applicable on oracle within aws rds, as aws manages the operating system in which the oracle database is running on' do\n skip 'This control is not applicable on oracle within aws rds, as aws manages the operating system in which the oracle database is running on'\n end\n end\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61447.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61685.rb", "line": 1 }, - "id": "V-61447" + "id": "V-61685" }, { - "title": "Only authorized system accounts must have the SYSTEM tablespace\n specified as the default tablespace.", - "desc": "The Oracle SYSTEM tablespace is used by the database to store all DBMS\n system objects. Other use of the system tablespace may compromise system\n availability and the effectiveness of host system access controls to the\n tablespace files.", + "title": "The DBMS must notify appropriate individuals when accounts are\n created.", + "desc": "Once an attacker establishes initial access to a system, they often\n attempt to create a persistent method of re-establishing access. One way to\n accomplish this is for the attacker to simply create a new account.\n\n Notification of account creation is one method and best practice for\n mitigating this risk. A comprehensive account management process will ensure an\n audit trail which documents the creation of application user accounts and\n notifies administrators and/or application owners exist. Such a process greatly\n reduces the risk that accounts will be surreptitiously created and provides\n logging that can be used for forensic purposes.\n\n Note that user authentication and account management must be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP. This requirement applies to cases where accounts are\n directly managed by Oracle.\n\n Notwithstanding how accounts are normally managed, the DBMS must support\n the requirement to notify appropriate individuals upon account creation within\n Oracle. Indeed, in a configuration where accounts are managed externally, the\n creation of an account within Oracle may indicate hostile activity.", "descriptions": { - "default": "The Oracle SYSTEM tablespace is used by the database to store all DBMS\n system objects. Other use of the system tablespace may compromise system\n availability and the effectiveness of host system access controls to the\n tablespace files." + "default": "Once an attacker establishes initial access to a system, they often\n attempt to create a persistent method of re-establishing access. One way to\n accomplish this is for the attacker to simply create a new account.\n\n Notification of account creation is one method and best practice for\n mitigating this risk. A comprehensive account management process will ensure an\n audit trail which documents the creation of application user accounts and\n notifies administrators and/or application owners exist. Such a process greatly\n reduces the risk that accounts will be surreptitiously created and provides\n logging that can be used for forensic purposes.\n\n Note that user authentication and account management must be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP. This requirement applies to cases where accounts are\n directly managed by Oracle.\n\n Notwithstanding how accounts are normally managed, the DBMS must support\n the requirement to notify appropriate individuals upon account creation within\n Oracle. Indeed, in a configuration where accounts are managed externally, the\n creation of an account within Oracle may indicate hostile activity." }, - "impact": 0, + "impact": 0.5, "refs": [], "tags": { - "gtitle": "SRG-APP-000516-DB-999900", - "gid": "V-61459", - "rid": "SV-75949r2_rule", - "stig_id": "O121-BP-023600", - "fix_id": "F-67375r2_fix", + "gtitle": "SRG-APP-000291-DB-000139", + "gid": "V-61797", + "rid": "SV-76287r2_rule", + "stig_id": "O121-C2-020400", + "fix_id": "F-67713r1_fix", "cci": [ - "CCI-000366" + "CCI-001683" ], "nist": [ - "CM-6 b", + "AC-2 (4)", "Rev_4" ], "false_negatives": null, @@ -2468,35 +2543,39 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Run the query:\n\n select property_name, property_value\n from database_properties\n where property_name in\n ('DEFAULT_PERMANENT_TABLESPACE','DEFAULT_TEMP_TABLESPACE');\n\n If either value is set to SYSTEM, this is a finding.\n\n Run the query:\n\n select username from dba_users\n where (default_tablespace = 'SYSTEM' or temporary_tablespace = 'SYSTEM')\n and username not in\n ('LBACSYS','OUTLN','SYS','SYSTEM');\n\n If any non-default account records are returned, this is a finding.", - "fix": "Create and dedicate tablespaces to support only one application.\n\n Do not share tablespaces between applications.\n\n Do not grant quotas to application object owners on tablespaces not dedicated\n to their associated application.\n\n Run the queries:\n\n alter database default tablespace ;\n alter database default temporary tablespace ;\n\n alter user default tablespace temporary tablespace\n ;\n\n Replace with the named user account.\n Replace with the new default tablespace name.\n Replace with the new default temporary tablespace\n name (typically TEMP).\n Repeat the \"alter user\" for each affected user account." + "check": "Check DBMS settings to determine whether it will notify\n appropriate individuals when accounts are created.\n\n If the DBMS does not notify appropriate individuals when accounts are created,\n this is a finding.", + "fix": "Working with the DBA and site management, determine the\n appropriate individuals (by job role) to be notified.\n\n If Oracle Audit Vault is available, configure it to notify the appropriate\n individuals when accounts are created.\n\n If Oracle Audit Vault is not available, configure the Oracle DBMS's auditing\n feature to record account-creation activity.\n\n If Standard Auditing is used:\n Create and deploy a mechanism, such as a frequently-run job, to monitor the\n SYS.AUD$ table for these records and notify the appropriate individuals.\n\n If unified Auditing is used:\n Create and deploy a mechanism, such as a frequently-run job, to monitor the\n SYS.UNIFIED_AUDIT_TRAIL view for these records and notify the appropriate\n individuals." }, - "code": "control 'V-61459' do\n title \"Only authorized system accounts must have the SYSTEM tablespace\n specified as the default tablespace.\"\n desc \"The Oracle SYSTEM tablespace is used by the database to store all DBMS\n system objects. Other use of the system tablespace may compromise system\n availability and the effectiveness of host system access controls to the\n tablespace files.\"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000516-DB-999900'\n tag \"gid\": 'V-61459'\n tag \"rid\": 'SV-75949r2_rule'\n tag \"stig_id\": 'O121-BP-023600'\n tag \"fix_id\": 'F-67375r2_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 query:\n\n select property_name, property_value\n from database_properties\n where property_name in\n ('DEFAULT_PERMANENT_TABLESPACE','DEFAULT_TEMP_TABLESPACE');\n\n If either value is set to SYSTEM, this is a finding.\n\n Run the query:\n\n select username from dba_users\n where (default_tablespace = 'SYSTEM' or temporary_tablespace = 'SYSTEM')\n and username not in\n ('LBACSYS','OUTLN','SYS','SYSTEM');\n\n If any non-default account records are returned, this is a finding.\"\n tag \"fix\": \"Create and dedicate tablespaces to support only one application.\n\n Do not share tablespaces between applications.\n\n Do not grant quotas to application object owners on tablespaces not dedicated\n to their associated application.\n\n Run the queries:\n\n alter database default tablespace ;\n alter database default temporary tablespace ;\n\n alter user default tablespace temporary tablespace\n ;\n\n Replace with the named user account.\n Replace with the new default tablespace name.\n Replace with the new default temporary tablespace\n name (typically TEMP).\n Repeat the \\\"alter user\\\" for each affected user account.\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n property_name = sql.query(\"select property_name\n from database_properties\n where property_name in\n ('DEFAULT_PERMANENT_TABLESPACE','DEFAULT_TEMP_TABLESPACE');\").column('property_name')\n\n describe 'The oracle database property_name' do\n subject { property_name }\n it { should_not include 'SYSTEM' }\n end\n\n property_value = sql.query(\"select property_value\n from database_properties\n where property_name in\n ('DEFAULT_PERMANENT_TABLESPACE','DEFAULT_TEMP_TABLESPACE');\").column('property_value')\n\n describe 'The oracle database property_value' do\n subject { property_value }\n it { should_not include 'SYSTEM' }\n end\n\n users_with_system_tablespace = sql.query(\"select username from dba_users\n where (default_tablespace = 'SYSTEM' or temporary_tablespace = 'SYSTEM')\n and username not in\n ('LBACSYS','OUTLN','SYS','SYSTEM');\").column('username').uniq\n if users_with_system_tablespace.empty?\n impact 0.0\n describe 'There are no oracle users granted system tablespace, therefore control N/A' do\n skip 'There are no oracle users granted system tablespace, therefore control N/A'\n end\n else\n users_with_system_tablespace.each do |user|\n describe \"oracle users with system tablespace: #{user}\" do\n subject { user }\n it { should be_in input('allowed_users_system_tablespace') }\n end\n end\n end\nend\n", + "code": "control 'V-61797' do\n title \"The DBMS must notify appropriate individuals when accounts are\n created.\"\n desc \"Once an attacker establishes initial access to a system, they often\n attempt to create a persistent method of re-establishing access. One way to\n accomplish this is for the attacker to simply create a new account.\n\n Notification of account creation is one method and best practice for\n mitigating this risk. A comprehensive account management process will ensure an\n audit trail which documents the creation of application user accounts and\n notifies administrators and/or application owners exist. Such a process greatly\n reduces the risk that accounts will be surreptitiously created and provides\n logging that can be used for forensic purposes.\n\n Note that user authentication and account management must be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP. This requirement applies to cases where accounts are\n directly managed by Oracle.\n\n Notwithstanding how accounts are normally managed, the DBMS must support\n the requirement to notify appropriate individuals upon account creation within\n Oracle. Indeed, in a configuration where accounts are managed externally, the\n creation of an account within Oracle may indicate hostile activity.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000291-DB-000139'\n tag \"gid\": 'V-61797'\n tag \"rid\": 'SV-76287r2_rule'\n tag \"stig_id\": 'O121-C2-020400'\n tag \"fix_id\": 'F-67713r1_fix'\n tag \"cci\": ['CCI-001683']\n tag \"nist\": ['AC-2 (4)', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Check DBMS settings to determine whether it will notify\n appropriate individuals when accounts are created.\n\n If the DBMS does not notify appropriate individuals when accounts are created,\n this is a finding.\"\n tag \"fix\": \"Working with the DBA and site management, determine the\n appropriate individuals (by job role) to be notified.\n\n If Oracle Audit Vault is available, configure it to notify the appropriate\n individuals when accounts are created.\n\n If Oracle Audit Vault is not available, configure the Oracle DBMS's auditing\n feature to record account-creation activity.\n\n If Standard Auditing is used:\n Create and deploy a mechanism, such as a frequently-run job, to monitor the\n SYS.AUD$ table for these records and notify the appropriate individuals.\n\n If unified Auditing is used:\n Create and deploy a mechanism, such as a frequently-run job, to monitor the\n SYS.UNIFIED_AUDIT_TRAIL view for these records and notify the appropriate\n individuals.\"\n describe 'A manual review is required to ensure the DBMS notifies the appropriate individuals when accounts are\n created' do\n skip 'A manual review is required to ensure the DBMS notifies the appropriate individuals when accounts are\n created'\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61459.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61797.rb", "line": 1 }, - "id": "V-61459" + "id": "V-61797" }, { - "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.", + "title": "The DBMS must protect against or limit the effects of\n organization-defined types of Denial of Service (DoS) attacks.", + "desc": "A variety of technologies exist to limit, or in some cases, eliminate\n the effects of DoS attacks. For example, boundary protection devices can filter\n certain types of packets to protect devices on an organization's internal\n network from being directly affected by DoS attacks.\n\n Employing increased capacity and bandwidth combined with service redundancy\n may reduce the susceptibility to some DoS attacks.\n\n Some of the ways databases can limit their exposure to DoS attacks are\n through limiting the number of connections that can be opened by a single user\n and database clustering.", "descriptions": { - "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." + "default": "A variety of technologies exist to limit, or in some cases, eliminate\n the effects of DoS attacks. For example, boundary protection devices can filter\n certain types of packets to protect devices on an organization's internal\n network from being directly affected by DoS attacks.\n\n Employing increased capacity and bandwidth combined with service redundancy\n may reduce the susceptibility to some DoS attacks.\n\n Some of the ways databases can limit their exposure to DoS attacks are\n through limiting the number of connections that can be opened by a single user\n and database clustering." }, - "impact": 0.5, - "refs": [], + "impact": 0, + "refs": [ + { + "ref": [] + } + ], "tags": { - "gtitle": "SRG-APP-000087-DB-000013", - "gid": "V-61619", - "rid": "SV-76109r1_rule", - "stig_id": "O121-C2-006700", - "fix_id": "F-67535r1_fix", + "gtitle": "SRG-APP-000245-DB-000132", + "gid": "V-61783", + "rid": "SV-76273r1_rule", + "stig_id": "O121-C2-019100", + "fix_id": "F-67699r1_fix", "cci": [ - "CCI-002165" + "CCI-002385" ], "nist": [ - "AC-3 (4)", + "SC-5", "Rev_4" ], "false_negatives": null, @@ -2509,35 +2588,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "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.)" + "check": "Review DBMS settings to verify the DBMS implements measures to\n limit the effects of the organization-defined types of Denial of Service (DoS)\n attacks.\n\n If measures have not been implemented, this is a finding.\n\n Check the $ORACLE_HOME/network/admin/listener.ora to see if a Rate Limit has\n been established. A rate limit is used to prevent denial of service (DOS)\n attacks on a database or to control a logon storm such as may be caused by an\n application server reboot.\n\n - - - - -\n Example of a listener configuration with rate limiting in effect:\n\n CONNECTION_RATE_LISTENER=10\n\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 LISTENER=\n (ADDRESS_LIST=\n (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1521)(RATE_LIMIT=8))\n (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1522)(RATE_LIMIT=12))\n (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1526))\n )", + "fix": "Implement measures to limit the effects of organization-defined\n types of Denial of Service attacks.\n\n Modify the $ORACLE_HOME/network/admin/listener.ora to establish a Rate Limit." }, - "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", + "code": " control 'V-61783' 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-61619.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61783.rb", "line": 1 }, - "id": "V-61619" + "id": "V-61783" }, { - "title": "System Privileges must not be granted to PUBLIC.", - "desc": "System privileges can be granted to users and roles and to the user\n group PUBLIC. All privileges granted to PUBLIC are accessible to every user in\n the database. Many of these privileges convey considerable authority over the\n database and should be granted only to those persons responsible for\n administering the database. In general, these privileges should be granted to\n roles and then the appropriate roles should be granted to users. System\n privileges must never be granted to PUBLIC as this could allow users to\n compromise the database.", + "title": "The system must protect audit tools from unauthorized modification.", + "desc": "Protecting audit data also includes identifying and protecting the\n tools used to view and manipulate log data.\n\n Depending upon the log format and application, system and application log\n tools may provide the only means to manipulate and manage application and\n system log data.\n\n If the tools are compromised it could provide attackers with the capability\n to manipulate log data. It is, therefore, imperative that audit tools be\n controlled and protected from unauthorized modification.\n\n Audit tools include, but are not limited to, OS provided audit tools,\n vendor provided audit tools, and open source audit tools needed to successfully\n view and manipulate audit information system activity and records.\n\n If an attacker were to gain access to audit tools he could analyze audit\n logs for system weaknesses or weaknesses in the auditing itself. An attacker\n could also manipulate logs to hide evidence of malicious activity.", "descriptions": { - "default": "System privileges can be granted to users and roles and to the user\n group PUBLIC. All privileges granted to PUBLIC are accessible to every user in\n the database. Many of these privileges convey considerable authority over the\n database and should be granted only to those persons responsible for\n administering the database. In general, these privileges should be granted to\n roles and then the appropriate roles should be granted to users. System\n privileges must never be granted to PUBLIC as this could allow users to\n compromise the database." + "default": "Protecting audit data also includes identifying and protecting the\n tools used to view and manipulate log data.\n\n Depending upon the log format and application, system and application log\n tools may provide the only means to manipulate and manage application and\n system log data.\n\n If the tools are compromised it could provide attackers with the capability\n to manipulate log data. It is, therefore, imperative that audit tools be\n controlled and protected from unauthorized modification.\n\n Audit tools include, but are not limited to, OS provided audit tools,\n vendor provided audit tools, and open source audit tools needed to successfully\n view and manipulate audit information system activity and records.\n\n If an attacker were to gain access to audit tools he could analyze audit\n logs for system weaknesses or weaknesses in the auditing itself. An attacker\n could also manipulate logs to hide evidence of malicious activity." }, - "impact": 0.5, + "impact": 0, "refs": [], "tags": { - "gtitle": "SRG-APP-000516-DB-999900", - "gid": "V-61435", - "rid": "SV-75925r1_rule", - "stig_id": "O121-BP-022400", - "fix_id": "F-67351r1_fix", + "gtitle": "SRG-APP-000122-DB-000203", + "gid": "V-61661", + "rid": "SV-76151r1_rule", + "stig_id": "O121-C2-009700", + "fix_id": "F-67575r1_fix", "cci": [ - "CCI-000366" + "CCI-001494" ], "nist": [ - "CM-6 b", + "AU-9", "Rev_4" ], "false_negatives": null, @@ -2550,30 +2629,30 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "From SQL*Plus:\n\n select privilege from dba_sys_privs where grantee = 'PUBLIC';\n\n If any records are returned, this is a finding.", - "fix": "Revoke any system privileges assigned to PUBLIC:\n\n From SQL*Plus:\n\n revoke [system privilege] from PUBLIC;\n\n Replace [system privilege] with the named system privilege.\n\n Note: System privileges are not granted to PUBLIC by default and would\n indicate a custom action." + "check": "Review access permissions to tools used to view or modify audit\n log data. These tools may include the DBMS itself or tools external to the\n database.\n\n If appropriate permissions and access controls are not applied to prevent\n unauthorized modification of these tools, this is a finding.", + "fix": "Add or modify access controls and permissions to tools used to\n view or modify audit log data. Tools must be modifiable by authorized personnel\n only." }, - "code": "control 'V-61435' do\n title 'System Privileges must not be granted to PUBLIC.'\n desc \"System privileges can be granted to users and roles and to the user\n group PUBLIC. All privileges granted to PUBLIC are accessible to every user in\n the database. Many of these privileges convey considerable authority over the\n database and should be granted only to those persons responsible for\n administering the database. In general, these privileges should be granted to\n roles and then the appropriate roles should be granted to users. System\n privileges must never be granted to PUBLIC as this could allow users to\n compromise the database.\"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000516-DB-999900'\n tag \"gid\": 'V-61435'\n tag \"rid\": 'SV-75925r1_rule'\n tag \"stig_id\": 'O121-BP-022400'\n tag \"fix_id\": 'F-67351r1_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 privilege from dba_sys_privs where grantee = 'PUBLIC';\n\n If any records are returned, this is a finding.\"\n tag \"fix\": \"Revoke any system privileges assigned to PUBLIC:\n\n From SQL*Plus:\n\n revoke [system privilege] from PUBLIC;\n\n Replace [system privilege] with the named system privilege.\n\n Note: System privileges are not granted to PUBLIC by default and would\n indicate a custom action.\"\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 privilege from dba_sys_privs where grantee = 'PUBLIC';\").row(0).column('privilege') do\n its('value') { should be_empty }\n end\nend\n", + "code": "control 'V-61661' do\n title 'The system must protect audit tools from unauthorized modification.'\n desc \"Protecting audit data also includes identifying and protecting the\n tools used to view and manipulate log data.\n\n Depending upon the log format and application, system and application log\n tools may provide the only means to manipulate and manage application and\n system log data.\n\n If the tools are compromised it could provide attackers with the capability\n to manipulate log data. It is, therefore, imperative that audit tools be\n controlled and protected from unauthorized modification.\n\n Audit tools include, but are not limited to, OS provided audit tools,\n vendor provided audit tools, and open source audit tools needed to successfully\n view and manipulate audit information system activity and records.\n\n If an attacker were to gain access to audit tools he could analyze audit\n logs for system weaknesses or weaknesses in the auditing itself. An attacker\n could also manipulate logs to hide evidence of malicious activity.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000122-DB-000203'\n tag \"gid\": 'V-61661'\n tag \"rid\": 'SV-76151r1_rule'\n tag \"stig_id\": 'O121-C2-009700'\n tag \"fix_id\": 'F-67575r1_fix'\n tag \"cci\": ['CCI-001494']\n tag \"nist\": ['AU-9', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Review access permissions to tools used to view or modify audit\n log data. These tools may include the DBMS itself or tools external to the\n database.\n\n If appropriate permissions and access controls are not applied to prevent\n unauthorized modification of these tools, this is a finding.\"\n tag \"fix\": \"Add or modify access controls and permissions to tools used to\n view or modify audit log data. Tools must be modifiable by authorized personnel\n only.\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n users_allowed_access_to_audit_info = sql.query(\"SELECT GRANTEE, TABLE_NAME, PRIVILEGE\n FROM DBA_TAB_PRIVS where owner='AUDSYS';\").column('grantee').uniq\n if users_allowed_access_to_audit_info.empty?\n impact 0.0\n describe 'There are no oracle users allowed access to audit information, control N/A' do\n skip 'There are no oracle users allowed access to audit information'\n end\n else\n users_allowed_access_to_audit_info.each do |user|\n describe \"oracle users: #{user} allowed access to audit information\" do\n subject { user }\n it { should be_in input('allowed_audit_users') }\n end\n end\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61435.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61661.rb", "line": 1 }, - "id": "V-61435" + "id": "V-61661" }, { - "title": "Audit trail data must be retained for at least one year.", - "desc": "Without preservation, a complete discovery of an attack or suspicious\n activity may not be determined. DBMS audit data also contributes to the\n complete investigation of unauthorized activity and needs to be included in\n audit retention plans and procedures.", + "title": "When using command-line tools such as Oracle SQL*Plus, which can\n accept a plain-text password, users must use an alternative logon method that\n does not expose the password.", + "desc": "The SRG states: To prevent the compromise of authentication\n information, such as passwords, during the authentication process, the feedback\n from the information system shall not provide any information that would allow\n an unauthorized user to compromise the authentication mechanism.\n\n Obfuscation of user-provided information when typed into the system is a\n method used in addressing this risk\n\n For example, displaying asterisks when a user types in a password, is an\n example of obscuring feedback of authentication information.\n\n Database applications may allow for entry of the account name and\n password as a visible parameter of the application execution command. This\n practice should be prohibited and disabled to prevent shoulder surfing.\n\n SQL*Plus is an essential part of any Oracle installation. SQL*Plus cannot\n be configured not to accept a plain-text password. Since the typical SQL*Plus\n user is a database administrator, the consequences of password compromise are\n particularly serious. Therefore, the use of plain-text passwords must be\n prohibited, as a matter of practice and procedure.\n\n Transport Layer Security (TLS) is the successor protocol to Secure Sockets\n Layer (SSL). Although the Oracle configuration parameters have names including\n SSL, such as SSL_VERSION and SSL_CIPHER_SUITES, they refer to TLS.", "descriptions": { - "default": "Without preservation, a complete discovery of an attack or suspicious\n activity may not be determined. DBMS audit data also contributes to the\n complete investigation of unauthorized activity and needs to be included in\n audit retention plans and procedures." + "default": "The SRG states: To prevent the compromise of authentication\n information, such as passwords, during the authentication process, the feedback\n from the information system shall not provide any information that would allow\n an unauthorized user to compromise the authentication mechanism.\n\n Obfuscation of user-provided information when typed into the system is a\n method used in addressing this risk\n\n For example, displaying asterisks when a user types in a password, is an\n example of obscuring feedback of authentication information.\n\n Database applications may allow for entry of the account name and\n password as a visible parameter of the application execution command. This\n practice should be prohibited and disabled to prevent shoulder surfing.\n\n SQL*Plus is an essential part of any Oracle installation. SQL*Plus cannot\n be configured not to accept a plain-text password. Since the typical SQL*Plus\n user is a database administrator, the consequences of password compromise are\n particularly serious. Therefore, the use of plain-text passwords must be\n prohibited, as a matter of practice and procedure.\n\n Transport Layer Security (TLS) is the successor protocol to Secure Sockets\n Layer (SSL). Although the Oracle configuration parameters have names including\n SSL, such as SSL_VERSION and SSL_CIPHER_SUITES, they refer to TLS." }, - "impact": 0.5, + "impact": 0.7, "refs": [], "tags": { - "gtitle": "SRG-APP-000516-DB-999900", - "gid": "V-61409", - "rid": "SV-75899r1_rule", - "stig_id": "O121-BP-021100", - "fix_id": "F-67325r1_fix", + "gtitle": "SRG-APP-000178-DB-000083", + "gid": "V-61845", + "rid": "SV-76335r2_rule", + "stig_id": "O121-N1-015602", + "fix_id": "F-67761r4_fix", "cci": [ "CCI-000366" ], @@ -2591,35 +2670,36 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Review and verify the implementation of an audit trail\n retention policy.\n\n Verify that audit data is maintained for a minimum of one year.\n\n If audit data is not maintained for a minimum of one year, this is a finding.", - "fix": "Develop, document and implement an audit retention policy and\n procedures.\n\n It is recommended that the most recent thirty days of audit logs remain\n available online.\n\n After thirty days, the audit logs may be maintained off-line.\n\n Online maintenance provides for a more timely capability and inclination to\n investigate suspicious activity." + "check": "For Oracle SQL*Plus, which cannot be configured not to accept a\n plain-text password, and any other essential tool with the same limitation,\n verify that the system documentation explains the need for the tool, who uses\n it, and any relevant mitigations; and that AO approval has been obtained. If\n not, this is a finding.\n\n Request evidence that all users of the tool are trained in the importance of\n not using the plain-text password option and in how to keep the password\n hidden; and that they adhere to this practice. If not, this is a finding.", + "fix": "For Oracle SQL*Plus, which cannot be configured not to accept a\n plain-text password, and any other essential tool with the same limitation:\n\n 1) Document the need for it, who uses it, and any relevant mitigations, and\n obtain AO approval.\n 2) Train all users of the tool in the importance of not using the plain-text\n password option and in how to keep the password hidden.\n\n - - - - -\n Consider wrapping the startup command with a shell or wrapper and using an\n Oracle external password store.\n\n Oracle provides the capability to provide for a secure external password\n facility. Use the Oracle mkstore to create a secure storage area for passwords\n for applications, batch jobs, and scripts to use or deploy a site-authorized\n facility to perform this function.\n\n Check to see what has been stored in the Oracle External Password Store.\n\n To view all contents of a client wallet external password store, check specific\n credentials by viewing them. Listing the external password store contents\n provides information used to decide whether to add or delete credentials from\n the store. To list the contents of the external password store, enter the\n following command at the command line:\n\n $ mkstore -wrl wallet_location -listCredential\n\n For example:\n\n $ mkstore -wrl c:\\oracle\\product\\12.1.0\\db_1\\wallets -listCredential\n\n The wallet_location specifies the path to the directory where the wallet, whose\n external password store contents is to be viewed, is located. This command\n lists all of the credential database service names (aliases) and the\n corresponding user name (schema) for that database. Passwords are not listed.\n\n Configuring Clients to Use the External Password Store\n\n If the client is already configured to use external authentication, such as\n Windows native authentication or Transport Layer Security (TLS), then Oracle\n Database uses that authentication method. The same credentials used for this\n type of authentication are typically also used to log on to the database.\n\n For clients not using such authentication methods or wanting to override them\n for database authentication, set the SQLNET.WALLET_OVERRIDE parameter in\n sqlnet.ora to TRUE. The default value for SQLNET.WALLET_OVERRIDE is FALSE,\n allowing standard use of authentication credentials as before.\n\n If wanting a client to use the secure external password store feature, then\n perform the following configuration task:\n\n 1. Create a wallet on the client by using the following syntax at the command\n line:\n orapki create -wallet wallet_location -auto_login_local\n\n For example:\n orapki wallet create -wallet c:\\oracle\\product\\12.1.0\\db_1\\wallets\n -auto_login_local\n Enter password: password\n\n The wallet_location is the path to the directory where the wallet is to be\n created and stored. This command creates an Oracle wallet with the autologon\n feature enabled at the location specified. The autologon feature enables the\n client to access the wallet contents without supplying a password.\n\n The mkstore utility -create option uses password complexity verification.\n\n 2. Create database connection credentials in the wallet by using the following\n syntax at the command line:\n mkstore -wrl wallet_location -createCredential db_connect_string username\n Enter password: password\n\n For example:\n mkstore -wrl c:\\oracle\\product\\12.1.0\\db_1\\wallets -createCredential\n oracle system\n Enter password: password\n\n In this specification:\n The wallet_location is the path to the directory where the wallet was created.\n The db_connect_string used in the CONNECT /@db_connect_string statement must be\n identical to the db_connect_string specified in the -createCredential command.\n\n The db_connect_string is the TNS alias used to specify the database in the\n tnsnames.ora file or any service name used to identify the database on an\n Oracle network. By default, tnsnames.ora is located in the\n $ORACLE_HOME/network/admin directory on UNIX systems and in ORACLE_HOME etwork\\admin on Windows.\n\n The username is the database logon credential. When prompted, enter the\n password for this user.\n\n 3. In the client sqlnet.ora file, enter the WALLET_LOCATION parameter and set\n it to the directory location of the wallet created in Step 1. For example, if\n the wallet was created in $ORACLE_HOME/network/admin and the Oracle home is set\n to /private/ora12, then need to enter the following into the client sqlnet.ora\n file:\n\n WALLET_LOCATION =\n (SOURCE =\n (METHOD = FILE)\n (METHOD_DATA =\n (DIRECTORY = /private/ora12/network/admin)\n )\n )\n\n 4. In the client sqlnet.ora file, enter the SQLNET.WALLET_OVERRIDE parameter\n and set it to TRUE as follows:\n\n SQLNET.WALLET_OVERRIDE = TRUE\n\n This setting causes all CONNECT /@db_connect_string statements to use the\n information in the wallet at the specified location to authenticate to\n databases.\n\n When external authentication is in use, an authenticated user with such a\n wallet can use the CONNECT /@db_connect_string syntax to access the previously\n specified databases without providing a user name and password. However, if a\n user fails that external authentication, then these connect statements also\n fail.\n\n Below is a sample sqlnet.ora file with the WALLET_LOCATION and the\n SQLNET.WALLET_OVERRIDE parameters set as described in Steps 3 and 4.\n\n Below is a sample SQLNET.ORA File with Wallet Parameters Set\n\n WALLET_LOCATION =\n (SOURCE =\n (METHOD = FILE)\n (METHOD_DATA =\n (DIRECTORY = /private/ora12/network/admin)\n )\n )\n\n SQLNET.WALLET_OVERRIDE = TRUE\n SSL_CLIENT_AUTHENTICATION = FALSE\n SSL_VERSION =1.2 or 1.1\n\n (Note: This assumes that a single sqlnet.ora file, in the default location, is\n in use. Please see the supplemental file Non-default sqlnet.ora\n configurations.pdf for how to find multiple and/or differently located\n sqlnet.ora files.)\n\n Note: SSL_VERSION = 1.2 or 1.1 is the actual value, not a suggestion to\n use one or the other." }, - "code": "control 'V-61409' do\n title 'Audit trail data must be retained for at least one year.'\n desc \"Without preservation, a complete discovery of an attack or suspicious\n activity may not be determined. DBMS audit data also contributes to the\n complete investigation of unauthorized activity and needs to be included in\n audit retention plans and procedures.\"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000516-DB-999900'\n tag \"gid\": 'V-61409'\n tag \"rid\": 'SV-75899r1_rule'\n tag \"stig_id\": 'O121-BP-021100'\n tag \"fix_id\": 'F-67325r1_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 and verify the implementation of an audit trail\n retention policy.\n\n Verify that audit data is maintained for a minimum of one year.\n\n If audit data is not maintained for a minimum of one year, this is a finding.\"\n tag \"fix\": \"Develop, document and implement an audit retention policy and\n procedures.\n\n It is recommended that the most recent thirty days of audit logs remain\n available online.\n\n After thirty days, the audit logs may be maintained off-line.\n\n Online maintenance provides for a more timely capability and inclination to\n investigate suspicious activity.\"\n describe 'A manual review is required to ensure audit trail data is retained for at least one year' do\n skip 'A manual review is required to ensure audit trail data is retained for at least one year'\n end\nend\n", + "code": "control 'V-61845' do\n title \"When using command-line tools such as Oracle SQL*Plus, which can\n accept a plain-text password, users must use an alternative logon method that\n does not expose the password.\"\n desc \"The SRG states: To prevent the compromise of authentication\n information, such as passwords, during the authentication process, the feedback\n from the information system shall not provide any information that would allow\n an unauthorized user to compromise the authentication mechanism.\n\n Obfuscation of user-provided information when typed into the system is a\n method used in addressing this risk\n\n For example, displaying asterisks when a user types in a password, is an\n example of obscuring feedback of authentication information.\n\n Database applications may allow for entry of the account name and\n password as a visible parameter of the application execution command. This\n practice should be prohibited and disabled to prevent shoulder surfing.\n\n SQL*Plus is an essential part of any Oracle installation. SQL*Plus cannot\n be configured not to accept a plain-text password. Since the typical SQL*Plus\n user is a database administrator, the consequences of password compromise are\n particularly serious. Therefore, the use of plain-text passwords must be\n prohibited, as a matter of practice and procedure.\n\n Transport Layer Security (TLS) is the successor protocol to Secure Sockets\n Layer (SSL). Although the Oracle configuration parameters have names including\n SSL, such as SSL_VERSION and SSL_CIPHER_SUITES, they refer to TLS.\n \"\n impact 0.7\n tag \"gtitle\": 'SRG-APP-000178-DB-000083'\n tag \"gid\": 'V-61845'\n tag \"rid\": 'SV-76335r2_rule'\n tag \"stig_id\": 'O121-N1-015602'\n tag \"fix_id\": 'F-67761r4_fix'\n tag \"cci\": ['CCI-000366']\n tag \"nist\": ['CM-6 b', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"For Oracle SQL*Plus, which cannot be configured not to accept a\n plain-text password, and any other essential tool with the same limitation,\n verify that the system documentation explains the need for the tool, who uses\n it, and any relevant mitigations; and that AO approval has been obtained. If\n not, this is a finding.\n\n Request evidence that all users of the tool are trained in the importance of\n not using the plain-text password option and in how to keep the password\n hidden; and that they adhere to this practice. If not, this is a finding.\"\n tag \"fix\": \"For Oracle SQL*Plus, which cannot be configured not to accept a\n plain-text password, and any other essential tool with the same limitation:\n\n 1) Document the need for it, who uses it, and any relevant mitigations, and\n obtain AO approval.\n 2) Train all users of the tool in the importance of not using the plain-text\n password option and in how to keep the password hidden.\n\n - - - - -\n Consider wrapping the startup command with a shell or wrapper and using an\n Oracle external password store.\n\n Oracle provides the capability to provide for a secure external password\n facility. Use the Oracle mkstore to create a secure storage area for passwords\n for applications, batch jobs, and scripts to use or deploy a site-authorized\n facility to perform this function.\n\n Check to see what has been stored in the Oracle External Password Store.\n\n To view all contents of a client wallet external password store, check specific\n credentials by viewing them. Listing the external password store contents\n provides information used to decide whether to add or delete credentials from\n the store. To list the contents of the external password store, enter the\n following command at the command line:\n\n $ mkstore -wrl wallet_location -listCredential\n\n For example:\n\n $ mkstore -wrl c:\\\\oracle\\\\product\\\\12.1.0\\\\db_1\\\\wallets -listCredential\n\n The wallet_location specifies the path to the directory where the wallet, whose\n external password store contents is to be viewed, is located. This command\n lists all of the credential database service names (aliases) and the\n corresponding user name (schema) for that database. Passwords are not listed.\n\n Configuring Clients to Use the External Password Store\n\n If the client is already configured to use external authentication, such as\n Windows native authentication or Transport Layer Security (TLS), then Oracle\n Database uses that authentication method. The same credentials used for this\n type of authentication are typically also used to log on to the database.\n\n For clients not using such authentication methods or wanting to override them\n for database authentication, set the SQLNET.WALLET_OVERRIDE parameter in\n sqlnet.ora to TRUE. The default value for SQLNET.WALLET_OVERRIDE is FALSE,\n allowing standard use of authentication credentials as before.\n\n If wanting a client to use the secure external password store feature, then\n perform the following configuration task:\n\n 1. Create a wallet on the client by using the following syntax at the command\n line:\n orapki create -wallet wallet_location -auto_login_local\n\n For example:\n orapki wallet create -wallet c:\\\\oracle\\\\product\\\\12.1.0\\\\db_1\\\\wallets\n -auto_login_local\n Enter password: password\n\n The wallet_location is the path to the directory where the wallet is to be\n created and stored. This command creates an Oracle wallet with the autologon\n feature enabled at the location specified. The autologon feature enables the\n client to access the wallet contents without supplying a password.\n\n The mkstore utility -create option uses password complexity verification.\n\n 2. Create database connection credentials in the wallet by using the following\n syntax at the command line:\n mkstore -wrl wallet_location -createCredential db_connect_string username\n Enter password: password\n\n For example:\n mkstore -wrl c:\\\\oracle\\\\product\\\\12.1.0\\\\db_1\\\\wallets -createCredential\n oracle system\n Enter password: password\n\n In this specification:\n The wallet_location is the path to the directory where the wallet was created.\n The db_connect_string used in the CONNECT /@db_connect_string statement must be\n identical to the db_connect_string specified in the -createCredential command.\n\n The db_connect_string is the TNS alias used to specify the database in the\n tnsnames.ora file or any service name used to identify the database on an\n Oracle network. By default, tnsnames.ora is located in the\n $ORACLE_HOME/network/admin directory on UNIX systems and in ORACLE_HOME\\\n etwork\\\\admin on Windows.\n\n The username is the database logon credential. When prompted, enter the\n password for this user.\n\n 3. In the client sqlnet.ora file, enter the WALLET_LOCATION parameter and set\n it to the directory location of the wallet created in Step 1. For example, if\n the wallet was created in $ORACLE_HOME/network/admin and the Oracle home is set\n to /private/ora12, then need to enter the following into the client sqlnet.ora\n file:\n\n WALLET_LOCATION =\n (SOURCE =\n (METHOD = FILE)\n (METHOD_DATA =\n (DIRECTORY = /private/ora12/network/admin)\n )\n )\n\n 4. In the client sqlnet.ora file, enter the SQLNET.WALLET_OVERRIDE parameter\n and set it to TRUE as follows:\n\n SQLNET.WALLET_OVERRIDE = TRUE\n\n This setting causes all CONNECT /@db_connect_string statements to use the\n information in the wallet at the specified location to authenticate to\n databases.\n\n When external authentication is in use, an authenticated user with such a\n wallet can use the CONNECT /@db_connect_string syntax to access the previously\n specified databases without providing a user name and password. However, if a\n user fails that external authentication, then these connect statements also\n fail.\n\n Below is a sample sqlnet.ora file with the WALLET_LOCATION and the\n SQLNET.WALLET_OVERRIDE parameters set as described in Steps 3 and 4.\n\n Below is a sample SQLNET.ORA File with Wallet Parameters Set\n\n WALLET_LOCATION =\n (SOURCE =\n (METHOD = FILE)\n (METHOD_DATA =\n (DIRECTORY = /private/ora12/network/admin)\n )\n )\n\n SQLNET.WALLET_OVERRIDE = TRUE\n SSL_CLIENT_AUTHENTICATION = FALSE\n SSL_VERSION =1.2 or 1.1\n\n (Note: This assumes that a single sqlnet.ora file, in the default location, is\n in use. Please see the supplemental file Non-default sqlnet.ora\n configurations.pdf for how to find multiple and/or differently located\n sqlnet.ora files.)\n\n Note: SSL_VERSION = 1.2 or 1.1 is the actual value, not a suggestion to\n use one or the other.\"\n describe 'A manual review is required to ensure when using command-line tools such as Oracle SQL*Plus, which can\n accept a plain-text password, users must use an alternative logon method that\n does not expose the password' do\n skip 'A manual review is required to ensure when using command-line tools such as Oracle SQL*Plus, which can\n accept a plain-text password, users must use an alternative logon method that\n does not expose the password'\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61409.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61845.rb", "line": 1 }, - "id": "V-61409" + "id": "V-61845" }, { - "title": "The DBMS must support taking organization-defined list of least\n disruptive actions to terminate suspicious events.", - "desc": "System availability is a key tenet of system security. Organizations\n need to have the flexibility to be able to define the automated actions taken\n in response to an identified incident. This includes being able to define a\n least disruptive action the application takes to terminate suspicious events. A\n least disruptive action may include initiating a request for human response\n rather than blocking traffic or disrupting system operation.\n\n In order to preserve availability, it is important for the DBMS to\n terminate suspicious events with the least disruptive action possible. If\n suspicious events are not terminated, an attacker may gain entry into the\n system; however, if the system overreacts to a suspicious event and takes an\n overly disruptive action, a Denial of Service (DoS) may occur.", + "title": "A single database connection configuration file must not be used to\n configure all database clients.", + "desc": "Applications employ the concept of least privilege for specific duties\n and information systems (including specific functions, ports, protocols, and\n services). The concept of least privilege is also applied to information system\n processes, ensuring that the processes operate at privilege levels no higher\n than necessary to accomplish required organizational missions and/or functions.\n Organizations consider the creation of additional processes, roles, and\n information system accounts as necessary to achieve least privilege.\n Organizations also apply least privilege concepts to the design, development,\n implementation, and operations of information systems.\n\n Many sites distribute a single client database connection configuration\n file to all site database users that contains network access information for\n all databases on the site. Such a file provides information to access databases\n not required by all users that may assist in unauthorized access attempts.", "descriptions": { - "default": "System availability is a key tenet of system security. Organizations\n need to have the flexibility to be able to define the automated actions taken\n in response to an identified incident. This includes being able to define a\n least disruptive action the application takes to terminate suspicious events. A\n least disruptive action may include initiating a request for human response\n rather than blocking traffic or disrupting system operation.\n\n In order to preserve availability, it is important for the DBMS to\n terminate suspicious events with the least disruptive action possible. If\n suspicious events are not terminated, an attacker may gain entry into the\n system; however, if the system overreacts to a suspicious event and takes an\n overly disruptive action, a Denial of Service (DoS) may occur." + "default": "Applications employ the concept of least privilege for specific duties\n and information systems (including specific functions, ports, protocols, and\n services). The concept of least privilege is also applied to information system\n processes, ensuring that the processes operate at privilege levels no higher\n than necessary to accomplish required organizational missions and/or functions.\n Organizations consider the creation of additional processes, roles, and\n information system accounts as necessary to achieve least privilege.\n Organizations also apply least privilege concepts to the design, development,\n implementation, and operations of information systems.\n\n Many sites distribute a single client database connection configuration\n file to all site database users that contains network access information for\n all databases on the site. Such a file provides information to access databases\n not required by all users that may assist in unauthorized access attempts." }, "impact": 0.5, "refs": [], "tags": { - "gtitle": "SRG-APP-000287-DB-000126", - "gid": "V-61795", - "rid": "SV-76285r1_rule", - "stig_id": "O121-C2-020300", - "fix_id": "F-67711r1_fix", + "gtitle": "SRG-APP-000062-DB-000012", + "gid": "V-61583", + "rid": "SV-76073r1_rule", + "stig_id": "O121-C2-003600", + "fix_id": "F-67499r1_fix", "cci": [ - "CCI-001670" + "CCI-000366", + "CCI-002220" ], "nist": [ - "SI-4 (7)", + "AC-5 c", "Rev_4" ], "false_negatives": null, @@ -2632,35 +2712,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Obtain the CC/S/A/FA's list of suspicious event types and the\n actions to be taken in response, ordered from least disruptive to last resort.\n\n If the list does not exist, this is a finding.\n\n For each event type in the list, review the measures in place in the\n DBMS/database configuration that are designed to detect and/or counter the\n event. (Alerting an administrator or operator to the problem is a valid\n measure.)\n\n If, for any event type defined in the list, no means of detecting the event\n exists, this is a finding.\n\n For each event type where an automatic countermeasure is defined, verify that\n its implementation is congruent with the list of defined actions. If not, this\n is a finding.\n\n Verify that administrators/operators are familiar with the list and the\n notification mechanism and are equipped to follow the instructions in the list.\n If not, this is a finding.", - "fix": "If the list does not exist, create it.\n\n For any event type defined in the list where no means of detecting the event\n exists, either create the means of detection or modify the list.\n\n For each event type where an automatic countermeasure is defined but its\n implementation differs from its description in the list, either modify the\n countermeasure or amend the list.\n\n If any administrators/operators are unfamiliar with the list or the\n notification mechanism, train them.\n\n If any administrators/operators are not equipped to follow the instructions in\n the list, provide them with the means to do so.\n\n Ensure the list is incorporated into, or referenced by, the System Security\n Plan.\n\n Note that Oracle Audit Vault and Oracle Database Vault are optional products\n that can be of considerable use in implementing active protection measures of\n this kind." + "check": "Review procedures for providing database connection information\n to users/user workstations. If procedures do not indicate or implement\n restrictions to connections required by the particular user, this is a finding.\n\n Note: This check is specific for the DBMS host system and not directed at\n client systems (client systems are included in the Application STIG/Checklist);\n however, detection of unauthorized client connections to the DBMS host system\n obtained through log files should be performed regularly and documented where\n authorized.", + "fix": "Implement procedures to supply database connection information to\n only those databases authorized for the user." }, - "code": "control 'V-61795' do\n title \"The DBMS must support taking organization-defined list of least\n disruptive actions to terminate suspicious events.\"\n desc \"System availability is a key tenet of system security. Organizations\n need to have the flexibility to be able to define the automated actions taken\n in response to an identified incident. This includes being able to define a\n least disruptive action the application takes to terminate suspicious events. A\n least disruptive action may include initiating a request for human response\n rather than blocking traffic or disrupting system operation.\n\n In order to preserve availability, it is important for the DBMS to\n terminate suspicious events with the least disruptive action possible. If\n suspicious events are not terminated, an attacker may gain entry into the\n system; however, if the system overreacts to a suspicious event and takes an\n overly disruptive action, a Denial of Service (DoS) may occur.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000287-DB-000126'\n tag \"gid\": 'V-61795'\n tag \"rid\": 'SV-76285r1_rule'\n tag \"stig_id\": 'O121-C2-020300'\n tag \"fix_id\": 'F-67711r1_fix'\n tag \"cci\": ['CCI-001670']\n tag \"nist\": ['SI-4 (7)', '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\": \"Obtain the CC/S/A/FA's list of suspicious event types and the\n actions to be taken in response, ordered from least disruptive to last resort.\n\n If the list does not exist, this is a finding.\n\n For each event type in the list, review the measures in place in the\n DBMS/database configuration that are designed to detect and/or counter the\n event. (Alerting an administrator or operator to the problem is a valid\n measure.)\n\n If, for any event type defined in the list, no means of detecting the event\n exists, this is a finding.\n\n For each event type where an automatic countermeasure is defined, verify that\n its implementation is congruent with the list of defined actions. If not, this\n is a finding.\n\n Verify that administrators/operators are familiar with the list and the\n notification mechanism and are equipped to follow the instructions in the list.\n If not, this is a finding.\"\n tag \"fix\": \"If the list does not exist, create it.\n\n For any event type defined in the list where no means of detecting the event\n exists, either create the means of detection or modify the list.\n\n For each event type where an automatic countermeasure is defined but its\n implementation differs from its description in the list, either modify the\n countermeasure or amend the list.\n\n If any administrators/operators are unfamiliar with the list or the\n notification mechanism, train them.\n\n If any administrators/operators are not equipped to follow the instructions in\n the list, provide them with the means to do so.\n\n Ensure the list is incorporated into, or referenced by, the System Security\n Plan.\n\n Note that Oracle Audit Vault and Oracle Database Vault are optional products\n that can be of considerable use in implementing active protection measures of\n this kind.\"\n describe 'A manual review is required to ensure the DBMS supports taking organization-defined list of least\n disruptive actions to terminate suspicious events.' do\n skip 'A manual review is required to ensure the DBMS supports taking organization-defined list of least\n disruptive actions to terminate suspicious events.'\n end\nend\n", + "code": "control 'V-61583' do\n title \"A single database connection configuration file must not be used to\n configure all database clients.\"\n desc \"Applications employ the concept of least privilege for specific duties\n and information systems (including specific functions, ports, protocols, and\n services). The concept of least privilege is also applied to information system\n processes, ensuring that the processes operate at privilege levels no higher\n than necessary to accomplish required organizational missions and/or functions.\n Organizations consider the creation of additional processes, roles, and\n information system accounts as necessary to achieve least privilege.\n Organizations also apply least privilege concepts to the design, development,\n implementation, and operations of information systems.\n\n Many sites distribute a single client database connection configuration\n file to all site database users that contains network access information for\n all databases on the site. Such a file provides information to access databases\n not required by all users that may assist in unauthorized access attempts.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000062-DB-000012'\n tag \"gid\": 'V-61583'\n tag \"rid\": 'SV-76073r1_rule'\n tag \"stig_id\": 'O121-C2-003600'\n tag \"fix_id\": 'F-67499r1_fix'\n tag \"cci\": ['CCI-000366', 'CCI-002220']\n tag \"nist\": ['CM-6 b', 'Rev_4']\n tag \"nist\": ['AC-5 c', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Review procedures for providing database connection information\n to users/user workstations. If procedures do not indicate or implement\n restrictions to connections required by the particular user, this is a finding.\n\n Note: This check is specific for the DBMS host system and not directed at\n client systems (client systems are included in the Application STIG/Checklist);\n however, detection of unauthorized client connections to the DBMS host system\n obtained through log files should be performed regularly and documented where\n authorized.\"\n tag \"fix\": \"Implement procedures to supply database connection information to\n only those databases authorized for the user.\"\n describe 'A manual review is required to ensure a single database connection configuration file is not used to\n configure all database clients' do\n skip 'A manual review is required to ensure a single database connection configuration file is not used to\n configure all database clients'\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61795.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61583.rb", "line": 1 }, - "id": "V-61795" + "id": "V-61583" }, { - "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.", + "title": "The DBMS must isolate security functions from nonsecurity functions by\n means of separate security domains.", + "desc": "Security functions are defined as \"the hardware, software, and/or\n firmware of the information system responsible for enforcing the system\n security policy and supporting the isolation of code and data on which the\n protection is based\".\n\n Developers and implementers can increase the assurance in security\n functions by employing well-defined security policy models, structured,\n disciplined, and rigorous hardware and software development techniques, and\n sound system/security engineering principles.\n\n Database Management Systems typically separate security functionality from\n non-security functionality via separate databases or schemas. Database objects\n or code implementing security functionality must not be commingled with objects\n or code implementing application logic. When security and non-security\n functionality is commingled, users who have access to non-security\n functionality may be able to access security functionality.", "descriptions": { - "default": "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." + "default": "Security functions are defined as \"the hardware, software, and/or\n firmware of the information system responsible for enforcing the system\n security policy and supporting the isolation of code and data on which the\n protection is based\".\n\n Developers and implementers can increase the assurance in security\n functions by employing well-defined security policy models, structured,\n disciplined, and rigorous hardware and software development techniques, and\n sound system/security engineering principles.\n\n Database Management Systems typically separate security functionality from\n non-security functionality via separate databases or schemas. Database objects\n or code implementing security functionality must not be commingled with objects\n or code implementing application logic. When security and non-security\n functionality is commingled, users who have access to non-security\n functionality may be able to access security functionality." }, "impact": 0.5, "refs": [], "tags": { - "gtitle": "SRG-APP-000516-DB-999900", - "gid": "V-61527", - "rid": "SV-76017r4_rule", - "stig_id": "O121-BP-026200", - "fix_id": "F-67443r2_fix", + "gtitle": "SRG-APP-000233-DB-000124", + "gid": "V-61775", + "rid": "SV-76265r1_rule", + "stig_id": "O121-C2-018500", + "fix_id": "F-67691r1_fix", "cci": [ - "CCI-000366" + "CCI-001084" ], "nist": [ - "CM-6 b", + "SC-3", "Rev_4" ], "false_negatives": null, @@ -2673,30 +2753,34 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "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" + "check": "Check DBMS settings to determine whether objects or code\n implementing security functionality are located in a separate security domain,\n such as a separate database or schema created specifically for security\n functionality.\n\n If security-related database objects or code are not kept separate, this is a\n finding.\n\n The Oracle elements of security functionality, such as the roles, permissions,\n and profiles, along with password complexity requirements, are stored in\n separate schemas in the database. Review any site-specific applications\n security modules built into the database and determine what schema they are\n located in and take appropriate action. The Oracle objects will be in the\n Oracle Data Dictionary.", + "fix": "Locate security-related database objects and code in a separate\n database, schema, or other separate security domain from database objects and\n code implementing application logic. (This is the default behavior for\n Oracle.) Review any site-specific applications security modules built into the\n database: determine what schema they are located in and take appropriate\n action." }, - "code": "control 'V-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", + "code": "control 'V-61775' do\n title \"The DBMS must isolate security functions from nonsecurity functions by\n means of separate security domains.\"\n desc \"Security functions are defined as \\\"the hardware, software, and/or\n firmware of the information system responsible for enforcing the system\n security policy and supporting the isolation of code and data on which the\n protection is based\\\".\n\n Developers and implementers can increase the assurance in security\n functions by employing well-defined security policy models, structured,\n disciplined, and rigorous hardware and software development techniques, and\n sound system/security engineering principles.\n\n Database Management Systems typically separate security functionality from\n non-security functionality via separate databases or schemas. Database objects\n or code implementing security functionality must not be commingled with objects\n or code implementing application logic. When security and non-security\n functionality is commingled, users who have access to non-security\n functionality may be able to access security functionality.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000233-DB-000124'\n tag \"gid\": 'V-61775'\n tag \"rid\": 'SV-76265r1_rule'\n tag \"stig_id\": 'O121-C2-018500'\n tag \"fix_id\": 'F-67691r1_fix'\n tag \"cci\": ['CCI-001084']\n tag \"nist\": ['SC-3', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Check DBMS settings to determine whether objects or code\n implementing security functionality are located in a separate security domain,\n such as a separate database or schema created specifically for security\n functionality.\n\n If security-related database objects or code are not kept separate, this is a\n finding.\n\n The Oracle elements of security functionality, such as the roles, permissions,\n and profiles, along with password complexity requirements, are stored in\n separate schemas in the database. Review any site-specific applications\n security modules built into the database and determine what schema they are\n located in and take appropriate action. The Oracle objects will be in the\n Oracle Data Dictionary.\"\n tag \"fix\": \"Locate security-related database objects and code in a separate\n database, schema, or other separate security domain from database objects and\n code implementing application logic. (This is the default behavior for\n Oracle.) Review any site-specific applications security modules built into the\n database: determine what schema they are located in and take appropriate\n action.\"\n describe 'A manual review is required to ensure the DBMS isolates security functions from nonsecurity functions by\n means of separate security domains' do\n skip 'A manual review is required to ensure the DBMS isolates security functions from nonsecurity functions by\n means of separate security domains'\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61527.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61775.rb", "line": 1 }, - "id": "V-61527" + "id": "V-61775" }, { - "title": "Disk space used by audit trail(s) must be monitored; audit records\n must be regularly or continuously off-loaded to a centralized log management\n system.", - "desc": "It is critical when a system is at risk of failing to process audit\n logs as required; it detects and takes action to mitigate the failure. Audit\n processing failures include: software/hardware errors, failures in the audit\n capturing mechanisms, and audit storage capacity being reached or exceeded.\n Applications are required to be capable of either directly performing or\n calling system-level functionality performing defined actions upon detection of\n an application audit log processing failure.\n\n The Security Requirements Guide says, \"A failure of database auditing will\n result in either the database continuing to function without auditing or in a\n complete halt to database operations. The database must be capable of taking\n organization-defined actions to avoid either a complete halt to processing or\n processing transactions in an unaudited manner.\"\n\n This STIG requirement mandates the implementation of a method to mitigate\n Oracle's inability to automatically reuse audit trail space on a first-in,\n first-out basis.", + "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.", "descriptions": { - "default": "It is critical when a system is at risk of failing to process audit\n logs as required; it detects and takes action to mitigate the failure. Audit\n processing failures include: software/hardware errors, failures in the audit\n capturing mechanisms, and audit storage capacity being reached or exceeded.\n Applications are required to be capable of either directly performing or\n calling system-level functionality performing defined actions upon detection of\n an application audit log processing failure.\n\n The Security Requirements Guide says, \"A failure of database auditing will\n result in either the database continuing to function without auditing or in a\n complete halt to database operations. The database must be capable of taking\n organization-defined actions to avoid either a complete halt to processing or\n processing transactions in an unaudited manner.\"\n\n This STIG requirement mandates the implementation of a method to mitigate\n Oracle's inability to automatically reuse audit trail space on a first-in,\n first-out basis." + "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." }, - "impact": 0.5, - "refs": [], + "impact": 0, + "refs": [ + { + "ref": [] + } + ], "tags": { - "gtitle": "SRG-APP-000109-DB-000049", - "gid": "V-61853", - "rid": "SV-76343r1_rule", - "stig_id": "O121-N2-008601", - "fix_id": "F-67769r1_fix", + "gtitle": "SRG-APP-000516-DB-999900", + "gid": "V-61531", + "rid": "SV-76021r2_rule", + "stig_id": "O121-BP-026400", + "fix_id": "F-67447r2_fix", "cci": [ "CCI-000366" ], @@ -2714,35 +2798,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Review the procedures, manual and/or automated, for monitoring\n the space used by audit trail(s) and for off-loading audit records to a\n centralized log management system.\n\n If the procedures do not exist, this is a finding.\n\n If the procedures exist, request evidence that they are followed. If the\n evidence indicates that the procedures are not followed, this is a finding.\n\n If the procedures exist, inquire if the system has ever run out of audit trail\n space in the last two years or since the last system upgrade, whichever is more\n recent. If it has run out of space in this period, and the procedures have not\n been updated to compensate, this is a finding.", - "fix": "Modify DBMS, OS, or third-party logging application settings to\n alert appropriate personnel when a specific percentage of log storage capacity\n is reached.\n\n For ease of management, it is recommended that the audit tables be kept in a\n dedicated tablespace.\n\n If Oracle Enterprise Manager is in use, the capability to issue such an alert\n is built in and configurable via the console so an email can be sent to a\n designated administrator.\n\n If Enterprise Manager is unavailable, the following script can be used to\n monitor storage space; this can be combined with additional code to email the\n appropriate administrator so they can take action.\n\n sqlplus connect as sysdba\n\n set pagesize 300\n set linesize 120\n column sumb format 9,999,999,999,999\n column extents format 999999\n column bytes format 9,999,999,999,999\n column largest format 9,999,999,999,999\n column Tot_Size format 9,999,999,999,999\n column Tot_Free format 9,999,999,999,999\n column Pct_Free format 9,999,999,999,999\n column Chunks_Free format 9,999,999,999,999\n column Max_Free format 9,999,999,999,999\n set echo off\n spool TSINFO.txt\n PROMPT SPACE AVAILABLE IN TABLESPACES\n select a.tablespace_name,sum(a.tots) Tot_Size,\n sum(a.sumb) Tot_Free,\n sum(a.sumb)*100/sum(a.tots) Pct_Free,\n sum(a.largest) Max_Free,sum(a.chunks) Chunks_Free\n from\n (\n select tablespace_name,0 tots,sum(bytes) sumb,\n max(bytes) largest,count(*) chunks\n from dba_free_space a\n group by tablespace_name\n union\n select tablespace_name,sum(bytes) tots,0,0,0 from\n dba_data_files\n group by tablespace_name) a\n group by a.tablespace_name;\n\n Sample Output\n\n SPACE AVAILABLE IN TABLESPACES\n\n TABLESPACE_NAME TOT_SIZE TOT_FREE PCT_FREE\n MAX_FREE CHUNKS_FREE\n ------------------------------ ------------ ------------ ------------\n ------------ ------------\n DES2 41,943,040 30,935,040 74\n 30,935,040 1\n DES2_I 31,457,280 23,396,352 74\n 23,396,352 1\n RBS 60,817,408 57,085,952 94\n 52,426,752 16\n SYSTEM 94,371,840 5,386,240 6\n 5,013,504 3\n TEMP 563,200 561,152 100\n 133,120 5\n TOOLS 120,586,240 89,407,488 74\n 78,190,592 12\n USERS 1,048,576 26,624 3\n 26,624 1" + "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." }, - "code": "control 'V-61853' do\n title \"Disk space used by audit trail(s) must be monitored; audit records\n must be regularly or continuously off-loaded to a centralized log management\n system.\"\n desc \"It is critical when a system is at risk of failing to process audit\n logs as required; it detects and takes action to mitigate the failure. Audit\n processing failures include: software/hardware errors, failures in the audit\n capturing mechanisms, and audit storage capacity being reached or exceeded.\n Applications are required to be capable of either directly performing or\n calling system-level functionality performing defined actions upon detection of\n an application audit log processing failure.\n\n The Security Requirements Guide says, \\\"A failure of database auditing will\n result in either the database continuing to function without auditing or in a\n complete halt to database operations. The database must be capable of taking\n organization-defined actions to avoid either a complete halt to processing or\n processing transactions in an unaudited manner.\\\"\n\n This STIG requirement mandates the implementation of a method to mitigate\n Oracle's inability to automatically reuse audit trail space on a first-in,\n first-out basis.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000109-DB-000049'\n tag \"gid\": 'V-61853'\n tag \"rid\": 'SV-76343r1_rule'\n tag \"stig_id\": 'O121-N2-008601'\n tag \"fix_id\": 'F-67769r1_fix'\n tag \"cci\": ['CCI-000366']\n tag \"nist\": ['CM-6 b', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Review the procedures, manual and/or automated, for monitoring\n the space used by audit trail(s) and for off-loading audit records to a\n centralized log management system.\n\n If the procedures do not exist, this is a finding.\n\n If the procedures exist, request evidence that they are followed. If the\n evidence indicates that the procedures are not followed, this is a finding.\n\n If the procedures exist, inquire if the system has ever run out of audit trail\n space in the last two years or since the last system upgrade, whichever is more\n recent. If it has run out of space in this period, and the procedures have not\n been updated to compensate, this is a finding.\"\n tag \"fix\": \"Modify DBMS, OS, or third-party logging application settings to\n alert appropriate personnel when a specific percentage of log storage capacity\n is reached.\n\n For ease of management, it is recommended that the audit tables be kept in a\n dedicated tablespace.\n\n If Oracle Enterprise Manager is in use, the capability to issue such an alert\n is built in and configurable via the console so an email can be sent to a\n designated administrator.\n\n If Enterprise Manager is unavailable, the following script can be used to\n monitor storage space; this can be combined with additional code to email the\n appropriate administrator so they can take action.\n\n sqlplus connect as sysdba\n\n set pagesize 300\n set linesize 120\n column sumb format 9,999,999,999,999\n column extents format 999999\n column bytes format 9,999,999,999,999\n column largest format 9,999,999,999,999\n column Tot_Size format 9,999,999,999,999\n column Tot_Free format 9,999,999,999,999\n column Pct_Free format 9,999,999,999,999\n column Chunks_Free format 9,999,999,999,999\n column Max_Free format 9,999,999,999,999\n set echo off\n spool TSINFO.txt\n PROMPT SPACE AVAILABLE IN TABLESPACES\n select a.tablespace_name,sum(a.tots) Tot_Size,\n sum(a.sumb) Tot_Free,\n sum(a.sumb)*100/sum(a.tots) Pct_Free,\n sum(a.largest) Max_Free,sum(a.chunks) Chunks_Free\n from\n (\n select tablespace_name,0 tots,sum(bytes) sumb,\n max(bytes) largest,count(*) chunks\n from dba_free_space a\n group by tablespace_name\n union\n select tablespace_name,sum(bytes) tots,0,0,0 from\n dba_data_files\n group by tablespace_name) a\n group by a.tablespace_name;\n\n Sample Output\n\n SPACE AVAILABLE IN TABLESPACES\n\n TABLESPACE_NAME TOT_SIZE TOT_FREE PCT_FREE\n MAX_FREE CHUNKS_FREE\n ------------------------------ ------------ ------------ ------------\n ------------ ------------\n DES2 41,943,040 30,935,040 74\n 30,935,040 1\n DES2_I 31,457,280 23,396,352 74\n 23,396,352 1\n RBS 60,817,408 57,085,952 94\n 52,426,752 16\n SYSTEM 94,371,840 5,386,240 6\n 5,013,504 3\n TEMP 563,200 561,152 100\n 133,120 5\n TOOLS 120,586,240 89,407,488 74\n 78,190,592 12\n USERS 1,048,576 26,624 3\n 26,624 1\"\n describe 'A manual review is required to ensure the Disk space used by audit trail(s) is monitored, and that audit records\n are regularly or continuously off-loaded to a centralized log management system' do\n skip 'A manual review is required to ensure the Disk space used by audit trail(s) is monitored, and that audit records\n are regularly or continuously off-loaded to a centralized log management system'\n end\nend\n", + "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", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61853.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61531.rb", "line": 1 }, - "id": "V-61853" + "id": "V-61531" }, { - "title": "The DBMS must separate user functionality (including user interface\n services) from database management functionality.", - "desc": "Information system management functionality includes functions\n necessary to administer databases, network components, workstations, or\n servers, and typically requires privileged user access.\n\n The separation of user functionality from information system management\n functionality is either physical or logical and is accomplished by using\n different computers, different central processing units, different instances of\n the operating system, different network addresses, combinations of these\n methods, or other methods, as appropriate.\n\n An example of this type of separation is observed in web administrative\n interfaces that use separate authentication methods for users of any other\n information system resources.\n\n This may include isolating the administrative interface on a different\n domain and with additional access controls.\n\n If administrative functionality or information regarding DBMS management is\n presented on an interface available for users, information on DBMS settings may\n be inadvertently made available to the user.", + "title": "Logic modules within the database (to include packages, procedures,\n functions and triggers) must be monitored to discover unauthorized changes.", + "desc": "Any changes to the hardware, software, and/or firmware components of\n the information system and/or application can potentially have significant\n effects on the overall security of the system. This includes the logic modules\n implemented within the database, such as packages, procedures, functions and\n triggers.\n\n If the DBMS were to allow any user to make changes to these, then those\n changes might be implemented without undergoing the appropriate testing and\n approvals that are part of a robust change management process.\n\n Accordingly, only qualified and authorized individuals shall be allowed to\n obtain access to information system components for purposes of initiating\n changes, including upgrades and modifications.\n\n Unmanaged changes that occur to the database logic modules can lead to\n unauthorized or compromised installations.", "descriptions": { - "default": "Information system management functionality includes functions\n necessary to administer databases, network components, workstations, or\n servers, and typically requires privileged user access.\n\n The separation of user functionality from information system management\n functionality is either physical or logical and is accomplished by using\n different computers, different central processing units, different instances of\n the operating system, different network addresses, combinations of these\n methods, or other methods, as appropriate.\n\n An example of this type of separation is observed in web administrative\n interfaces that use separate authentication methods for users of any other\n information system resources.\n\n This may include isolating the administrative interface on a different\n domain and with additional access controls.\n\n If administrative functionality or information regarding DBMS management is\n presented on an interface available for users, information on DBMS settings may\n be inadvertently made available to the user." + "default": "Any changes to the hardware, software, and/or firmware components of\n the information system and/or application can potentially have significant\n effects on the overall security of the system. This includes the logic modules\n implemented within the database, such as packages, procedures, functions and\n triggers.\n\n If the DBMS were to allow any user to make changes to these, then those\n changes might be implemented without undergoing the appropriate testing and\n approvals that are part of a robust change management process.\n\n Accordingly, only qualified and authorized individuals shall be allowed to\n obtain access to information system components for purposes of initiating\n changes, including upgrades and modifications.\n\n Unmanaged changes that occur to the database logic modules can lead to\n unauthorized or compromised installations." }, "impact": 0.5, "refs": [], "tags": { - "gtitle": "SRG-APP-000211-DB-000122", - "gid": "V-61883", - "rid": "SV-76373r1_rule", - "stig_id": "O121-P2-017300", - "fix_id": "F-67799r1_fix", + "gtitle": "SRG-APP-000133-DB-000179", + "gid": "V-68863", + "rid": "SV-83467r1_rule", + "stig_id": "O121-OS-010710", + "fix_id": "F-75045r1_fix", "cci": [ - "CCI-001082" + "CCI-001499" ], "nist": [ - "SC-2", + "CM-5 (6)", "Rev_4" ], "false_negatives": null, @@ -2755,35 +2839,39 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Check DBMS settings and vendor documentation to verify\n administrative functionality is separate from user functionality.\n\n If administrator and general user functionality is not separated either\n physically or logically, this is a finding.", - "fix": "Configure DBMS settings to separate database administration and\n general user functionality. Provide those who have both administrative and\n general-user responsibilities with separate accounts for these separate\n functions." + "check": "Review monitoring procedures and implementation evidence to\n verify that monitoring of changes to database logic modules is done.\n\n Verify the list of objects (packages, procedures, functions, and triggers)\n being monitored is complete. If monitoring does not occur or is not complete,\n this is a finding.", + "fix": "Implement procedures to monitor for unauthorized changes to\n database logic modules. If a third-party automated tool is not employed, an\n automated job that reports on the objects of interest and compares them to the\n baseline report for the same will meet the requirement." }, - "code": "control 'V-61883' do\n title \"The DBMS must separate user functionality (including user interface\n services) from database management functionality.\"\n desc \"Information system management functionality includes functions\n necessary to administer databases, network components, workstations, or\n servers, and typically requires privileged user access.\n\n The separation of user functionality from information system management\n functionality is either physical or logical and is accomplished by using\n different computers, different central processing units, different instances of\n the operating system, different network addresses, combinations of these\n methods, or other methods, as appropriate.\n\n An example of this type of separation is observed in web administrative\n interfaces that use separate authentication methods for users of any other\n information system resources.\n\n This may include isolating the administrative interface on a different\n domain and with additional access controls.\n\n If administrative functionality or information regarding DBMS management is\n presented on an interface available for users, information on DBMS settings may\n be inadvertently made available to the user.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000211-DB-000122'\n tag \"gid\": 'V-61883'\n tag \"rid\": 'SV-76373r1_rule'\n tag \"stig_id\": 'O121-P2-017300'\n tag \"fix_id\": 'F-67799r1_fix'\n tag \"cci\": ['CCI-001082']\n tag \"nist\": ['SC-2', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Check DBMS settings and vendor documentation to verify\n administrative functionality is separate from user functionality.\n\n If administrator and general user functionality is not separated either\n physically or logically, this is a finding.\"\n tag \"fix\": \"Configure DBMS settings to separate database administration and\n general user functionality. Provide those who have both administrative and\n general-user responsibilities with separate accounts for these separate\n functions.\"\n describe 'A manual review is required to ensure the DBMS separates user functionality (including user interface\n services) from database management functionality' do\n skip 'A manual review is required to ensure the DBMS separates user functionality (including user interface\n services) from database management functionality'\n end\nend\n", + "code": "control 'V-68863' do\n title \"Logic modules within the database (to include packages, procedures,\n functions and triggers) must be monitored to discover unauthorized changes.\"\n desc \"Any changes to the hardware, software, and/or firmware components of\n the information system and/or application can potentially have significant\n effects on the overall security of the system. This includes the logic modules\n implemented within the database, such as packages, procedures, functions and\n triggers.\n\n If the DBMS were to allow any user to make changes to these, then those\n changes might be implemented without undergoing the appropriate testing and\n approvals that are part of a robust change management process.\n\n Accordingly, only qualified and authorized individuals shall be allowed to\n obtain access to information system components for purposes of initiating\n changes, including upgrades and modifications.\n\n Unmanaged changes that occur to the database logic modules can lead to\n unauthorized or compromised installations.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000133-DB-000179'\n tag \"gid\": 'V-68863'\n tag \"rid\": 'SV-83467r1_rule'\n tag \"stig_id\": 'O121-OS-010710'\n tag \"fix_id\": 'F-75045r1_fix'\n tag \"cci\": ['CCI-001499']\n tag \"nist\": ['CM-5 (6)', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Review monitoring procedures and implementation evidence to\n verify that monitoring of changes to database logic modules is done.\n\n Verify the list of objects (packages, procedures, functions, and triggers)\n being monitored is complete. If monitoring does not occur or is not complete,\n this is a finding.\"\n tag \"fix\": \"Implement procedures to monitor for unauthorized changes to\n database logic modules. If a third-party automated tool is not employed, an\n automated job that reports on the objects of interest and compares them to the\n baseline report for the same will meet the requirement.\"\n describe 'A manual review is required to ensure the logic modules within the database (to include packages, procedures,\n functions and triggers) are monitored to discover unauthorized changes' do\n skip 'A manual review is required to ensure the logic modules within the database (to include packages, procedures,\n functions and triggers) are monitored to discover unauthorized changes'\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61883.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-68863.rb", "line": 1 }, - "id": "V-61883" + "id": "V-68863" }, { - "title": "The DBMS must prevent unauthorized and unintended information transfer\n via shared system resources.", - "desc": "The purpose of this control is to prevent information, including\n encrypted representations of information, produced by the actions of a prior\n user/role (or the actions of a process acting on behalf of a prior user/role)\n from being available to any current user/role (or current process) that obtains\n access to a shared system resource (e.g., registers, main memory, secondary\n storage) after the resource has been released back to the information system.\n Control of information in shared resources is also referred to as object reuse.\n\n Data used for the development and testing of applications often involves\n copying data from production. It is important that specific procedures exist\n for this process, so copies of sensitive data are not misplaced or left in a\n temporary location without the proper controls.", + "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": "The purpose of this control is to prevent information, including\n encrypted representations of information, produced by the actions of a prior\n user/role (or the actions of a process acting on behalf of a prior user/role)\n from being available to any current user/role (or current process) that obtains\n access to a shared system resource (e.g., registers, main memory, secondary\n storage) after the resource has been released back to the information system.\n Control of information in shared resources is also referred to as object reuse.\n\n Data used for the development and testing of applications often involves\n copying data from production. It is important that specific procedures exist\n for this process, so copies of sensitive data are not misplaced or left in a\n temporary location without the proper controls." + "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.5, - "refs": [], + "impact": 0, + "refs": [ + { + "ref": [] + } + ], "tags": { - "gtitle": "SRG-APP-000243-DB-000128", - "gid": "V-61781", - "rid": "SV-76271r1_rule", - "stig_id": "O121-C2-018900", - "fix_id": "F-67697r1_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-001090" + "CCI-000366" ], "nist": [ - "SC-4", + "CM-6 b", "Rev_4" ], "false_negatives": null, @@ -2796,35 +2884,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Verify there are proper procedures in place for the refreshing\n of development/test data from production. Review any scripts or code that\n exists for the movement of production data to development/test, and verify\n copies of production data are not left in unprotected locations.\n\n If there is no documented procedure for data movement from production to\n development/test, this is a finding.\n\n If the code that exists for data movement does not remove any copies of\n production data from unprotected locations, this is a finding.", - "fix": "Create and document a process for moving data from production to\n development/test systems, and follow the process.\n\n Modify any code used for moving data from production to development/test\n systems to ensure copies of production data are not left in nonsecured\n locations.\n\n Moving data is only a part of the challenge of protecting the data. When the\n data is moved, it should also be changed so sensitive information is not made\n available in development environments.\n\n With the Oracle Data Masking Pack for Oracle Enterprise Manager, organizations\n can comply with data privacy and protection mandates that restrict the use of\n actual customer data. With Oracle Data Masking Pack, sensitive information,\n such as credit card or social security numbers, can be replaced with realistic\n values, allowing production data to be safely used for development, testing, or\n sharing with out-source or off-shore partners for other nonproduction purposes.\n When used in conjunction with Oracle Enterprise Manager, it is easy to develop\n a secure process that is capable of obfuscating the data during the movement\n process.\n\n If the Oracle Data Masking Pack and Enterprise Manager are not available,\n develop site-specific procedures to manage and obfuscate sensitive 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-61781' do\n title \"The DBMS must prevent unauthorized and unintended information transfer\n via shared system resources.\"\n desc \"The purpose of this control is to prevent information, including\n encrypted representations of information, produced by the actions of a prior\n user/role (or the actions of a process acting on behalf of a prior user/role)\n from being available to any current user/role (or current process) that obtains\n access to a shared system resource (e.g., registers, main memory, secondary\n storage) after the resource has been released back to the information system.\n Control of information in shared resources is also referred to as object reuse.\n\n Data used for the development and testing of applications often involves\n copying data from production. It is important that specific procedures exist\n for this process, so copies of sensitive data are not misplaced or left in a\n temporary location without the proper controls.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000243-DB-000128'\n tag \"gid\": 'V-61781'\n tag \"rid\": 'SV-76271r1_rule'\n tag \"stig_id\": 'O121-C2-018900'\n tag \"fix_id\": 'F-67697r1_fix'\n tag \"cci\": ['CCI-001090']\n tag \"nist\": ['SC-4', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Verify there are proper procedures in place for the refreshing\n of development/test data from production. Review any scripts or code that\n exists for the movement of production data to development/test, and verify\n copies of production data are not left in unprotected locations.\n\n If there is no documented procedure for data movement from production to\n development/test, this is a finding.\n\n If the code that exists for data movement does not remove any copies of\n production data from unprotected locations, this is a finding.\"\n tag \"fix\": \"Create and document a process for moving data from production to\n development/test systems, and follow the process.\n\n Modify any code used for moving data from production to development/test\n systems to ensure copies of production data are not left in nonsecured\n locations.\n\n Moving data is only a part of the challenge of protecting the data. When the\n data is moved, it should also be changed so sensitive information is not made\n available in development environments.\n\n With the Oracle Data Masking Pack for Oracle Enterprise Manager, organizations\n can comply with data privacy and protection mandates that restrict the use of\n actual customer data. With Oracle Data Masking Pack, sensitive information,\n such as credit card or social security numbers, can be replaced with realistic\n values, allowing production data to be safely used for development, testing, or\n sharing with out-source or off-shore partners for other nonproduction purposes.\n When used in conjunction with Oracle Enterprise Manager, it is easy to develop\n a secure process that is capable of obfuscating the data during the movement\n process.\n\n If the Oracle Data Masking Pack and Enterprise Manager are not available,\n develop site-specific procedures to manage and obfuscate sensitive data.\"\n describe 'A manual review is required to ensure the DBMS prevents unauthorized and unintended information transfer\n via shared system resources' do\n skip 'A manual review is required to ensure the DBMS prevents unauthorized and unintended information transfer\n via shared system resources'\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-61781.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61601.rb", "line": 1 }, - "id": "V-61781" + "id": "V-61601" }, { - "title": "The DBMS must support the requirement to back up audit data and\n records onto a different system or media than the system being audited on an\n organization-defined frequency.", - "desc": "Protection of log data includes assuring log data is not accidentally\n lost or deleted. Backing up audit records to a different system or onto media\n separate from the system being audited on an organizational-defined frequency\n helps to assure, in the event of a catastrophic system failure, the audit\n records will be retained.", + "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.", "descriptions": { - "default": "Protection of log data includes assuring log data is not accidentally\n lost or deleted. Backing up audit records to a different system or onto media\n separate from the system being audited on an organizational-defined frequency\n helps to assure, in the event of a catastrophic system failure, the audit\n records will be retained." + "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." }, - "impact": 0.5, + "impact": 0.7, "refs": [], "tags": { - "gtitle": "SRG-APP-000125-DB-000170", - "gid": "V-61665", - "rid": "SV-76155r1_rule", - "stig_id": "O121-C2-010000", - "fix_id": "F-67579r1_fix", + "gtitle": "SRG-APP-000178-DB-000083", + "gid": "V-61843", + "rid": "SV-76333r2_rule", + "stig_id": "O121-N1-015601", + "fix_id": "F-67759r1_fix", "cci": [ - "CCI-001348" + "CCI-000366" ], "nist": [ - "AU-9 (2)", + "CM-6 b", "Rev_4" ], "false_negatives": null, @@ -2837,35 +2925,39 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Check with the database administrator, storage administrator or\n system administrator, as applicable at the site, to verify that Oracle is\n configured EITHER to perform backups of the audit data specifically, OR, with\n appropriate permissions granted, to permit a third-party tool to do so. Test\n the backup process. Test the restore process (using a non-production system as\n the target).\n\n If Oracle is not so configured, this is a finding.\n\n If the test run of the backup and restore fails, this is a finding.", - "fix": "Utilize DBMS features or other software that supports the ability\n to back up audit data and records onto a system or media different from the\n system being audited on an organization-defined frequency.\n\n EITHER use Oracle features (such as Backup or Data Pump) to perform backups of\n the audit data specifically, OR grant appropriate permissions to permit a\n third-party tool to do so." + "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." }, - "code": "control 'V-61665' do\n title \"The DBMS must support the requirement to back up audit data and\n records onto a different system or media than the system being audited on an\n organization-defined frequency.\"\n desc \"Protection of log data includes assuring log data is not accidentally\n lost or deleted. Backing up audit records to a different system or onto media\n separate from the system being audited on an organizational-defined frequency\n helps to assure, in the event of a catastrophic system failure, the audit\n records will be retained.\"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000125-DB-000170'\n tag \"gid\": 'V-61665'\n tag \"rid\": 'SV-76155r1_rule'\n tag \"stig_id\": 'O121-C2-010000'\n tag \"fix_id\": 'F-67579r1_fix'\n tag \"cci\": ['CCI-001348']\n tag \"nist\": ['AU-9 (2)', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Check with the database administrator, storage administrator or\n system administrator, as applicable at the site, to verify that Oracle is\n configured EITHER to perform backups of the audit data specifically, OR, with\n appropriate permissions granted, to permit a third-party tool to do so. Test\n the backup process. Test the restore process (using a non-production system as\n the target).\n\n If Oracle is not so configured, this is a finding.\n\n If the test run of the backup and restore fails, this is a finding.\"\n tag \"fix\": \"Utilize DBMS features or other software that supports the ability\n to back up audit data and records onto a system or media different from the\n system being audited on an organization-defined frequency.\n\n EITHER use Oracle features (such as Backup or Data Pump) to perform backups of\n the audit data specifically, OR grant appropriate permissions to permit a\n third-party tool to do so.\"\n describe 'A manual review is required to ensure the DBMS supports the requirement to back up audit data and\n records onto a different system or media than the system being audited on an\n organization-defined frequency' do\n skip 'A manual review is required to ensure the DBMS supports the requirement to back up audit data and\n records onto a different system or media than the system being audited on an\n organization-defined frequency'\n end\nend\n", + "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", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61665.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61843.rb", "line": 1 }, - "id": "V-61665" + "id": "V-61843" }, { - "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.", + "title": "Database software, applications, and configuration files must be\n monitored to discover unauthorized changes.", + "desc": "Any changes to the hardware, software, and/or firmware components of\n the information system and/or application can potentially have significant\n effects on the overall security of the system.\n\n If the system were to allow any user to make changes to software libraries,\n then those changes might be implemented without undergoing the appropriate\n testing and approvals that are part of a robust change management process.\n\n Accordingly, only qualified and authorized individuals shall be allowed to\n obtain access to information system components for purposes of initiating\n changes, including upgrades and modifications.\n\n Unmanaged changes that occur to the database software libraries or\n configuration can lead to unauthorized or compromised installations.", "descriptions": { - "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." + "default": "Any changes to the hardware, software, and/or firmware components of\n the information system and/or application can potentially have significant\n effects on the overall security of the system.\n\n If the system were to allow any user to make changes to software libraries,\n then those changes might be implemented without undergoing the appropriate\n testing and approvals that are part of a robust change management process.\n\n Accordingly, only qualified and authorized individuals shall be allowed to\n obtain access to information system components for purposes of initiating\n changes, including upgrades and modifications.\n\n Unmanaged changes that occur to the database software libraries or\n configuration can lead to unauthorized or compromised installations." }, - "impact": 0.5, - "refs": [], + "impact": 0, + "refs": [ + { + "ref": [] + } + ], "tags": { - "gtitle": "SRG-APP-000516-DB-999900", - "gid": "V-61413", - "rid": "SV-75903r1_rule", - "stig_id": "O121-BP-021300", - "fix_id": "F-67329r1_fix", + "gtitle": "SRG-APP-000133-DB-000179", + "gid": "V-61867", + "rid": "SV-76357r2_rule", + "stig_id": "O121-OS-010700", + "fix_id": "F-67783r2_fix", "cci": [ - "CCI-000366" + "CCI-001499" ], "nist": [ - "CM-6 b", + "CM-5 (6)", "Rev_4" ], "false_negatives": null, @@ -2878,35 +2970,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "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." + "check": "Review monitoring procedures and implementation evidence to\n verify that monitoring of changes to database software libraries, related\n applications, and configuration files is done.\n\n Verify that the list of files and directories being monitored is complete. If\n monitoring does not occur or is not complete, this is a finding.", + "fix": "Implement procedures to monitor for unauthorized changes to DBMS\n software libraries, related software application libraries, and configuration\n files. If a third-party automated tool is not employed, an automated job that\n reports file information on the directories and files of interest and compares\n them to the baseline report for the same will meet the requirement.\n\n File hashes or checksums should be used for comparisons since file dates may be\n manipulated by malicious users." }, - "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", + "code": " control 'V-61867' 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-61413.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61867.rb", "line": 1 }, - "id": "V-61413" + "id": "V-61867" }, { - "title": "The DBMS must automatically audit account disabling actions, to the\n extent such information is available.", - "desc": "When application accounts are disabled, user accessibility is\n affected. Accounts are utilized for identifying individual application users or\n for identifying the application processes themselves.\n\n In order to detect and respond to events affecting user accessibility and\n application processing, applications must audit account disabling actions and,\n as required, notify the appropriate individuals so they can investigate the\n event.\n\n Such a capability greatly reduces the risk that application accessibility\n will be negatively affected for extended periods of time and provides logging\n that can be used for forensic purposes.\n\n Note that user authentication and account management should be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP.\n\n However, notwithstanding how accounts are managed, Oracle auditing must\n always be configured to capture account-disabling actions, to the extent such\n information is available.\n\n Note that some Oracle architectural details limit the ability to capture\n this information. There is a difference between actions taken by a user that\n generate an audit record and actions by the database itself, which do not\n generate an audit record. If an account is locked because of an expiration\n event, it is done by the database without involving the action of a user.\n Failed logins are logged user interactions, but the subsequent locking of the\n account, although initiated by user actions, is a function of the database.", + "title": "DBMS must conduct backups of system-level information per\n organization-defined frequency that is consistent with recovery time and\n recovery point objectives.", + "desc": "Information system backup is a critical step in maintaining data\n assurance and availability.\n\n System-level information includes: system-state information, operating\n system and application software, and licenses.\n\n Backups shall be consistent with organizational recovery time and recovery\n point objectives.\n\n Databases that do not back up information regularly risk the loss of that\n information in the event of a system failure. Most databases contain\n functionality to allow regular backups; it is important that this functionality\n is enabled and configured correctly to prevent data loss.", "descriptions": { - "default": "When application accounts are disabled, user accessibility is\n affected. Accounts are utilized for identifying individual application users or\n for identifying the application processes themselves.\n\n In order to detect and respond to events affecting user accessibility and\n application processing, applications must audit account disabling actions and,\n as required, notify the appropriate individuals so they can investigate the\n event.\n\n Such a capability greatly reduces the risk that application accessibility\n will be negatively affected for extended periods of time and provides logging\n that can be used for forensic purposes.\n\n Note that user authentication and account management should be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP.\n\n However, notwithstanding how accounts are managed, Oracle auditing must\n always be configured to capture account-disabling actions, to the extent such\n information is available.\n\n Note that some Oracle architectural details limit the ability to capture\n this information. There is a difference between actions taken by a user that\n generate an audit record and actions by the database itself, which do not\n generate an audit record. If an account is locked because of an expiration\n event, it is done by the database without involving the action of a user.\n Failed logins are logged user interactions, but the subsequent locking of the\n account, although initiated by user actions, is a function of the database." + "default": "Information system backup is a critical step in maintaining data\n assurance and availability.\n\n System-level information includes: system-state information, operating\n system and application software, and licenses.\n\n Backups shall be consistent with organizational recovery time and recovery\n point objectives.\n\n Databases that do not back up information regularly risk the loss of that\n information in the event of a system failure. Most databases contain\n functionality to allow regular backups; it is important that this functionality\n is enabled and configured correctly to prevent data loss." }, "impact": 0.5, "refs": [], "tags": { - "gtitle": "SRG-APP-000028-DB-000187", - "gid": "V-61571", - "rid": "SV-76061r4_rule", - "stig_id": "O121-C2-002400", - "fix_id": "F-67487r2_fix", + "gtitle": "SRG-APP-000146-DB-000099", + "gid": "V-61701", + "rid": "SV-76191r1_rule", + "stig_id": "O121-C2-012600", + "fix_id": "F-67617r1_fix", "cci": [ - "CCI-001404" + "CCI-000537" ], "nist": [ - "AC-2 (4)", + "CP-9 (b)", "Rev_4" ], "false_negatives": null, @@ -2919,39 +3011,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Check Oracle settings (and also OS settings and/or\n enterprise-level authentication/access mechanisms settings) to determine if\n account disabling actions are being audited. If account disabling actions are\n not being audited by Oracle, this is a finding.\n\n If Standard Auditing is used:\n To see if Oracle is configured to capture audit data, enter the following\n SQL*Plus command:\n SHOW PARAMETER AUDIT_TRAIL\n or the following SQL query:\n SELECT * FROM SYS.V$PARAMETER WHERE NAME = 'audit_trail';\n If Oracle returns the value 'NONE', this is a finding.\n\n If Unified Auditing is used:\n To see if Oracle is configured to capture audit data including account\n disabling, enter the following SQL*Plus command:\n SELECT ' Account disabling is not being audited. '\n FROM dual\n WHERE (SELECT Count(*)\n FROM (select policy_name , audit_option from audit_unified_policies\n WHERE audit_option = 'ALTER USER'\n and policy_name in (select policy_name from audit_unified_enabled_policies\n where user_name='ALL USERS'))) = 0\n OR (SELECT value\n FROM v$option\n WHERE parameter = 'Unified Auditing') != 'TRUE';\n\n If Oracle returns \"no rows selected\", this is not a finding.", - "fix": "Configure Oracle to audit account disabling actions.\n\n If Standard Auditing is used:\n Use this process to ensure auditable events are captured:\n ALTER SYSTEM SET AUDIT_TRAIL= SCOPE=SPFILE;\n Audit trail type can be 'OS', 'DB', 'DB,EXTENDED', 'XML' or 'XML,EXTENDED'.\n After executing this statement, it may be necessary to shut down and restart\n the Oracle database.\n\n If Unified Auditing is used:\n To ensure auditable events are captured:\n Link the oracle binary with uniaud_on, and then restart the database. Oracle\n Database Upgrade Guide describes how to enable unified auditing. Reference\n V-61625 for information on how to configure a policy to audit account disabling.\n\n For more information on the configuration of auditing, refer to the following\n documents:\n \"Auditing Database Activity\" in the Oracle Database 2 Day + Security Guide:\n http://docs.oracle.com/database/121/TDPSG/tdpsg_auditing.htm#TDPSG50000\n \"Monitoring Database Activity with Auditing\" in the Oracle Database Security\n Guide:\n http://docs.oracle.com/database/121/DBSEG/part_6.htm#CCHEHCGI\n \"DBMS_AUDIT_MGMT\" in the Oracle Database PL/SQL Packages and Types Reference:\n http://docs.oracle.com/database/121/ARPLS/d_audit_mgmt.htm#ARPLS241\n Oracle Database Upgrade Guide:\n http://docs.oracle.com/database/121/UPGRD/afterup.htm#UPGRD52810" + "check": "Review DBMS and OS backup configuration to determine that\n system-level data is backed up in according with organization-defined frequency.\n\n If the system-level data of the DBMS is not backed up to the\n organization-defined frequency, this is a finding.", + "fix": "Utilize DBMS, OS, or third-party product(s) to meet the\n requirement of backing up system data according to the organization-defined\n frequency." }, - "code": "control 'V-61571' do\n title \"The DBMS must automatically audit account disabling actions, to the\n extent such information is available.\"\n desc \"When application accounts are disabled, user accessibility is\n affected. Accounts are utilized for identifying individual application users or\n for identifying the application processes themselves.\n\n In order to detect and respond to events affecting user accessibility and\n application processing, applications must audit account disabling actions and,\n as required, notify the appropriate individuals so they can investigate the\n event.\n\n Such a capability greatly reduces the risk that application accessibility\n will be negatively affected for extended periods of time and provides logging\n that can be used for forensic purposes.\n\n Note that user authentication and account management should be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP.\n\n However, notwithstanding how accounts are managed, Oracle auditing must\n always be configured to capture account-disabling actions, to the extent such\n information is available.\n\n Note that some Oracle architectural details limit the ability to capture\n this information. There is a difference between actions taken by a user that\n generate an audit record and actions by the database itself, which do not\n generate an audit record. If an account is locked because of an expiration\n event, it is done by the database without involving the action of a user.\n Failed logins are logged user interactions, but the subsequent locking of the\n account, although initiated by user actions, is a function of the database.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000028-DB-000187'\n tag \"gid\": 'V-61571'\n tag \"rid\": 'SV-76061r4_rule'\n tag \"stig_id\": 'O121-C2-002400'\n tag \"fix_id\": 'F-67487r2_fix'\n tag \"cci\": ['CCI-001404']\n tag \"nist\": ['AC-2 (4)', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Check Oracle settings (and also OS settings and/or\n enterprise-level authentication/access mechanisms settings) to determine if\n account disabling actions are being audited. If account disabling actions are\n not being audited by Oracle, this is a finding.\n\n If Standard Auditing is used:\n To see if Oracle is configured to capture audit data, enter the following\n SQL*Plus command:\n SHOW PARAMETER AUDIT_TRAIL\n or the following SQL query:\n SELECT * FROM SYS.V$PARAMETER WHERE NAME = 'audit_trail';\n If Oracle returns the value 'NONE', this is a finding.\n\n If Unified Auditing is used:\n To see if Oracle is configured to capture audit data including account\n disabling, enter the following SQL*Plus command:\n SELECT ' Account disabling is not being audited. '\n FROM dual\n WHERE (SELECT Count(*)\n FROM (select policy_name , audit_option from audit_unified_policies\n WHERE audit_option = 'ALTER USER'\n and policy_name in (select policy_name from audit_unified_enabled_policies\n where user_name='ALL USERS'))) = 0\n OR (SELECT value\n FROM v$option\n WHERE parameter = 'Unified Auditing') != 'TRUE';\n\n If Oracle returns \\\"no rows selected\\\", this is not a finding.\"\n tag \"fix\": \"Configure Oracle to audit account disabling actions.\n\n If Standard Auditing is used:\n Use this process to ensure auditable events are captured:\n ALTER SYSTEM SET AUDIT_TRAIL= SCOPE=SPFILE;\n Audit trail type can be 'OS', 'DB', 'DB,EXTENDED', 'XML' or 'XML,EXTENDED'.\n After executing this statement, it may be necessary to shut down and restart\n the Oracle database.\n\n If Unified Auditing is used:\n To ensure auditable events are captured:\n Link the oracle binary with uniaud_on, and then restart the database. Oracle\n Database Upgrade Guide describes how to enable unified auditing. Reference\n V-61625 for information on how to configure a policy to audit account disabling.\n\n For more information on the configuration of auditing, refer to the following\n documents:\n \\\"Auditing Database Activity\\\" in the Oracle Database 2 Day + Security Guide:\n http://docs.oracle.com/database/121/TDPSG/tdpsg_auditing.htm#TDPSG50000\n \\\"Monitoring Database Activity with Auditing\\\" in the Oracle Database Security\n Guide:\n http://docs.oracle.com/database/121/DBSEG/part_6.htm#CCHEHCGI\n \\\"DBMS_AUDIT_MGMT\\\" in the Oracle Database PL/SQL Packages and Types Reference:\n http://docs.oracle.com/database/121/ARPLS/d_audit_mgmt.htm#ARPLS241\n Oracle Database Upgrade Guide:\n http://docs.oracle.com/database/121/UPGRD/afterup.htm#UPGRD52810\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n standard_auditing_used = input('standard_auditing_used')\n unified_auditing_used = input('unified_auditing_used')\n\n describe.one do\n describe 'Standard auditing is in use for audit purposes' do\n subject { standard_auditing_used }\n it { should be true }\n end\n\n describe 'Unified auditing is in use for audit purposes' do\n subject { unified_auditing_used }\n it { should be true }\n end\n end\n\n audit_trail = sql.query(\"select value from v$parameter where name = 'audit_trail';\").column('value')\n\n if standard_auditing_used\n describe 'The oracle database audit_trail parameter' do\n subject { audit_trail }\n it { should_not cmp 'NONE' }\n end\n end\n\n unified_auditing = sql.query(\"SELECT value FROM V$OPTION WHERE PARAMETER = 'Unified Auditing';\").column('value')\n\n if unified_auditing_used\n describe 'The oracle database unified auditing parameter' do\n subject { unified_auditing }\n it { should_not cmp 'FALSE' }\n end\n\n unified_auditing_events = sql.query(\"SELECT ' Account disabling is not being audited. '\n FROM dual\n WHERE (SELECT Count(*)\n FROM (select policy_name , audit_option from audit_unified_policies\n WHERE audit_option = 'ALTER USER'\n and policy_name in (select policy_name from audit_unified_enabled_policies\n where user_name='ALL USERS'))) = 0\n OR (SELECT value\n FROM v$option\n WHERE parameter = 'Unified Auditing') != 'TRUE';\").column('Account disabling is not being audited.').uniq\n\n describe 'The unified auditing data capture for account disabling actions' do\n subject { unified_auditing_events.to_s }\n it { should_not cmp '[nil]' }\n end\n end\nend\n", + "code": "control 'V-61701' do\n title \"DBMS must conduct backups of system-level information per\n organization-defined frequency that is consistent with recovery time and\n recovery point objectives.\"\n desc \"Information system backup is a critical step in maintaining data\n assurance and availability.\n\n System-level information includes: system-state information, operating\n system and application software, and licenses.\n\n Backups shall be consistent with organizational recovery time and recovery\n point objectives.\n\n Databases that do not back up information regularly risk the loss of that\n information in the event of a system failure. Most databases contain\n functionality to allow regular backups; it is important that this functionality\n is enabled and configured correctly to prevent data loss.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000146-DB-000099'\n tag \"gid\": 'V-61701'\n tag \"rid\": 'SV-76191r1_rule'\n tag \"stig_id\": 'O121-C2-012600'\n tag \"fix_id\": 'F-67617r1_fix'\n tag \"cci\": ['CCI-000537']\n tag \"nist\": ['CP-9 (b)', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Review DBMS and OS backup configuration to determine that\n system-level data is backed up in according with organization-defined frequency.\n\n If the system-level data of the DBMS is not backed up to the\n organization-defined frequency, this is a finding.\"\n tag \"fix\": \"Utilize DBMS, OS, or third-party product(s) to meet the\n requirement of backing up system data according to the organization-defined\n frequency.\"\n describe 'A manual is required to ensure the DBMS conducts backups of system-level information per\n organization-defined frequency that is consistent with recovery time and\n recovery point objectives' do\n skip 'A manual is required to ensure the DBMS conducts backups of system-level information per\n organization-defined frequency that is consistent with recovery time and\n recovery point objectives'\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61571.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61701.rb", "line": 1 }, - "id": "V-61571" + "id": "V-61701" }, { - "title": "Remote administration must be disabled for the Oracle connection\n manager.", - "desc": "Remote administration provides a potential opportunity for malicious\n users to make unauthorized changes to the Connection Manager configuration or\n interrupt its service.", + "title": "Attempts to bypass access controls must be audited.", + "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 Detection of suspicious activity, including access attempts and successful\n access from unexpected places, during unexpected times, or other unusual\n indicators can support decisions to apply countermeasures to deter an attack.\n Without detection, malicious activity may proceed without hindrance.", "descriptions": { - "default": "Remote administration provides a potential opportunity for malicious\n users to make unauthorized changes to the Connection Manager configuration or\n interrupt its service." + "default": "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 Detection of suspicious activity, including access attempts and successful\n access from unexpected places, during unexpected times, or other unusual\n indicators can support decisions to apply countermeasures to deter an attack.\n Without detection, malicious activity may proceed without hindrance." }, - "impact": 0, - "refs": [ - { - "ref": [] - } - ], + "impact": 0.5, + "refs": [], "tags": { - "gtitle": "SRG-APP-000516-DB-999900", - "gid": "V-61533", - "rid": "SV-76023r1_rule", - "stig_id": "O121-BP-026500", - "fix_id": "F-67449r1_fix", + "gtitle": "SRG-APP-000115-DB-000056", + "gid": "V-61651", + "rid": "SV-76141r1_rule", + "stig_id": "O121-C2-009000", + "fix_id": "F-67565r1_fix", "cci": [ - "CCI-000366" + "CCI-000158" ], "nist": [ - "CM-6 b", + "AU-7 (1)", "Rev_4" ], "false_negatives": null, @@ -2964,35 +3052,39 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "View the cman.ora file in the ORACLE_HOME/network/admin\n directory.\n\n If the file does not exist, the database is not accessed via Oracle Connection\n Manager and this check is not a finding.\n\n If the entry and value for REMOTE_ADMIN is not listed or is not set to a value\n of NO (REMOTE_ADMIN = NO), this is a finding.", - "fix": "View the cman.ora file in the ORACLE_HOME/network/admin directory\n of the Connection Manager.\n\n Include the following line in the file:\n\n REMOTE_ADMIN = NO" + "check": "Review any audit settings for:\n - Unsuccessful logon attempts;\n - Account locking events;\n - Account disabling from a specific source location;\n - Failed database object attempts or attempts to access objects that do not\n exist; and\n - Other activities that may produce unexpected failures or trigger DBMS\n lockdown actions.\n\n If any of the above events as applicable to the DBMS are not audited, this is a\n finding.\n\n - - - - - -\n Check the current users in the database to see what profile they are assigned.\n The logon attempts past a site-defined allowable number, along with account\n locking, is best performed using a profile that defines the limits on these\n activities as designed by the DBA at a specific site. Failed database object\n access or attempt to access objects is monitored by auditing. Checking other\n activities that may produce unexpected failures or trigger database lockdown\n procedures is possible, but the check for the existence of those procedures is\n not possible unless they are defined.\n\n Check to see what profiles exist for the different users of the database.\n\n SQL>col name format a20\n col username format a21\n col profile format a10\n col \"tmp tba\" format a10\n select u.username,\n u.default_tablespace,\n u.temporary_tablespace \"TMP TBS\",\n u.profile,\n r.granted_role,\n r.admin_option,\n r.default_role\n from sys.dba_users u,\n sys.dba_role_privs r\n where u.username = r.grantee (+)\n group by u.username,\n u.default_tablespace,\n u.temporary_tablespace,\n u.profile,\n r.granted_role,\n r.admin_option,\n r.default_role;\n\n View existing profiles and see what their settings are.\n\n SQL> select profile, resource_name, limit\n from dba_profiles\n order by profile, resource_name;\n\n This is the audit table. Specific actions are logged in this table.\n\n If Standard Auditing is used:\n SQL> desc aud$;\n Name Null? Type\n ----------------- ------- ------\n SESSIONID NOT NULL NUMBER\n ENTRYID NOT NULL NUMBER\n STATEMENT NOT NULL NUMBER\n TIMESTAMP# DATE\n USERID VARCHAR2(30)\n USERHOST VARCHAR2(128)\n TERMINAL VARCHAR2(255)\n ACTION# NOT NULL NUMBER\n RETURNCODE NOT NULL NUMBER\n OBJ$CREATOR VARCHAR2(30)\n OBJ$NAME VARCHAR2(128)\n AUTH$PRIVILEGES VARCHAR2(16)\n AUTH$GRANTEE VARCHAR2(30)\n NEW$OWNER VARCHAR2(30)\n NEW$NAME VARCHAR2(128)\n SES$ACTIONS VARCHAR2(19)\n SES$TID NUMBER\n LOGOFF$LREAD NUMBER\n LOGOFF$PREAD NUMBER\n LOGOFF$LWRITE NUMBER\n LOGOFF$DEAD NUMBER\n LOGOFF$TIME DATE\n COMMENT$TEXT VARCHAR2(4000)\n CLIENTID VARCHAR2(64)\n SPARE1 VARCHAR2(255)\n SPARE2 NUMBER\n OBJ$LABEL RAW(255)\n SES$LABEL RAW(255)\n PRIV$USED NUMBER\n SESSIONCPU NUMBER\n NTIMESTAMP# TIMESTAMP(6)\n PROXY$SID NUMBER\n USER$GUID VARCHAR2(32)\n INSTANCE# NUMBER\n PROCESS# VARCHAR2(16)\n XID RAW(8)\n AUDITID VARCHAR2(64)\n SCN NUMBER\n DBID NUMBER\n SQLBIND CLOB\n SQLTEXT CLOB\n OBJ$EDITION VARCHAR2(30)\n\n If Unified Auditing is used:\n SQL> desc unified_audit_trail;\n Name Null Type\n -------------- ------ ------\n AUDIT_TYPE VARCHAR2(64)\n SESSIONID NUMBER\n PROXY_SESSIONID NUMBER\n OS_USERNAME VARCHAR2(30)\n USERHOST VARCHAR2(128)\n TERMINAL VARCHAR2(30)\n INSTANCE_ID NUMBER\n DBID NUMBER\n AUTHENTICATION_TYPE VARCHAR2(1024)\n DBUSERNAME VARCHAR2(30)\n DBPROXY_USERNAME VARCHAR2(30)\n EXTERNAL_USERID VARCHAR2(1024)\n GLOBAL_USERID VARCHAR2(32)\n CLIENT_PROGRAM_NAME VARCHAR2(48)\n DBLINK_INFO VARCHAR2(4000)\n XS_USER_NAME VARCHAR2(128)\n XS_SESSIONID RAW(33 BYTE)\n ENTRY_ID NUMBER\n STATEMENT_ID NUMBER\n EVENT_TIMESTAMP TIMESTAMP(6) WITH LOCAL TIME ZONE\n ACTION_NAME VARCHAR2(64)\n RETURN_CODE NUMBER\n OS_PROCESS VARCHAR2(16)\n TRANSACTION_ID RAW(8 BYTE)\n SCN NUMBER\n EXECUTION_ID VARCHAR2(64)\n OBJECT_SCHEMA VARCHAR2(30)\n OBJECT_NAME VARCHAR2(128)\n SQL_TEXT CLOB\n SQL_BINDS CLOB\n APPLICATION_CONTEXTS VARCHAR2(4000)\n CLIENT_IDENTIFIER VARCHAR2(64)\n NEW_SCHEMA VARCHAR2(30)\n NEW_NAME VARCHAR2(128)\n OBJECT_EDITION VARCHAR2(30)\n SYSTEM_PRIVILEGE_USED VARCHAR2(1024)\n SYSTEM_PRIVILEGE VARCHAR2(40)\n AUDIT_OPTION VARCHAR2(40)\n OBJECT_PRIVILEGES VARCHAR2(19)\n ROLE VARCHAR2(30)\n TARGET_USER VARCHAR2(30)\n EXCLUDED_USER VARCHAR2(30)\n EXCLUDED_SCHEMA VARCHAR2(30)\n EXCLUDED_OBJECT VARCHAR2(128)\n ADDITIONAL_INFO VARCHAR2(4000)\n UNIFIED_AUDIT_POLICIES VARCHAR2(4000)\n FGA_POLICY_NAME VARCHAR2(30)\n XS_INACTIVITY_TIMEOUT NUMBER\n XS_ENTITY_TYPE VARCHAR2(32)\n XS_TARGET_PRINCIPAL_NAME VARCHAR2(30)\n XS_PROXY_USER_NAME VARCHAR2(30)\n XS_DATASEC_POLICY_NAME VARCHAR2(30)\n XS_SCHEMA_NAME VARCHAR2(30)\n XS_CALLBACK_EVENT_TYPE VARCHAR2(32)\n XS_PACKAGE_NAME VARCHAR2(30)\n XS_PROCEDURE_NAME VARCHAR2(30)\n XS_ENABLED_ROLE VARCHAR2(30)\n XS_COOKIE VARCHAR2(1024)\n XS_NS_NAME VARCHAR2(30)\n XS_NS_ATTRIBUTE VARCHAR2(4000)\n XS_NS_ATTRIBUTE_OLD_VAL VARCHAR2(4000)\n XS_NS_ATTRIBUTE_NEW_VAL VARCHAR2(4000)\n DV_ACTION_CODE NUMBER\n DV_ACTION_NAME VARCHAR2(30)\n DV_EXTENDED_ACTION_CODE NUMBER\n DV_GRANTEE VARCHAR2(30)\n DV_RETURN_CODE NUMBER\n DV_ACTION_OBJECT_NAME VARCHAR2(128)\n DV_RULE_SET_NAME VARCHAR2(90)\n DV_COMMENT VARCHAR2(4000)\n DV_FACTOR_CONTEXT VARCHAR2(4000)\n DV_OBJECT_STATUS VARCHAR2(1)\n OLS_POLICY_NAME VARCHAR2(30)\n OLS_GRANTEE VARCHAR2(30)\n OLS_MAX_READ_LABEL VARCHAR2(4000)\n OLS_MAX_WRITE_LABEL VARCHAR2(4000)\n OLS_MIN_WRITE_LABEL VARCHAR2(4000)\n OLS_PRIVILEGES_GRANTED VARCHAR2(30)\n OLS_PROGRAM_UNIT_NAME VARCHAR2(30)\n OLS_PRIVILEGES_USED VARCHAR2(128)\n OLS_STRING_LABEL VARCHAR2(4000)\n OLS_LABEL_COMPONENT_TYPE VARCHAR2(12)\n OLS_LABEL_COMPONENT_NAME VARCHAR2(30)\n OLS_PARENT_GROUP_NAME VARCHAR2(30)\n OLS_OLD_VALUE VARCHAR2(4000)\n OLS_NEW_VALUE VARCHAR2(4000)\n RMAN_SESSION_RECID NUMBER\n RMAN_SESSION_STAMP NUMBER\n RMAN_OPERATION VARCHAR2(20)\n RMAN_OBJECT_TYPE VARCHAR2(20)\n RMAN_DEVICE_TYPE VARCHAR2(5)\n DP_TEXT_PARAMETERS1 VARCHAR2(512)\n DP_BOOLEAN_PARAMETERS1 VARCHAR2(512)\n DIRECT_PATH_NUM_COLUMNS_LOADED NUMBER", + "fix": "Configure auditing to capture the events listed below where\n available in the DBMS:\n - Unsuccessful logon attempts\n - Account locking events\n - Account disabling from a specific source location\n - Failed database object attempts or attempts to access objects that do not\n exist\n - Other activities that may produce unexpected failures or trigger DBMS\n lockdown actions" }, - "code": " control 'V-61533' do\n impact 0.0\n describe 'This control is not applicable on oracle within aws rds, as aws manages the operating system in which the oracle database is running on' do\n skip 'This control is not applicable on oracle within aws rds, as aws manages the operating system in which the oracle database is running on'\n end\n end\n", + "code": "control 'V-61651' do\n title 'Attempts to bypass access controls must be audited.'\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 Detection of suspicious activity, including access attempts and successful\n access from unexpected places, during unexpected times, or other unusual\n indicators can support decisions to apply countermeasures to deter an attack.\n Without detection, malicious activity may proceed without hindrance.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000115-DB-000056'\n tag \"gid\": 'V-61651'\n tag \"rid\": 'SV-76141r1_rule'\n tag \"stig_id\": 'O121-C2-009000'\n tag \"fix_id\": 'F-67565r1_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 any audit settings for:\n - Unsuccessful logon attempts;\n - Account locking events;\n - Account disabling from a specific source location;\n - Failed database object attempts or attempts to access objects that do not\n exist; and\n - Other activities that may produce unexpected failures or trigger DBMS\n lockdown actions.\n\n If any of the above events as applicable to the DBMS are not audited, this is a\n finding.\n\n - - - - - -\n Check the current users in the database to see what profile they are assigned.\n The logon attempts past a site-defined allowable number, along with account\n locking, is best performed using a profile that defines the limits on these\n activities as designed by the DBA at a specific site. Failed database object\n access or attempt to access objects is monitored by auditing. Checking other\n activities that may produce unexpected failures or trigger database lockdown\n procedures is possible, but the check for the existence of those procedures is\n not possible unless they are defined.\n\n Check to see what profiles exist for the different users of the database.\n\n SQL>col name format a20\n col username format a21\n col profile format a10\n col \\\"tmp tba\\\" format a10\n select u.username,\n u.default_tablespace,\n u.temporary_tablespace \\\"TMP TBS\\\",\n u.profile,\n r.granted_role,\n r.admin_option,\n r.default_role\n from sys.dba_users u,\n sys.dba_role_privs r\n where u.username = r.grantee (+)\n group by u.username,\n u.default_tablespace,\n u.temporary_tablespace,\n u.profile,\n r.granted_role,\n r.admin_option,\n r.default_role;\n\n View existing profiles and see what their settings are.\n\n SQL> select profile, resource_name, limit\n from dba_profiles\n order by profile, resource_name;\n\n This is the audit table. Specific actions are logged in this table.\n\n If Standard Auditing is used:\n SQL> desc aud$;\n Name Null? Type\n ----------------- ------- ------\n SESSIONID NOT NULL NUMBER\n ENTRYID NOT NULL NUMBER\n STATEMENT NOT NULL NUMBER\n TIMESTAMP# DATE\n USERID VARCHAR2(30)\n USERHOST VARCHAR2(128)\n TERMINAL VARCHAR2(255)\n ACTION# NOT NULL NUMBER\n RETURNCODE NOT NULL NUMBER\n OBJ$CREATOR VARCHAR2(30)\n OBJ$NAME VARCHAR2(128)\n AUTH$PRIVILEGES VARCHAR2(16)\n AUTH$GRANTEE VARCHAR2(30)\n NEW$OWNER VARCHAR2(30)\n NEW$NAME VARCHAR2(128)\n SES$ACTIONS VARCHAR2(19)\n SES$TID NUMBER\n LOGOFF$LREAD NUMBER\n LOGOFF$PREAD NUMBER\n LOGOFF$LWRITE NUMBER\n LOGOFF$DEAD NUMBER\n LOGOFF$TIME DATE\n COMMENT$TEXT VARCHAR2(4000)\n CLIENTID VARCHAR2(64)\n SPARE1 VARCHAR2(255)\n SPARE2 NUMBER\n OBJ$LABEL RAW(255)\n SES$LABEL RAW(255)\n PRIV$USED NUMBER\n SESSIONCPU NUMBER\n NTIMESTAMP# TIMESTAMP(6)\n PROXY$SID NUMBER\n USER$GUID VARCHAR2(32)\n INSTANCE# NUMBER\n PROCESS# VARCHAR2(16)\n XID RAW(8)\n AUDITID VARCHAR2(64)\n SCN NUMBER\n DBID NUMBER\n SQLBIND CLOB\n SQLTEXT CLOB\n OBJ$EDITION VARCHAR2(30)\n\n If Unified Auditing is used:\n SQL> desc unified_audit_trail;\n Name Null Type\n -------------- ------ ------\n AUDIT_TYPE VARCHAR2(64)\n SESSIONID NUMBER\n PROXY_SESSIONID NUMBER\n OS_USERNAME VARCHAR2(30)\n USERHOST VARCHAR2(128)\n TERMINAL VARCHAR2(30)\n INSTANCE_ID NUMBER\n DBID NUMBER\n AUTHENTICATION_TYPE VARCHAR2(1024)\n DBUSERNAME VARCHAR2(30)\n DBPROXY_USERNAME VARCHAR2(30)\n EXTERNAL_USERID VARCHAR2(1024)\n GLOBAL_USERID VARCHAR2(32)\n CLIENT_PROGRAM_NAME VARCHAR2(48)\n DBLINK_INFO VARCHAR2(4000)\n XS_USER_NAME VARCHAR2(128)\n XS_SESSIONID RAW(33 BYTE)\n ENTRY_ID NUMBER\n STATEMENT_ID NUMBER\n EVENT_TIMESTAMP TIMESTAMP(6) WITH LOCAL TIME ZONE\n ACTION_NAME VARCHAR2(64)\n RETURN_CODE NUMBER\n OS_PROCESS VARCHAR2(16)\n TRANSACTION_ID RAW(8 BYTE)\n SCN NUMBER\n EXECUTION_ID VARCHAR2(64)\n OBJECT_SCHEMA VARCHAR2(30)\n OBJECT_NAME VARCHAR2(128)\n SQL_TEXT CLOB\n SQL_BINDS CLOB\n APPLICATION_CONTEXTS VARCHAR2(4000)\n CLIENT_IDENTIFIER VARCHAR2(64)\n NEW_SCHEMA VARCHAR2(30)\n NEW_NAME VARCHAR2(128)\n OBJECT_EDITION VARCHAR2(30)\n SYSTEM_PRIVILEGE_USED VARCHAR2(1024)\n SYSTEM_PRIVILEGE VARCHAR2(40)\n AUDIT_OPTION VARCHAR2(40)\n OBJECT_PRIVILEGES VARCHAR2(19)\n ROLE VARCHAR2(30)\n TARGET_USER VARCHAR2(30)\n EXCLUDED_USER VARCHAR2(30)\n EXCLUDED_SCHEMA VARCHAR2(30)\n EXCLUDED_OBJECT VARCHAR2(128)\n ADDITIONAL_INFO VARCHAR2(4000)\n UNIFIED_AUDIT_POLICIES VARCHAR2(4000)\n FGA_POLICY_NAME VARCHAR2(30)\n XS_INACTIVITY_TIMEOUT NUMBER\n XS_ENTITY_TYPE VARCHAR2(32)\n XS_TARGET_PRINCIPAL_NAME VARCHAR2(30)\n XS_PROXY_USER_NAME VARCHAR2(30)\n XS_DATASEC_POLICY_NAME VARCHAR2(30)\n XS_SCHEMA_NAME VARCHAR2(30)\n XS_CALLBACK_EVENT_TYPE VARCHAR2(32)\n XS_PACKAGE_NAME VARCHAR2(30)\n XS_PROCEDURE_NAME VARCHAR2(30)\n XS_ENABLED_ROLE VARCHAR2(30)\n XS_COOKIE VARCHAR2(1024)\n XS_NS_NAME VARCHAR2(30)\n XS_NS_ATTRIBUTE VARCHAR2(4000)\n XS_NS_ATTRIBUTE_OLD_VAL VARCHAR2(4000)\n XS_NS_ATTRIBUTE_NEW_VAL VARCHAR2(4000)\n DV_ACTION_CODE NUMBER\n DV_ACTION_NAME VARCHAR2(30)\n DV_EXTENDED_ACTION_CODE NUMBER\n DV_GRANTEE VARCHAR2(30)\n DV_RETURN_CODE NUMBER\n DV_ACTION_OBJECT_NAME VARCHAR2(128)\n DV_RULE_SET_NAME VARCHAR2(90)\n DV_COMMENT VARCHAR2(4000)\n DV_FACTOR_CONTEXT VARCHAR2(4000)\n DV_OBJECT_STATUS VARCHAR2(1)\n OLS_POLICY_NAME VARCHAR2(30)\n OLS_GRANTEE VARCHAR2(30)\n OLS_MAX_READ_LABEL VARCHAR2(4000)\n OLS_MAX_WRITE_LABEL VARCHAR2(4000)\n OLS_MIN_WRITE_LABEL VARCHAR2(4000)\n OLS_PRIVILEGES_GRANTED VARCHAR2(30)\n OLS_PROGRAM_UNIT_NAME VARCHAR2(30)\n OLS_PRIVILEGES_USED VARCHAR2(128)\n OLS_STRING_LABEL VARCHAR2(4000)\n OLS_LABEL_COMPONENT_TYPE VARCHAR2(12)\n OLS_LABEL_COMPONENT_NAME VARCHAR2(30)\n OLS_PARENT_GROUP_NAME VARCHAR2(30)\n OLS_OLD_VALUE VARCHAR2(4000)\n OLS_NEW_VALUE VARCHAR2(4000)\n RMAN_SESSION_RECID NUMBER\n RMAN_SESSION_STAMP NUMBER\n RMAN_OPERATION VARCHAR2(20)\n RMAN_OBJECT_TYPE VARCHAR2(20)\n RMAN_DEVICE_TYPE VARCHAR2(5)\n DP_TEXT_PARAMETERS1 VARCHAR2(512)\n DP_BOOLEAN_PARAMETERS1 VARCHAR2(512)\n DIRECT_PATH_NUM_COLUMNS_LOADED NUMBER\"\n tag \"fix\": \"Configure auditing to capture the events listed below where\n available in the DBMS:\n - Unsuccessful logon attempts\n - Account locking events\n - Account disabling from a specific source location\n - Failed database object attempts or attempts to access objects that do not\n exist\n - Other activities that may produce unexpected failures or trigger DBMS\n lockdown actions\"\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-61533.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61651.rb", "line": 1 }, - "id": "V-61533" + "id": "V-61651" }, { - "title": "Database software directories, including DBMS configuration files,\n must be stored in dedicated directories, or DASD pools, separate from the host\n OS and other applications.", - "desc": "When dealing with change control issues, it should be noted, any\n changes to the hardware, software, and/or firmware components of the\n information system and/or application can potentially have significant effects\n on the overall security of the system.\n\n Multiple applications can provide a cumulative negative effect. A\n vulnerability and subsequent exploit to one application can lead to an exploit\n of other applications sharing the same security context. For example, an\n exploit to a web server process that leads to unauthorized administrative\n access to host system directories can most likely lead to a compromise of all\n applications hosted by the same system. Database software not installed using\n dedicated directories both threatens and is threatened by other hosted\n applications. Access controls defined for one application may by default\n provide access to the other application's database objects or directories. Any\n method that provides any level of separation of security context assists in the\n protection between applications.", + "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.", "descriptions": { - "default": "When dealing with change control issues, it should be noted, any\n changes to the hardware, software, and/or firmware components of the\n information system and/or application can potentially have significant effects\n on the overall security of the system.\n\n Multiple applications can provide a cumulative negative effect. A\n vulnerability and subsequent exploit to one application can lead to an exploit\n of other applications sharing the same security context. For example, an\n exploit to a web server process that leads to unauthorized administrative\n access to host system directories can most likely lead to a compromise of all\n applications hosted by the same system. Database software not installed using\n dedicated directories both threatens and is threatened by other hosted\n applications. Access controls defined for one application may by default\n provide access to the other application's database objects or directories. Any\n method that provides any level of separation of security context assists in the\n protection between applications." + "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." }, - "impact": 0.5, - "refs": [], + "impact": 0, + "refs": [ + { + "ref": [] + } + ], "tags": { - "gtitle": "SRG-APP-000133-DB-000199", - "gid": "V-61875", - "rid": "SV-76365r1_rule", - "stig_id": "O121-P2-010900", - "fix_id": "F-67791r1_fix", + "gtitle": "SRG-APP-000171-DB-000074", + "gid": "V-61733", + "rid": "SV-76223r2_rule", + "stig_id": "O121-C2-014600", + "fix_id": "F-67649r5_fix", "cci": [ - "CCI-001499" + "CCI-000196" ], "nist": [ - "CM-5 (6)", + "IA-5 (1) (c)", "Rev_4" ], "false_negatives": null, @@ -3005,35 +3097,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Review the DBMS software library directory and note other root\n directories located on the same disk directory or any subdirectories. If any\n non-DBMS software directories exist on the disk directory, examine or\n investigate their use.\n\n If any of the directories are used by other applications, including third-party\n applications that use the DBMS, this is a finding.\n\n Only applications that are required for the functioning and administration, not\n use, of the DBMS should be located on the same disk directory as the DBMS\n software libraries.\n\n For databases located on mainframes, confirm that the database and its\n configuration files are isolated in their own DASD pools.\n\n If database software and database configuration files share DASD with other\n applications, this is a finding.", - "fix": "Install all applications on directories, or pools, separate from\n the DBMS software library directory. Re-locate any directories or re-install\n other application software that currently shares the DBMS software library\n directory to separate directories.\n\n For mainframe-based databases, locate database software and configuration files\n in separate DASD pools from other mainframe applications." + "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.)" }, - "code": "control 'V-61875' do\n title \"Database software directories, including DBMS configuration files,\n must be stored in dedicated directories, or DASD pools, separate from the host\n OS and other applications.\"\n desc \"When dealing with change control issues, it should be noted, any\n changes to the hardware, software, and/or firmware components of the\n information system and/or application can potentially have significant effects\n on the overall security of the system.\n\n Multiple applications can provide a cumulative negative effect. A\n vulnerability and subsequent exploit to one application can lead to an exploit\n of other applications sharing the same security context. For example, an\n exploit to a web server process that leads to unauthorized administrative\n access to host system directories can most likely lead to a compromise of all\n applications hosted by the same system. Database software not installed using\n dedicated directories both threatens and is threatened by other hosted\n applications. Access controls defined for one application may by default\n provide access to the other application's database objects or directories. Any\n method that provides any level of separation of security context assists in the\n protection between applications.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000133-DB-000199'\n tag \"gid\": 'V-61875'\n tag \"rid\": 'SV-76365r1_rule'\n tag \"stig_id\": 'O121-P2-010900'\n tag \"fix_id\": 'F-67791r1_fix'\n tag \"cci\": ['CCI-001499']\n tag \"nist\": ['CM-5 (6)', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Review the DBMS software library directory and note other root\n directories located on the same disk directory or any subdirectories. If any\n non-DBMS software directories exist on the disk directory, examine or\n investigate their use.\n\n If any of the directories are used by other applications, including third-party\n applications that use the DBMS, this is a finding.\n\n Only applications that are required for the functioning and administration, not\n use, of the DBMS should be located on the same disk directory as the DBMS\n software libraries.\n\n For databases located on mainframes, confirm that the database and its\n configuration files are isolated in their own DASD pools.\n\n If database software and database configuration files share DASD with other\n applications, this is a finding.\"\n tag \"fix\": \"Install all applications on directories, or pools, separate from\n the DBMS software library directory. Re-locate any directories or re-install\n other application software that currently shares the DBMS software library\n directory to separate directories.\n\n For mainframe-based databases, locate database software and configuration files\n in separate DASD pools from other mainframe applications.\"\n describe 'A manual review is required to ensure Database software directories, including DBMS configuration files,\n are stored in dedicated directories, or DASD pools, separate from the host\n OS and other applications' do\n skip 'A manual review is required to ensure Database software directories, including DBMS configuration files,\n are stored in dedicated directories, or DASD pools, separate from the host\n OS and other applications'\n end\nend\n", + "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", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61875.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61733.rb", "line": 1 }, - "id": "V-61875" + "id": "V-61733" }, { - "title": "DBMS backup and restoration files must be protected from unauthorized\n access.", - "desc": "Information system backup is a critical step in maintaining data\n assurance and availability.\n\n User-level information is data generated by information system and/or\n application users. In order to assure availability of this data in the event of\n a system failure, DoD organizations are required to ensure user-generated data\n is backed up at a defined frequency. This includes data stored on file systems,\n within databases or within any other storage media.\n\n Applications performing backups must be capable of backing up user-level\n information per the DoD-defined frequency.\n\n Lost or compromised DBMS backup and restoration files may lead to not only\n the loss of data, but also the unauthorized access to sensitive data. Backup\n files need the same protections against unauthorized access when stored on\n backup media as when online and actively in use by the database system. In\n addition, the backup media needs to be protected against physical loss. Most\n DBMS's maintain online copies of critical control files to provide transparent\n or easy recovery from hard disk loss or other interruptions to database\n operation.", + "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 system backup is a critical step in maintaining data\n assurance and availability.\n\n User-level information is data generated by information system and/or\n application users. In order to assure availability of this data in the event of\n a system failure, DoD organizations are required to ensure user-generated data\n is backed up at a defined frequency. This includes data stored on file systems,\n within databases or within any other storage media.\n\n Applications performing backups must be capable of backing up user-level\n information per the DoD-defined frequency.\n\n Lost or compromised DBMS backup and restoration files may lead to not only\n the loss of data, but also the unauthorized access to sensitive data. Backup\n files need the same protections against unauthorized access when stored on\n backup media as when online and actively in use by the database system. In\n addition, the backup media needs to be protected against physical loss. Most\n DBMS's maintain online copies of critical control files to provide transparent\n or easy recovery from hard disk loss or other interruptions to database\n operation." + "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-000145-DB-000098", - "gid": "V-61699", - "rid": "SV-76189r1_rule", - "stig_id": "O121-C2-012500", - "fix_id": "F-67615r1_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-000535" + "CCI-000366" ], "nist": [ - "CP-9 (a)", + "CM-6 b", "Rev_4" ], "false_negatives": null, @@ -3046,35 +3138,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Review file protections assigned to online backup and\n restoration files. Review access protections and procedures for off-line backup\n and restoration files.\n\n If backup or restoration files are subject to unauthorized access, this is a\n finding.\n\n It may be necessary to review backup and restoration procedures to determine\n ownership and access during all phases of backup and recovery.", - "fix": "Implement protection for backup and restoration files. Document\n personnel and the level of access authorized for each to the backup and\n restoration files in the system documentation." + "check": "If the DBMS or DBMS host is not shared by production and\n development activities, this check is not a finding.\n\n Review OS DBA group membership.\n\n If any developer accounts, as identified in the System Security Plan, have been\n assigned DBA privileges, this is a finding.\n\n Note: Though shared production/non-production DBMS installations was allowed\n under previous database STIG guidance, doing so may place it in violation of\n OS, Application, Network or Enclave STIG guidance. Ensure that any shared\n production/non-production DBMS installation meets STIG guidance requirements at\n all levels or mitigate any conflicts in STIG guidance with the AO.", + "fix": "Create separate DBMS host OS groups for developer and production\n DBAs.\n\n Do not assign production DBA OS group membership to accounts used for\n development.\n\n Remove development accounts from production DBA OS group membership.\n\n Recommend establishing a dedicated DBMS host for production DBMS installations.\n A dedicated host system in this case refers to an instance of the operating\n system at a minimum. The operating system may reside on a virtual host machine\n where supported by the DBMS vendor." }, - "code": "control 'V-61699' do\n title \"DBMS backup and restoration files must be protected from unauthorized\n access.\"\n desc \"Information system backup is a critical step in maintaining data\n assurance and availability.\n\n User-level information is data generated by information system and/or\n application users. In order to assure availability of this data in the event of\n a system failure, DoD organizations are required to ensure user-generated data\n is backed up at a defined frequency. This includes data stored on file systems,\n within databases or within any other storage media.\n\n Applications performing backups must be capable of backing up user-level\n information per the DoD-defined frequency.\n\n Lost or compromised DBMS backup and restoration files may lead to not only\n the loss of data, but also the unauthorized access to sensitive data. Backup\n files need the same protections against unauthorized access when stored on\n backup media as when online and actively in use by the database system. In\n addition, the backup media needs to be protected against physical loss. Most\n DBMS's maintain online copies of critical control files to provide transparent\n or easy recovery from hard disk loss or other interruptions to database\n operation.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000145-DB-000098'\n tag \"gid\": 'V-61699'\n tag \"rid\": 'SV-76189r1_rule'\n tag \"stig_id\": 'O121-C2-012500'\n tag \"fix_id\": 'F-67615r1_fix'\n tag \"cci\": ['CCI-000535']\n tag \"nist\": ['CP-9 (a)', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Review file protections assigned to online backup and\n restoration files. Review access protections and procedures for off-line backup\n and restoration files.\n\n If backup or restoration files are subject to unauthorized access, this is a\n finding.\n\n It may be necessary to review backup and restoration procedures to determine\n ownership and access during all phases of backup and recovery.\"\n tag \"fix\": \"Implement protection for backup and restoration files. Document\n personnel and the level of access authorized for each to the backup and\n restoration files in the system documentation.\"\n describe 'A manual review is required to ensure DBMS backup and restoration files are protected from unauthorized\n access' do\n skip 'A manual review is required to ensure DBMS backup and restoration files are protected from unauthorized\n access'\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-61699.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61487.rb", "line": 1 }, - "id": "V-61699" + "id": "V-61487" }, { - "title": "Default demonstration and sample databases, database objects, and\n applications must be removed.", - "desc": "Information systems are capable of providing a wide variety of\n functions and services. Some of the functions and services, provided by\n default, may not be necessary to support essential organizational operations\n (e.g., key missions, functions).\n\n It is detrimental for applications to provide, or install by default,\n functionality exceeding requirements or mission objectives. Examples include,\n but are not limited to, installing advertising software, demonstrations, or\n browser plugins not related to requirements or providing a wide array of\n functionality not required for the mission.\n\n Applications must adhere to the principles of least functionality by\n providing only essential capabilities.\n\n Demonstration and sample database objects and applications present publicly\n known attack points for malicious users. These demonstration and sample objects\n are meant to provide simple examples of coding specific functions and are not\n developed to prevent vulnerabilities from being introduced to the DBMS and host\n system.", + "title": "Application user privilege assignment must be reviewed monthly or more\n frequently to ensure compliance with least privilege and documented policy.", + "desc": "Users granted privileges not required to perform their assigned\n functions are able to make unauthorized modifications to the production data or\n database. Monthly or more frequent periodic review of privilege assignments\n assures that organizational and/or functional changes are reflected\n appropriately.", "descriptions": { - "default": "Information systems are capable of providing a wide variety of\n functions and services. Some of the functions and services, provided by\n default, may not be necessary to support essential organizational operations\n (e.g., key missions, functions).\n\n It is detrimental for applications to provide, or install by default,\n functionality exceeding requirements or mission objectives. Examples include,\n but are not limited to, installing advertising software, demonstrations, or\n browser plugins not related to requirements or providing a wide array of\n functionality not required for the mission.\n\n Applications must adhere to the principles of least functionality by\n providing only essential capabilities.\n\n Demonstration and sample database objects and applications present publicly\n known attack points for malicious users. These demonstration and sample objects\n are meant to provide simple examples of coding specific functions and are not\n developed to prevent vulnerabilities from being introduced to the DBMS and host\n system." + "default": "Users granted privileges not required to perform their assigned\n functions are able to make unauthorized modifications to the production data or\n database. Monthly or more frequent periodic review of privilege assignments\n assures that organizational and/or functional changes are reflected\n appropriately." }, "impact": 0.5, "refs": [], "tags": { - "gtitle": "SRG-APP-000141-DB-000090", - "gid": "V-61677", - "rid": "SV-76167r3_rule", - "stig_id": "O121-C2-011500", - "fix_id": "F-67591r1_fix", + "gtitle": "SRG-APP-000516-DB-999900", + "gid": "V-61455", + "rid": "SV-75945r1_rule", + "stig_id": "O121-BP-023400", + "fix_id": "F-67371r1_fix", "cci": [ - "CCI-000381" + "CCI-000366" ], "nist": [ - "CM-7 a", + "CM-6 b", "Rev_4" ], "false_negatives": null, @@ -3087,35 +3179,39 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "If Oracle is hosted on a server that does not support\n production systems, and is designated for the deployment of samples and\n demonstrations, this is not applicable (NA).\n\n Review documentation and websites from Oracle and any other relevant vendors\n for vendor-provided demonstration or sample databases, database applications,\n schemas, objects, and files.\n\n Review the Oracle DBMS to determine if any of the demonstration and sample\n databases, schemas, database applications, or files are installed in the\n database or are included with the DBMS application. If any are present in the\n database or are included with the DBMS application, this is a finding.\n\n The Oracle Default Sample Schema User Accounts are:\n\n BI\n Owns the Business Intelligence schema included in the Oracle Sample Schemas.\n\n HR\n Manages the Human Resources schema. Schema stores information about the\n employees and the facilities of the company.\n\n OE\n Manages the Order Entry schema. Schema stores product inventories and sales of\n the company's products through various channels.\n\n PM\n Manages the Product Media schema. Schema contains descriptions and detailed\n information about each product sold by the company.\n\n IX\n Manages the Information Exchange schema. Schema manages shipping through\n business-to-business (B2B) applications database.\n\n SH\n Manages the Sales schema. Schema stores statistics to facilitate business\n decisions.\n\n SCOTT\n A demonstration account with a simple schema.\n\n Connect to Oracle as SYSDBA; run the following SQL to check for presence of\n Oracle Default Sample Schema User Accounts:\n select distinct(username) from dba_users where username in\n ('BI','HR','OE','PM','IX','SH','SCOTT');\n\n If any of the users listed above is returned it means that there are demo\n programs installed, so this is a finding.\n ", - "fix": "Remove any demonstration and sample databases, database\n applications, objects, and files from the DBMS.\n\n To remove an account and all objects owned by that account (using BI as an\n example):\n DROP USER BI CASCADE;\n\n To remove objects without removing their owner, use the appropriate DROP\n statement (DROP TABLE, DROP VIEW, etc.)." + "check": "Review policy, procedures and implementation evidence to\n determine if periodic reviews of user privileges by the ISSO are being\n performed.\n\n Evidence may consist of email or other correspondence that acknowledges receipt\n of periodic reports and notification of review between the DBA and ISSO or\n other auditors as assigned.\n\n If policy and procedures are incomplete or no evidence of implementation\n exists, this is a finding.", + "fix": "Develop, document and implement policy and procedures for\n periodic review of database user accounts and privilege assignments.\n\n Include methods to provide evidence of review in the procedures to verify\n reviews occur in accordance with the procedures." }, - "code": "control 'V-61677' do\n title \"Default demonstration and sample databases, database objects, and\n applications must be removed.\"\n desc \"Information systems are capable of providing a wide variety of\n functions and services. Some of the functions and services, provided by\n default, may not be necessary to support essential organizational operations\n (e.g., key missions, functions).\n\n It is detrimental for applications to provide, or install by default,\n functionality exceeding requirements or mission objectives. Examples include,\n but are not limited to, installing advertising software, demonstrations, or\n browser plugins not related to requirements or providing a wide array of\n functionality not required for the mission.\n\n Applications must adhere to the principles of least functionality by\n providing only essential capabilities.\n\n Demonstration and sample database objects and applications present publicly\n known attack points for malicious users. These demonstration and sample objects\n are meant to provide simple examples of coding specific functions and are not\n developed to prevent vulnerabilities from being introduced to the DBMS and host\n system.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000141-DB-000090'\n tag \"gid\": 'V-61677'\n tag \"rid\": 'SV-76167r3_rule'\n tag \"stig_id\": 'O121-C2-011500'\n tag \"fix_id\": 'F-67591r1_fix'\n tag \"cci\": ['CCI-000381']\n tag \"nist\": ['CM-7 a', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"If Oracle is hosted on a server that does not support\n production systems, and is designated for the deployment of samples and\n demonstrations, this is not applicable (NA).\n\n Review documentation and websites from Oracle and any other relevant vendors\n for vendor-provided demonstration or sample databases, database applications,\n schemas, objects, and files.\n\n Review the Oracle DBMS to determine if any of the demonstration and sample\n databases, schemas, database applications, or files are installed in the\n database or are included with the DBMS application. If any are present in the\n database or are included with the DBMS application, this is a finding.\n\n The Oracle Default Sample Schema User Accounts are:\n\n BI\n Owns the Business Intelligence schema included in the Oracle Sample Schemas.\n\n HR\n Manages the Human Resources schema. Schema stores information about the\n employees and the facilities of the company.\n\n OE\n Manages the Order Entry schema. Schema stores product inventories and sales of\n the company's products through various channels.\n\n PM\n Manages the Product Media schema. Schema contains descriptions and detailed\n information about each product sold by the company.\n\n IX\n Manages the Information Exchange schema. Schema manages shipping through\n business-to-business (B2B) applications database.\n\n SH\n Manages the Sales schema. Schema stores statistics to facilitate business\n decisions.\n\n SCOTT\n A demonstration account with a simple schema.\n\n Connect to Oracle as SYSDBA; run the following SQL to check for presence of\n Oracle Default Sample Schema User Accounts:\n select distinct(username) from dba_users where username in\n ('BI','HR','OE','PM','IX','SH','SCOTT');\n\n If any of the users listed above is returned it means that there are demo\n programs installed, so this is a finding.\n \"\n tag \"fix\": \"Remove any demonstration and sample databases, database\n applications, objects, and files from the DBMS.\n\n To remove an account and all objects owned by that account (using BI as an\n example):\n DROP USER BI CASCADE;\n\n To remove objects without removing their owner, use the appropriate DROP\n statement (DROP TABLE, DROP VIEW, etc.).\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n sample_schema_user_accounts = sql.query(\"select distinct(username) from dba_users where username in\n ('BI','HR','OE','PM','IX','SH','SCOTT');\").column('username')\n\n describe 'The list of oracle default sample schema user accounts' do\n subject { sample_schema_user_accounts }\n it { should be_empty }\n end\nend\n", + "code": "control 'V-61455' do\n title \"Application user privilege assignment must be reviewed monthly or more\n frequently to ensure compliance with least privilege and documented policy.\"\n desc \"Users granted privileges not required to perform their assigned\n functions are able to make unauthorized modifications to the production data or\n database. Monthly or more frequent periodic review of privilege assignments\n assures that organizational and/or functional changes are reflected\n appropriately.\"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000516-DB-999900'\n tag \"gid\": 'V-61455'\n tag \"rid\": 'SV-75945r1_rule'\n tag \"stig_id\": 'O121-BP-023400'\n tag \"fix_id\": 'F-67371r1_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, procedures and implementation evidence to\n determine if periodic reviews of user privileges by the ISSO are being\n performed.\n\n Evidence may consist of email or other correspondence that acknowledges receipt\n of periodic reports and notification of review between the DBA and ISSO or\n other auditors as assigned.\n\n If policy and procedures are incomplete or no evidence of implementation\n exists, this is a finding.\"\n tag \"fix\": \"Develop, document and implement policy and procedures for\n periodic review of database user accounts and privilege assignments.\n\n Include methods to provide evidence of review in the procedures to verify\n reviews occur in accordance with the procedures.\"\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 application user privilege assignment are reviewed monthly or more frequently to ensure compliance with least privilege and documented policy. The database roles to review are: #{database_roles}\" do\n skip \"A manual review is required to ensure application user privilege assignment are reviewed monthly or more frequently to ensure compliance with least privilege and documented policy. The database roles to review are: #{database_roles}\"\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61677.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61455.rb", "line": 1 }, - "id": "V-61677" + "id": "V-61455" }, { - "title": "Use of the DBMS software installation account must be restricted.", - "desc": "This requirement is intended to limit exposure due to operating from\n within a privileged account or role. The inclusion of role is intended to\n address those situations where an access control policy, such as Role Based\n Access Control (RBAC), is being implemented and where a change of role provides\n the same degree of assurance in the change of access authorizations for both\n the user and all processes acting on behalf of the user as would be provided by\n a change between a privileged and non-privileged account.\n\n To limit exposure when operating from within a privileged account or role,\n the application must support organizational requirements that users of\n information system accounts, or roles, with access to organization-defined\n lists of security functions or security-relevant information, use\n non-privileged accounts, or roles, when accessing other (non-security) system\n functions.\n\n Use of privileged accounts for non-administrative purposes puts data at\n risk of unintended or unauthorized loss, modification, or exposure. In\n particular, DBA accounts if used for non-administration application development\n or application maintenance can lead to miss-assignment of privileges where\n privileges are inherited by object owners. It may also lead to loss or\n compromise of application data where the elevated privileges bypass controls\n designed in and provided by applications.\n\n The DBMS software installation account may require privileges not required\n for database administration or other functions. Use of accounts configured with\n excess privileges may result in the loss or compromise of data or system\n settings due to elevated privileges that bypass controls designed to protect\n them.\n\n This requirement is particularly important because Oracle equates the\n installation account with the SYS account - the super-DBA. Once logged on to\n the operating system, this account can connect to the database AS SYSDBA\n without further authentication. It is very powerful and, by virtue of not\n being linked to any one person, cannot be audited to the level of the\n individual.", + "title": "Databases utilizing Discretionary Access Control (DAC) must enforce a\n policy that limits propagation of access rights.", + "desc": "Discretionary Access Control (DAC) is based on the premise that\n individual users are owners of objects and therefore have discretion over\n who should be authorized to access the object and in which mode (e.g., read or\n write). Ownership is usually acquired as a consequence of creating the object\n or via specified ownership assignment.\n\n DAC allows the owner to determine who will have access to objects they\n control. An example of DAC includes user-controlled file permissions. DAC\n models have the potential for the access controls to propagate without limit,\n resulting in unauthorized access to said objects.\n\n When applications provide a discretionary access control mechanism, the\n application must be able to limit the propagation of those access rights.\n\n The DBMS must ensure the recipient of permissions possesses only the access\n intended. The database must enforce the ability to limit rights propagation if\n that is the intent of the grantor. If the propagation of access rights is not\n limited, users with rights to objects they do not own can continue to grant\n rights to those objects to other users without limit.\n\n This is default behavior for Oracle.", "descriptions": { - "default": "This requirement is intended to limit exposure due to operating from\n within a privileged account or role. The inclusion of role is intended to\n address those situations where an access control policy, such as Role Based\n Access Control (RBAC), is being implemented and where a change of role provides\n the same degree of assurance in the change of access authorizations for both\n the user and all processes acting on behalf of the user as would be provided by\n a change between a privileged and non-privileged account.\n\n To limit exposure when operating from within a privileged account or role,\n the application must support organizational requirements that users of\n information system accounts, or roles, with access to organization-defined\n lists of security functions or security-relevant information, use\n non-privileged accounts, or roles, when accessing other (non-security) system\n functions.\n\n Use of privileged accounts for non-administrative purposes puts data at\n risk of unintended or unauthorized loss, modification, or exposure. In\n particular, DBA accounts if used for non-administration application development\n or application maintenance can lead to miss-assignment of privileges where\n privileges are inherited by object owners. It may also lead to loss or\n compromise of application data where the elevated privileges bypass controls\n designed in and provided by applications.\n\n The DBMS software installation account may require privileges not required\n for database administration or other functions. Use of accounts configured with\n excess privileges may result in the loss or compromise of data or system\n settings due to elevated privileges that bypass controls designed to protect\n them.\n\n This requirement is particularly important because Oracle equates the\n installation account with the SYS account - the super-DBA. Once logged on to\n the operating system, this account can connect to the database AS SYSDBA\n without further authentication. It is very powerful and, by virtue of not\n being linked to any one person, cannot be audited to the level of the\n individual." + "default": "Discretionary Access Control (DAC) is based on the premise that\n individual users are owners of objects and therefore have discretion over\n who should be authorized to access the object and in which mode (e.g., read or\n write). Ownership is usually acquired as a consequence of creating the object\n or via specified ownership assignment.\n\n DAC allows the owner to determine who will have access to objects they\n control. An example of DAC includes user-controlled file permissions. DAC\n models have the potential for the access controls to propagate without limit,\n resulting in unauthorized access to said objects.\n\n When applications provide a discretionary access control mechanism, the\n application must be able to limit the propagation of those access rights.\n\n The DBMS must ensure the recipient of permissions possesses only the access\n intended. The database must enforce the ability to limit rights propagation if\n that is the intent of the grantor. If the propagation of access rights is not\n limited, users with rights to objects they do not own can continue to grant\n rights to those objects to other users without limit.\n\n This is default behavior for Oracle." }, - "impact": 0.7, - "refs": [], + "impact": 0.5, + "refs": [ + { + "ref": [] + } + ], "tags": { - "gtitle": "SRG-APP-000063-DB-000022", - "gid": "V-61865", - "rid": "SV-76355r2_rule", - "stig_id": "O121-OS-004600", - "fix_id": "F-67781r4_fix", + "gtitle": "SRG-APP-000085-DB-000038", + "gid": "V-61617", + "rid": "SV-76107r1_rule", + "stig_id": "O121-C2-006600", + "fix_id": "F-67533r1_fix", "cci": [ - "CCI-000366" + "CCI-002165" ], "nist": [ - "CM-6 b", + "AC-3 (4)", "Rev_4" ], "false_negatives": null, @@ -3128,35 +3224,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Review system documentation to identify the installation\n account.\n\n Verify whether the account is used for anything involving interactive activity\n beyond DBMS software installation, upgrade, and maintenance actions.\n\n If the account is used for anything involving interactive activity beyond DBMS\n software installation, upgrade, and maintenance actions, this is a finding.", - "fix": "Restrict interactive use of the DBMS software installation\n account to DBMS software installation, upgrade, and maintenance actions only.\n\n If possible, disable installation accounts when authorized actions are not\n being performed. Otherwise, disable the use of the account(s) for interactive\n activity." + "check": "Verify the DBMS has the ability to grant permissions without\n the grantee receiving the right to grant those same permissions to another user.\n\n Review organization policies regarding access propagation. If an access\n propagation policy limiting the propagation of rights does not exist, this is a\n finding.\n\n Review DBMS configuration to verify access propagation policies are enforced by\n the DBMS as configured. If the DBMS does not enforce the access propagation\n policy, this is a finding.", + "fix": "Create and document an access propagation policy that limits the\n propagation of rights.\n\n Configure the DBMS to enforce the access propagation policy.\n\n When a user is granted access to an object, they have access to the object.\n When a user is granted access to an object with the GRANT option, then they can\n provide permissions to others. Without the GRANT option, a user cannot grant\n access to an object. No configuration is required." }, - "code": "control 'V-61865' do\n title 'Use of the DBMS software installation account must be restricted.'\n desc \"This requirement is intended to limit exposure due to operating from\n within a privileged account or role. The inclusion of role is intended to\n address those situations where an access control policy, such as Role Based\n Access Control (RBAC), is being implemented and where a change of role provides\n the same degree of assurance in the change of access authorizations for both\n the user and all processes acting on behalf of the user as would be provided by\n a change between a privileged and non-privileged account.\n\n To limit exposure when operating from within a privileged account or role,\n the application must support organizational requirements that users of\n information system accounts, or roles, with access to organization-defined\n lists of security functions or security-relevant information, use\n non-privileged accounts, or roles, when accessing other (non-security) system\n functions.\n\n Use of privileged accounts for non-administrative purposes puts data at\n risk of unintended or unauthorized loss, modification, or exposure. In\n particular, DBA accounts if used for non-administration application development\n or application maintenance can lead to miss-assignment of privileges where\n privileges are inherited by object owners. It may also lead to loss or\n compromise of application data where the elevated privileges bypass controls\n designed in and provided by applications.\n\n The DBMS software installation account may require privileges not required\n for database administration or other functions. Use of accounts configured with\n excess privileges may result in the loss or compromise of data or system\n settings due to elevated privileges that bypass controls designed to protect\n them.\n\n This requirement is particularly important because Oracle equates the\n installation account with the SYS account - the super-DBA. Once logged on to\n the operating system, this account can connect to the database AS SYSDBA\n without further authentication. It is very powerful and, by virtue of not\n being linked to any one person, cannot be audited to the level of the\n individual.\n \"\n impact 0.7\n tag \"gtitle\": 'SRG-APP-000063-DB-000022'\n tag \"gid\": 'V-61865'\n tag \"rid\": 'SV-76355r2_rule'\n tag \"stig_id\": 'O121-OS-004600'\n tag \"fix_id\": 'F-67781r4_fix'\n tag \"cci\": ['CCI-000366']\n tag \"nist\": ['CM-6 b', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Review system documentation to identify the installation\n account.\n\n Verify whether the account is used for anything involving interactive activity\n beyond DBMS software installation, upgrade, and maintenance actions.\n\n If the account is used for anything involving interactive activity beyond DBMS\n software installation, upgrade, and maintenance actions, this is a finding.\"\n tag \"fix\": \"Restrict interactive use of the DBMS software installation\n account to DBMS software installation, upgrade, and maintenance actions only.\n\n If possible, disable installation accounts when authorized actions are not\n being performed. Otherwise, disable the use of the account(s) for interactive\n activity.\"\n describe 'A manual review is required to ensure the use of the DBMS software installation account is restricted' do\n skip 'A manual review is required to ensure the use of the DBMS software installation account is restricted'\n end\nend\n", + "code": " control 'V-61617' do\n title \"Databases utilizing Discretionary Access Control (DAC) must enforce a\n policy that limits propagation of access rights.\"\n desc \"Discretionary Access Control (DAC) is based on the premise that\n individual users are owners of objects and therefore have discretion over\n who should be authorized to access the object and in which mode (e.g., read or\n write). Ownership is usually acquired as a consequence of creating the object\n or via specified ownership assignment.\n\n DAC allows the owner to determine who will have access to objects they\n control. An example of DAC includes user-controlled file permissions. DAC\n models have the potential for the access controls to propagate without limit,\n resulting in unauthorized access to said objects.\n\n When applications provide a discretionary access control mechanism, the\n application must be able to limit the propagation of those access rights.\n\n The DBMS must ensure the recipient of permissions possesses only the access\n intended. The database must enforce the ability to limit rights propagation if\n that is the intent of the grantor. If the propagation of access rights is not\n limited, users with rights to objects they do not own can continue to grant\n rights to those objects to other users without limit.\n\n This is default behavior for Oracle.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000085-DB-000038'\n tag \"gid\": 'V-61617'\n tag \"rid\": 'SV-76107r1_rule'\n tag \"stig_id\": 'O121-C2-006600'\n tag \"fix_id\": 'F-67533r1_fix'\n tag \"cci\": ['CCI-002165']\n tag \"nist\": ['AC-3 (4)', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Verify the DBMS has the ability to grant permissions without\n the grantee receiving the right to grant those same permissions to another user.\n\n Review organization policies regarding access propagation. If an access\n propagation policy limiting the propagation of rights does not exist, this is a\n finding.\n\n Review DBMS configuration to verify access propagation policies are enforced by\n the DBMS as configured. If the DBMS does not enforce the access propagation\n policy, this is a finding.\"\n tag \"fix\": \"Create and document an access propagation policy that limits the\n propagation of rights.\n\n Configure the DBMS to enforce the access propagation policy.\n\n When a user is granted access to an object, they have access to the object.\n When a user is granted access to an object with the GRANT option, then they can\n provide permissions to others. Without the GRANT option, a user cannot grant\n access to an object. No configuration is required.\"\n describe 'A manaul review is required to ensure the Databases utilizing Discretionary Access Control (DAC) enforce a\n policy that limits propagation of access rights' do\n skip 'A manaul review is required to ensure the Databases utilizing Discretionary Access Control (DAC) enforce a\n policy that limits propagation of access rights'\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61865.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61617.rb", "line": 1 }, - "id": "V-61865" + "id": "V-61617" }, { - "title": "The DBMS must produce audit records containing sufficient information\n to establish when (date and time) the 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's important, for accurate forensic analysis, to know exactly\n when specific actions were performed. This requires the date and time an audit\n record is referring to. If date and time information is not recorded and stored\n with the audit record, the record itself is of very limited use.", + "title": "The DBMS must separate user functionality (including user interface\n services) from database management functionality.", + "desc": "Information system management functionality includes functions\n necessary to administer databases, network components, workstations, or\n servers, and typically requires privileged user access.\n\n The separation of user functionality from information system management\n functionality is either physical or logical and is accomplished by using\n different computers, different central processing units, different instances of\n the operating system, different network addresses, combinations of these\n methods, or other methods, as appropriate.\n\n An example of this type of separation is observed in web administrative\n interfaces that use separate authentication methods for users of any other\n information system resources.\n\n This may include isolating the administrative interface on a different\n domain and with additional access controls.\n\n If administrative functionality or information regarding DBMS management is\n presented on an interface available for users, information on DBMS settings may\n be inadvertently made available to the user.", "descriptions": { - "default": "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's important, for accurate forensic analysis, to know exactly\n when specific actions were performed. This requires the date and time an audit\n record is referring to. If date and time information is not recorded and stored\n with the audit record, the record itself is of very limited use." + "default": "Information system management functionality includes functions\n necessary to administer databases, network components, workstations, or\n servers, and typically requires privileged user access.\n\n The separation of user functionality from information system management\n functionality is either physical or logical and is accomplished by using\n different computers, different central processing units, different instances of\n the operating system, different network addresses, combinations of these\n methods, or other methods, as appropriate.\n\n An example of this type of separation is observed in web administrative\n interfaces that use separate authentication methods for users of any other\n information system resources.\n\n This may include isolating the administrative interface on a different\n domain and with additional access controls.\n\n If administrative functionality or information regarding DBMS management is\n presented on an interface available for users, information on DBMS settings may\n be inadvertently made available to the user." }, "impact": 0.5, "refs": [], "tags": { - "gtitle": "SRG-APP-000096-DB-000040", - "gid": "V-61631", - "rid": "SV-76121r1_rule", - "stig_id": "O121-C2-007500", - "fix_id": "F-67881r1_fix", + "gtitle": "SRG-APP-000211-DB-000122", + "gid": "V-61883", + "rid": "SV-76373r1_rule", + "stig_id": "O121-P2-017300", + "fix_id": "F-67799r1_fix", "cci": [ - "CCI-000131" + "CCI-001082" ], "nist": [ - "AU-3", + "SC-2", "Rev_4" ], "false_negatives": null, @@ -3169,35 +3265,35 @@ "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 when events occurred, 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 no timestamp, 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 when events occurred, 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 no timestamp, 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 the date and\n time of any user/subject or process associated with the event. If preferred,\n 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 To ensure auditable events are captured:\n Link the oracle binary with uniaud_on, and then restart the database.\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" + "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-61631' do\n title \"The DBMS must produce audit records containing sufficient information\n to establish when (date and time) the 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's important, for accurate forensic analysis, to know exactly\n when specific actions were performed. This requires the date and time an audit\n record is referring to. If date and time information is not recorded and stored\n with the audit record, the record itself is of very limited use.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000096-DB-000040'\n tag \"gid\": 'V-61631'\n tag \"rid\": 'SV-76121r1_rule'\n tag \"stig_id\": 'O121-C2-007500'\n tag \"fix_id\": 'F-67881r1_fix'\n tag \"cci\": ['CCI-000131']\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 when events occurred, 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 no timestamp, 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 when events occurred, 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 no timestamp, 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 the date and\n time of any user/subject or process associated with the event. If preferred,\n 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 To ensure auditable events are captured:\n Link the oracle binary with uniaud_on, and then restart the database.\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\"\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-61883' do\n title \"The DBMS must separate user functionality (including user interface\n services) from database management functionality.\"\n desc \"Information system management functionality includes functions\n necessary to administer databases, network components, workstations, or\n servers, and typically requires privileged user access.\n\n The separation of user functionality from information system management\n functionality is either physical or logical and is accomplished by using\n different computers, different central processing units, different instances of\n the operating system, different network addresses, combinations of these\n methods, or other methods, as appropriate.\n\n An example of this type of separation is observed in web administrative\n interfaces that use separate authentication methods for users of any other\n information system resources.\n\n This may include isolating the administrative interface on a different\n domain and with additional access controls.\n\n If administrative functionality or information regarding DBMS management is\n presented on an interface available for users, information on DBMS settings may\n be inadvertently made available to the user.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000211-DB-000122'\n tag \"gid\": 'V-61883'\n tag \"rid\": 'SV-76373r1_rule'\n tag \"stig_id\": 'O121-P2-017300'\n tag \"fix_id\": 'F-67799r1_fix'\n tag \"cci\": ['CCI-001082']\n tag \"nist\": ['SC-2', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Check DBMS settings and vendor documentation to verify\n administrative functionality is separate from user functionality.\n\n If administrator and general user functionality is not separated either\n physically or logically, this is a finding.\"\n tag \"fix\": \"Configure DBMS settings to separate database administration and\n general user functionality. Provide those who have both administrative and\n general-user responsibilities with separate accounts for these separate\n functions.\"\n describe 'A manual review is required to ensure the DBMS separates user functionality (including user interface\n services) from database management functionality' do\n skip 'A manual review is required to ensure the DBMS separates user functionality (including user interface\n services) from database management functionality'\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61631.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61883.rb", "line": 1 }, - "id": "V-61631" + "id": "V-61883" }, { - "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": "Unused database components, DBMS software, and database objects must\n be removed.", + "desc": "Information systems are capable of providing a wide variety of\n functions and services. Some of the functions and services, provided by\n default, may not be necessary to support essential organizational operations\n (e.g., key missions, functions).\n\n It is detrimental for applications to provide, or install by default,\n functionality exceeding requirements or mission objectives. Examples include,\n but are not limited to, installing advertising software, demonstrations, or\n browser plug-ins not related to requirements or providing a wide array of\n functionality not required for the mission.\n\n Applications must adhere to the principles of least functionality by\n providing only essential capabilities.\n\n Demonstration and sample database objects and applications present publicly\n known attack points for malicious users. These demonstration and sample objects\n are meant to provide simple examples of coding specific functions and are not\n developed to prevent vulnerabilities from being introduced to the DBMS and host\n system.\n\n Unused and unnecessary DBMS components increase the attack vector for the\n DBMS by introducing additional targets for attack. By minimizing the services\n and applications installed on the system, the number of potential\n vulnerabilities is reduced.", "descriptions": { - "default": "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": "Information systems are capable of providing a wide variety of\n functions and services. Some of the functions and services, provided by\n default, may not be necessary to support essential organizational operations\n (e.g., key missions, functions).\n\n It is detrimental for applications to provide, or install by default,\n functionality exceeding requirements or mission objectives. Examples include,\n but are not limited to, installing advertising software, demonstrations, or\n browser plug-ins not related to requirements or providing a wide array of\n functionality not required for the mission.\n\n Applications must adhere to the principles of least functionality by\n providing only essential capabilities.\n\n Demonstration and sample database objects and applications present publicly\n known attack points for malicious users. These demonstration and sample objects\n are meant to provide simple examples of coding specific functions and are not\n developed to prevent vulnerabilities from being introduced to the DBMS and host\n system.\n\n Unused and unnecessary DBMS components increase the attack vector for the\n DBMS by introducing additional targets for attack. By minimizing the services\n and applications installed on the system, the number of potential\n vulnerabilities is reduced." }, - "impact": 0.5, + "impact": 0, "refs": [], "tags": { - "gtitle": "SRG-APP-000101-DB-000044", - "gid": "V-61641", - "rid": "SV-76131r1_rule", - "stig_id": "O121-C2-008000", - "fix_id": "F-67553r2_fix", + "gtitle": "SRG-APP-000141-DB-000091", + "gid": "V-61679", + "rid": "SV-76169r2_rule", + "stig_id": "O121-C2-011600", + "fix_id": "F-67593r2_fix", "cci": [ - "CCI-000135" + "CCI-000381" ], "nist": [ - "AU-3 (1)", + "CM-7 a", "Rev_4" ], "false_negatives": null, @@ -3210,35 +3306,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": "Run this query to produce a list of components and features\n installed with the database:\n\n SELECT comp_id, comp_name, version, status from dba_registry\n where comp_id not in ('CATALOG','CATPROC','XDB');\n\n Review the list. If unused components are installed and are not documented and\n authorized, this is a finding.\n\n Starting with releases 11.1.0.7.x and above, all products are installed by\n default and the option to customize the product/component selection is no\n longer possible with the exception of those listed here:\n\n Oracle JVM,\n Oracle Text,\n Oracle Multimedia,\n Oracle OLAP,\n Oracle Spatial,\n Oracle Label Security,\n Oracle Application Express,\n Oracle Database Vault", + "fix": "If any components are required for operation of applications that\n will be accessing the DBMS, include them in the system documentation.\n\n One cannot remove components, either via Database Configuration Assistant\n (DBCA) or manually once the database has been created, either from a container\n or a non-container database.\n\n One can, however, use DBCA to create a non-container database and remove\n components during the creation process, before the database is created.\n\n When using DBCA to create a custom non-container database, select\n creation mode = advanced\n Database Template = Custom\n Database Options..Database Component.\n\n Components that can be selected or de-selected are:\n Oracle JVM, Oracle Text, Oracle Multimedia, Oracle OLAP, Oracle Spatial, Oracle\n Label Security, Oracle Application Express, Oracle Database Vault\n\n For a container database (CDB), the CDB$ROOT must have all possible database\n components available. This is because, when a pluggable database (PDB) is\n plugged into the CDB, the CDB must have the same components installed as the\n PDB. Since we do not know what components the PDBS may have, the CDB must be\n able to support all possible PDB configurations.\n\n Components installed in the CDB$ROOT do not need to be licensed. Components\n are only considered to be used if they are installed in the PDB.\n\n To configure a PDB to only use specific components, do the following:\n\n 1) Create a non-CDB 12.1 database and configure that database with the\n components desired.\n\n 2) Plug the non-CDB database into a CDB database, creating a new PDB. If\n wanted, can then create additional clones from the new PDB." }, - "code": "control 'V-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-61679' do\n title \"Unused database components, DBMS software, and database objects must\n be removed.\"\n desc \"Information systems are capable of providing a wide variety of\n functions and services. Some of the functions and services, provided by\n default, may not be necessary to support essential organizational operations\n (e.g., key missions, functions).\n\n It is detrimental for applications to provide, or install by default,\n functionality exceeding requirements or mission objectives. Examples include,\n but are not limited to, installing advertising software, demonstrations, or\n browser plug-ins not related to requirements or providing a wide array of\n functionality not required for the mission.\n\n Applications must adhere to the principles of least functionality by\n providing only essential capabilities.\n\n Demonstration and sample database objects and applications present publicly\n known attack points for malicious users. These demonstration and sample objects\n are meant to provide simple examples of coding specific functions and are not\n developed to prevent vulnerabilities from being introduced to the DBMS and host\n system.\n\n Unused and unnecessary DBMS components increase the attack vector for the\n DBMS by introducing additional targets for attack. By minimizing the services\n and applications installed on the system, the number of potential\n vulnerabilities is reduced.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000141-DB-000091'\n tag \"gid\": 'V-61679'\n tag \"rid\": 'SV-76169r2_rule'\n tag \"stig_id\": 'O121-C2-011600'\n tag \"fix_id\": 'F-67593r2_fix'\n tag \"cci\": ['CCI-000381']\n tag \"nist\": ['CM-7 a', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Run this query to produce a list of components and features\n installed with the database:\n\n SELECT comp_id, comp_name, version, status from dba_registry\n where comp_id not in ('CATALOG','CATPROC','XDB');\n\n Review the list. If unused components are installed and are not documented and\n authorized, this is a finding.\n\n Starting with releases 11.1.0.7.x and above, all products are installed by\n default and the option to customize the product/component selection is no\n longer possible with the exception of those listed here:\n\n Oracle JVM,\n Oracle Text,\n Oracle Multimedia,\n Oracle OLAP,\n Oracle Spatial,\n Oracle Label Security,\n Oracle Application Express,\n Oracle Database Vault\"\n tag \"fix\": \"If any components are required for operation of applications that\n will be accessing the DBMS, include them in the system documentation.\n\n One cannot remove components, either via Database Configuration Assistant\n (DBCA) or manually once the database has been created, either from a container\n or a non-container database.\n\n One can, however, use DBCA to create a non-container database and remove\n components during the creation process, before the database is created.\n\n When using DBCA to create a custom non-container database, select\n creation mode = advanced\n Database Template = Custom\n Database Options..Database Component.\n\n Components that can be selected or de-selected are:\n Oracle JVM, Oracle Text, Oracle Multimedia, Oracle OLAP, Oracle Spatial, Oracle\n Label Security, Oracle Application Express, Oracle Database Vault\n\n For a container database (CDB), the CDB$ROOT must have all possible database\n components available. This is because, when a pluggable database (PDB) is\n plugged into the CDB, the CDB must have the same components installed as the\n PDB. Since we do not know what components the PDBS may have, the CDB must be\n able to support all possible PDB configurations.\n\n Components installed in the CDB$ROOT do not need to be licensed. Components\n are only considered to be used if they are installed in the PDB.\n\n To configure a PDB to only use specific components, do the following:\n\n 1) Create a non-CDB 12.1 database and configure that database with the\n components desired.\n\n 2) Plug the non-CDB database into a CDB database, creating a new PDB. If\n wanted, can then create additional clones from the new PDB.\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n list_of_installed_components = sql.query(\"SELECT comp_id, comp_name, version, status from dba_registry where comp_id not in ('CATALOG','CATPROC','XDB');\").column('comp_name').uniq\n if list_of_installed_components.empty?\n impact 0.0\n describe 'There are no oracle database components installed, control N/A' do\n skip 'TThere are no oracle database components installed, control N/A'\n end\n else\n list_of_installed_components.each do |component|\n describe \"The installed oracle database components: #{component}\" do\n subject { component }\n it { should be_in input('allowed_oracledb_components') }\n end\n end\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61641.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61679.rb", "line": 1 }, - "id": "V-61641" + "id": "V-61679" }, { - "title": "Object permissions granted to PUBLIC must be restricted.", - "desc": "Permissions on objects may be granted to the user group PUBLIC.\n Because every database user is a member of the PUBLIC group, granting object\n permissions to PUBLIC gives all users in the database access to that object. In\n a secure environment, granting object permissions to PUBLIC must be restricted\n to those objects that all users are allowed to access. The policy does not\n require object permissions assigned to PUBLIC by the installation of Oracle\n Database server components be revoked.", + "title": "The DBMS must use organization-defined replay-resistant authentication\n mechanisms for network access to non-privileged accounts.", + "desc": "An authentication process resists replay attacks if it is impractical\n to achieve a successful authentication by recording and replaying a previous\n authentication message.\n\n Techniques used to address this include protocols using nonces (e.g.,\n numbers generated for a specific one-time use) or challenges (e.g., TLS,\n WS_Security), and time synchronous or challenge-response one-time\n authenticators.\n\n Replay attacks, if successfully used against a database account, could\n result in access to database data. A successful replay attack against a\n non-privileged database account could result in a compromise of data stored on\n the database.\n\n Oracle Database enables you to encrypt data that is sent over a network.\n There is no distinction between privileged and non-privileged accounts.\n\n Encryption of network data provides data privacy so that unauthorized\n parties are not able to view plaintext data as it passes over the network.\n Oracle Database also provides protection against two forms of active attacks.\n\n Data modification attack: An unauthorized party intercepting data in\n transit, altering it, and retransmitting it is a data modification attack. For\n example, intercepting a $100 bank deposit, changing the amount to $10,000, and\n retransmitting the higher amount is a data modification attack.\n\n Replay attack: Repetitively retransmitting an entire set of valid data is\n a replay attack, such as intercepting a $100 bank withdrawal and retransmitting\n it ten times, thereby receiving $1,000.\n\n AES and Triple-DES operate in outer Cipher Block Chaining (CBC) mode.\n\n The DES algorithm uses a 56-bit key length.\n\n SHA-1 is in the process of being removed from service within the DoD and\n it's use is to be limited during the transition to SHA-2. Use of SHA-1 for\n digital signature generation is prohibited. Allowable uses during the\n transition include CHECKSUM usage and verification of legacy certificate\n signatures. SHA-1 is considered a temporary solution during legacy application\n transitionary periods and should not be engineered into new applications. SHA-2\n is the path forward for DoD.", "descriptions": { - "default": "Permissions on objects may be granted to the user group PUBLIC.\n Because every database user is a member of the PUBLIC group, granting object\n permissions to PUBLIC gives all users in the database access to that object. In\n a secure environment, granting object permissions to PUBLIC must be restricted\n to those objects that all users are allowed to access. The policy does not\n require object permissions assigned to PUBLIC by the installation of Oracle\n Database server components be revoked." + "default": "An authentication process resists replay attacks if it is impractical\n to achieve a successful authentication by recording and replaying a previous\n authentication message.\n\n Techniques used to address this include protocols using nonces (e.g.,\n numbers generated for a specific one-time use) or challenges (e.g., TLS,\n WS_Security), and time synchronous or challenge-response one-time\n authenticators.\n\n Replay attacks, if successfully used against a database account, could\n result in access to database data. A successful replay attack against a\n non-privileged database account could result in a compromise of data stored on\n the database.\n\n Oracle Database enables you to encrypt data that is sent over a network.\n There is no distinction between privileged and non-privileged accounts.\n\n Encryption of network data provides data privacy so that unauthorized\n parties are not able to view plaintext data as it passes over the network.\n Oracle Database also provides protection against two forms of active attacks.\n\n Data modification attack: An unauthorized party intercepting data in\n transit, altering it, and retransmitting it is a data modification attack. For\n example, intercepting a $100 bank deposit, changing the amount to $10,000, and\n retransmitting the higher amount is a data modification attack.\n\n Replay attack: Repetitively retransmitting an entire set of valid data is\n a replay attack, such as intercepting a $100 bank withdrawal and retransmitting\n it ten times, thereby receiving $1,000.\n\n AES and Triple-DES operate in outer Cipher Block Chaining (CBC) mode.\n\n The DES algorithm uses a 56-bit key length.\n\n SHA-1 is in the process of being removed from service within the DoD and\n it's use is to be limited during the transition to SHA-2. Use of SHA-1 for\n digital signature generation is prohibited. Allowable uses during the\n transition include CHECKSUM usage and verification of legacy certificate\n signatures. SHA-1 is considered a temporary solution during legacy application\n transitionary periods and should not be engineered into new applications. SHA-2\n is the path forward for DoD." }, "impact": 0, - "refs": [], + "refs": [ + { + "ref": [] + } + ], "tags": { - "gtitle": "SRG-APP-000516-DB-999900", - "gid": "V-61439", - "rid": "SV-75929r3_rule", - "stig_id": "O121-BP-022600", - "fix_id": "F-67355r2_fix", + "gtitle": "SRG-APP-000157-DB-000112", + "gid": "V-61715", + "rid": "SV-76205r4_rule", + "stig_id": "O121-C2-013700", + "fix_id": "F-67631r1_fix", "cci": [ - "CCI-000366" + "CCI-001942" ], "nist": [ - "CM-6 b", + "IA-2 (9)", "Rev_4" ], "false_negatives": null, @@ -3251,35 +3351,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "A default Oracle Database installation provides a set of\n predefined administrative accounts and non-administrative accounts. These are\n accounts that have special privileges required to administer areas of the\n database, such as the “CREATE ANY TABLE” or “ALTER SESSION” privilege, or\n “EXECUTE” privileges on packages owned by the SYS schema. The default\n tablespace for administrative accounts is either “SYSTEM” or “SYSAUX”.\n Non-administrative user accounts only have the minimum privileges needed to\n perform their jobs. Their default tablespace is “USERS”.\n\n To protect these accounts from unauthorized access, the installation process\n expires and locks most of these accounts, except where noted below. The\n database administrator is responsible for unlocking and resetting these\n accounts, as required.\n\n Non-Administrative Accounts - Expired and locked:\n APEX_PUBLIC_USER, DIP, FLOWS_040100*, FLOWS_FILES, MDDATA, ORACLE_OCM,\n SPATIAL_CSW_ADMIN_USR, SPATIAL_WFS_ADMIN_USR, XS$NULL\n\n Administrative Accounts - Expired and Locked:\n ANONYMOUS, CTXSTS, EXFSYS, LBACSYS, MDSYS, OLAPSYS, OEDDATA, OWBSYS,\n ORDPLUGINS, ORDSYS, OUTLN, SI_INFORMTN_SCHEMA, WK_TEST, WK_SYS, WKPROXY, WMSYS,\n XDB\n\n Administrative Accounts - Open:\n DBSNMP, MGMT_VIEW, SYS, SYSMAN, SYSTEM\n\n * Subject to change based on version installed\n\n Run the SQL query:\n\n select owner ||'.'|| table_name ||':'|| privilege from dba_tab_privs\n where grantee = 'PUBLIC';\n and owner not in\n ();\n\n (With respect to the list of special accounts that are excluded from this\n requirement, it is expected that the DBA will maintain the list to suit local\n circumstances, adding special accounts as necessary and removing any that are\n not supposed to be in use in the Oracle deployment that is under review.)\n\n If there are any records returned that are not Oracle product accounts, and are\n not documented and authorized, this is a finding.\n\n Note: This check may return false positives where other Oracle product accounts\n are not included in the exclusion list.", - "fix": "Revoke any privileges granted to PUBLIC for objects that are not\n owned by Oracle product accounts.\n\n From SQL*Plus:\n\n revoke [privilege name] from [user name] on [object name];\n\n Assign permissions to custom application user roles based on job functions:\n\n From SQL*Plus:\n\n grant [privilege name] to [user role] on [object name];" + "check": "Review DBMS settings to determine whether organization-defined\n replay-resistant authentication mechanisms for network access to non-privileged\n accounts exist.\n\n If these mechanisms do not exist, this is a finding.\n\n To check that network encryption is enabled and using site-specified encryption\n procedures, look in SQLNET.ORA, located at\n $ORACLE_HOME/network/admin/sqlnet.ora. (Note: This assumes that a single\n sqlnet.ora file, in the default location, is in use. Please see the\n supplemental file \"Non-default sqlnet.ora configurations.pdf\" for how to find\n multiple and/or differently located sqlnet.ora files.) If encryption is set,\n entries like the following will be present:\n\n SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER= (SHA384)\n SQLNET.ENCRYPTION_TYPES_SERVER=(AES256)\n SQLNET.CRYPTO_CHECKSUM_SERVER = required\n\n SQLNET.CRYPTO_CHECKSUM_TYPES_CLIENT= (SHA384)\n SQLNET.ENCRYPTION_TYPES_CLIENT= (AES256)\n SQLNET.CRYPTO_CHECKSUM_CLIENT = requested\n\n (The values assigned to the parameters may be different, the combination of\n parameters may be different, and not all of the example parameters will\n necessarily exist in the file.)", + "fix": "Configure DBMS, OS and/or enterprise-level authentication/access\n mechanism to require organization-defined replay-resistant authentication\n mechanisms for network access to non-privileged accounts.\n\n If appropriate, apply Oracle Data Network Encryption to protect against replay\n mechanisms." }, - "code": "control 'V-61439' do\n title 'Object permissions granted to PUBLIC must be restricted.'\n desc \"Permissions on objects may be granted to the user group PUBLIC.\n Because every database user is a member of the PUBLIC group, granting object\n permissions to PUBLIC gives all users in the database access to that object. In\n a secure environment, granting object permissions to PUBLIC must be restricted\n to those objects that all users are allowed to access. The policy does not\n require object permissions assigned to PUBLIC by the installation of Oracle\n Database server components be revoked.\"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000516-DB-999900'\n tag \"gid\": 'V-61439'\n tag \"rid\": 'SV-75929r3_rule'\n tag \"stig_id\": 'O121-BP-022600'\n tag \"fix_id\": 'F-67355r2_fix'\n tag \"cci\": ['CCI-000366']\n tag \"nist\": ['CM-6 b', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"A default Oracle Database installation provides a set of\n predefined administrative accounts and non-administrative accounts. These are\n accounts that have special privileges required to administer areas of the\n database, such as the “CREATE ANY TABLE” or “ALTER SESSION” privilege, or\n “EXECUTE” privileges on packages owned by the SYS schema. The default\n tablespace for administrative accounts is either “SYSTEM” or “SYSAUX”.\n Non-administrative user accounts only have the minimum privileges needed to\n perform their jobs. Their default tablespace is “USERS”.\n\n To protect these accounts from unauthorized access, the installation process\n expires and locks most of these accounts, except where noted below. The\n database administrator is responsible for unlocking and resetting these\n accounts, as required.\n\n Non-Administrative Accounts - Expired and locked:\n APEX_PUBLIC_USER, DIP, FLOWS_040100*, FLOWS_FILES, MDDATA, ORACLE_OCM,\n SPATIAL_CSW_ADMIN_USR, SPATIAL_WFS_ADMIN_USR, XS$NULL\n\n Administrative Accounts - Expired and Locked:\n ANONYMOUS, CTXSTS, EXFSYS, LBACSYS, MDSYS, OLAPSYS, OEDDATA, OWBSYS,\n ORDPLUGINS, ORDSYS, OUTLN, SI_INFORMTN_SCHEMA, WK_TEST, WK_SYS, WKPROXY, WMSYS,\n XDB\n\n Administrative Accounts - Open:\n DBSNMP, MGMT_VIEW, SYS, SYSMAN, SYSTEM\n\n * Subject to change based on version installed\n\n Run the SQL query:\n\n select owner ||'.'|| table_name ||':'|| privilege from dba_tab_privs\n where grantee = 'PUBLIC';\n and owner not in\n ();\n\n (With respect to the list of special accounts that are excluded from this\n requirement, it is expected that the DBA will maintain the list to suit local\n circumstances, adding special accounts as necessary and removing any that are\n not supposed to be in use in the Oracle deployment that is under review.)\n\n If there are any records returned that are not Oracle product accounts, and are\n not documented and authorized, this is a finding.\n\n Note: This check may return false positives where other Oracle product accounts\n are not included in the exclusion list.\"\n tag \"fix\": \"Revoke any privileges granted to PUBLIC for objects that are not\n owned by Oracle product accounts.\n\n From SQL*Plus:\n\n revoke [privilege name] from [user name] on [object name];\n\n Assign permissions to custom application user roles based on job functions:\n\n From SQL*Plus:\n\n grant [privilege name] to [user role] on [object name];\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n users_with_public_access = sql.query(\"select DISTINCT owner from dba_tab_privs where grantee = 'PUBLIC';\").column('owner').uniq\n\n if users_with_public_access.empty?\n impact 0.0\n describe 'There are no oracle users with access to PUBLIC, control N/A' do\n skip 'There are no oracle users with access to PUBLIC'\n end\n else\n users_with_public_access.each do |user|\n describe \"oracle user: #{user} with access to PUBLIC\" do\n subject { user }\n it { should be_in input('users_allowed_access_to_public')}\n end\n end\n end\nend\n", + "code": " control 'V-61715' 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-61439.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61715.rb", "line": 1 }, - "id": "V-61439" + "id": "V-61715" }, { - "title": "Database job/batch queues must be reviewed regularly to detect\n unauthorized database job submissions.", - "desc": "Unauthorized users may bypass security mechanisms by submitting jobs\n to job queues managed by the database to be run under a more privileged\n security context of the database or host system. These queues must be monitored\n regularly to detect any such unauthorized job submissions.", + "title": "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.", "descriptions": { - "default": "Unauthorized users may bypass security mechanisms by submitting jobs\n to job queues managed by the database to be run under a more privileged\n security context of the database or host system. These queues must be monitored\n regularly to detect any such unauthorized job submissions." + "default": "Information 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." }, "impact": 0.5, "refs": [], "tags": { - "gtitle": "SRG-APP-000516-DB-999900", - "gid": "V-61449", - "rid": "SV-75939r3_rule", - "stig_id": "O121-BP-023100", - "fix_id": "F-67365r2_fix", + "gtitle": "SRG-APP-000098-DB-000042", + "gid": "V-61635", + "rid": "SV-76125r1_rule", + "stig_id": "O121-C2-007700", + "fix_id": "F-67547r1_fix", "cci": [ - "CCI-000366" + "CCI-000133" ], "nist": [ - "CM-6 b", + "AU-3", "Rev_4" ], "false_negatives": null, @@ -3292,35 +3392,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "The DBMS_JOB PL/SQL package has been replaced by DBMS_SCHEDULER\n in Oracle versions 10.1 and higher, though it continues to be supported for\n backward compatibility.\n\n Run this query:\n select value from v$parameter where name = 'job_queue_processes';\n\n Run this query:\n select value from all_scheduler_global_attribute\n where ATTRIBUTE_NAME = 'MAX_JOB_SLAVE_PROCESSES';\n\n To understand the relationship between these settings, review:\n https://docs.oracle.com/database/121/ADMIN/appendix_a.htm#ADMIN11002\n\n Review documented and implemented procedures for monitoring the Oracle DBMS\n job/batch queues for unauthorized submissions. If procedures for job queue\n review are not defined, documented or evidence of implementation does not\n exist, this is a finding.\n\n Job queue information is available from the DBA_JOBS view. The following\n command lists jobs submitted to the queue. DBMS_JOB does not generate a\n 'history' of previous job executions.\n\n Run this query:\n select job, next_date, next_sec, failures, broken from dba_jobs;\n\n Scheduler queue information is available from the DBA_SCHEDULER_JOBS view. The\n following command lists jobs submitted to the queue.\n\n Run this query:\n select owner, job_name, state, job_class, job_type, job_action\n from dba_scheduler_jobs;", - "fix": "Develop, document and implement procedures to monitor the\n database job queues for unauthorized job submissions.\n\n Develop, document and implement a formal migration plan to convert jobs using\n DBMS_JOB to use DBMS_SCHEDULER instead for Oracle versions 10.1 and higher.\n (This does not apply to DBMS_JOB jobs generated by Oracle itself, such as those\n for refreshing materialized views.)\n\n Set the value of the job_queue_processes parameter to a low value to restrict\n concurrent DBMS_JOB executions.\n\n Use auditing to capture use of the DBMS_JOB package in the audit trail. Review\n the audit trail for unauthorized use of the DBMS_JOB package." + "check": "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" }, - "code": "control 'V-61449' do\n title \"Database job/batch queues must be reviewed regularly to detect\n unauthorized database job submissions.\"\n desc \"Unauthorized users may bypass security mechanisms by submitting jobs\n to job queues managed by the database to be run under a more privileged\n security context of the database or host system. These queues must be monitored\n regularly to detect any such unauthorized job submissions.\"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000516-DB-999900'\n tag \"gid\": 'V-61449'\n tag \"rid\": 'SV-75939r3_rule'\n tag \"stig_id\": 'O121-BP-023100'\n tag \"fix_id\": 'F-67365r2_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\": \"The DBMS_JOB PL/SQL package has been replaced by DBMS_SCHEDULER\n in Oracle versions 10.1 and higher, though it continues to be supported for\n backward compatibility.\n\n Run this query:\n select value from v$parameter where name = 'job_queue_processes';\n\n Run this query:\n select value from all_scheduler_global_attribute\n where ATTRIBUTE_NAME = 'MAX_JOB_SLAVE_PROCESSES';\n\n To understand the relationship between these settings, review:\n https://docs.oracle.com/database/121/ADMIN/appendix_a.htm#ADMIN11002\n\n Review documented and implemented procedures for monitoring the Oracle DBMS\n job/batch queues for unauthorized submissions. If procedures for job queue\n review are not defined, documented or evidence of implementation does not\n exist, this is a finding.\n\n Job queue information is available from the DBA_JOBS view. The following\n command lists jobs submitted to the queue. DBMS_JOB does not generate a\n 'history' of previous job executions.\n\n Run this query:\n select job, next_date, next_sec, failures, broken from dba_jobs;\n\n Scheduler queue information is available from the DBA_SCHEDULER_JOBS view. The\n following command lists jobs submitted to the queue.\n\n Run this query:\n select owner, job_name, state, job_class, job_type, job_action\n from dba_scheduler_jobs;\"\n tag \"fix\": \"Develop, document and implement procedures to monitor the\n database job queues for unauthorized job submissions.\n\n Develop, document and implement a formal migration plan to convert jobs using\n DBMS_JOB to use DBMS_SCHEDULER instead for Oracle versions 10.1 and higher.\n (This does not apply to DBMS_JOB jobs generated by Oracle itself, such as those\n for refreshing materialized views.)\n\n Set the value of the job_queue_processes parameter to a low value to restrict\n concurrent DBMS_JOB executions.\n\n Use auditing to capture use of the DBMS_JOB package in the audit trail. Review\n the audit trail for unauthorized use of the DBMS_JOB package.\"\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_jobs = sql.query(\"select owner, job_name, state, job_class, job_type, job_action\n from dba_scheduler_jobs;\").column('job_name')\n\n describe \"You must manually review the database jobs to detect unauthorized database job submissions. The jobs to review are: #{database_jobs}\" do\n skip \"You must manually review the database jobs to detect unauthorized database job submissions. The jobs to review are: #{database_jobs}\"\n end\nend\n", + "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", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61449.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61635.rb", "line": 1 }, - "id": "V-61449" + "id": "V-61635" }, { - "title": "The DBMS must enforce password maximum lifetime restrictions.", - "desc": "Password maximum lifetime is the maximum period of time, (typically in\n days) a user's password may be in effect before the user is forced to change it.\n\n Passwords need to be changed at specific policy-based intervals as per\n policy. Any password, no matter how complex, can eventually be cracked.\n\n One method of minimizing this risk is to use complex passwords and\n periodically change them. If the application does not limit the lifetime of\n passwords and force users to change their passwords, there is the risk that the\n system and/or application passwords could be compromised.\n\n The “PASSWORD_LIFE_TIME” parameter defines the number of days a password\n remains valid. This can, but must not be, set to “UNLIMITED”. Further, the\n “PASSWORD_GRACE_TIME” parameter, if set to “UNLIMITED”, can nullify the\n “PASSWORD_LIFE_TIME”. “PASSWORD_GRACE_TIME” must be set to “0” days (or another\n small integer).\n\n Note: 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. With respect to Oracle, this requirement applies to cases\n where it is necessary to have accounts directly managed by Oracle.", + "title": "All use of privileged accounts must be audited.", + "desc": "This is intended to limit exposure, by making it possible to trace any\n unauthorized access, by a privileged user account or role that has permissions\n on security functions or security-relevant information, to other data or\n functionality.", "descriptions": { - "default": "Password maximum lifetime is the maximum period of time, (typically in\n days) a user's password may be in effect before the user is forced to change it.\n\n Passwords need to be changed at specific policy-based intervals as per\n policy. Any password, no matter how complex, can eventually be cracked.\n\n One method of minimizing this risk is to use complex passwords and\n periodically change them. If the application does not limit the lifetime of\n passwords and force users to change their passwords, there is the risk that the\n system and/or application passwords could be compromised.\n\n The “PASSWORD_LIFE_TIME” parameter defines the number of days a password\n remains valid. This can, but must not be, set to “UNLIMITED”. Further, the\n “PASSWORD_GRACE_TIME” parameter, if set to “UNLIMITED”, can nullify the\n “PASSWORD_LIFE_TIME”. “PASSWORD_GRACE_TIME” must be set to “0” days (or another\n small integer).\n\n Note: 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. With respect to Oracle, this requirement applies to cases\n where it is necessary to have accounts directly managed by Oracle." + "default": "This is intended to limit exposure, by making it possible to trace any\n unauthorized access, by a privileged user account or role that has permissions\n on security functions or security-relevant information, to other data or\n functionality." }, "impact": 0.5, "refs": [], "tags": { - "gtitle": "SRG-APP-000174-DB-000080", - "gid": "V-61739", - "rid": "SV-76229r3_rule", - "stig_id": "O121-C2-015200", - "fix_id": "F-67655r5_fix", + "gtitle": "SRG-APP-000063-DB-000018", + "gid": "V-61595", + "rid": "SV-76085r2_rule", + "stig_id": "O121-C2-004200", + "fix_id": "F-67511r1_fix", "cci": [ - "CCI-000199" + "CCI-000366" ], "nist": [ - "IA-5 (1) (d)", + "CM-6 b", "Rev_4" ], "false_negatives": null, @@ -3333,35 +3433,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "If all user accounts are authenticated by the OS or an\n enterprise-level authentication/access mechanism, and not by Oracle, this is\n not a finding.\n\n Review DBMS settings to determine if passwords must be changed periodically. If\n not, this is a finding:\n\n SELECT p1.profile,\n CASE p1.limit WHEN 'UNLIMITED' THEN 'UNLIMITED' ELSE\n CASE p2.limit WHEN 'UNLIMITED' THEN 'UNLIMITED' ELSE\n CASE p3.limit WHEN 'UNLIMITED' THEN 'UNLIMITED' ELSE\n CASE p4.limit WHEN 'UNLIMITED' THEN 'UNLIMITED' ELSE\n TO_CHAR(DECODE(p1.limit, 'DEFAULT', p3.limit, p1.limit) + DECODE(p2.limit,\n 'DEFAULT', p4.limit, p2.limit))\n END\n END\n END\n END effective_life_time\n FROM dba_profiles p1, dba_profiles p2, dba_profiles p3, dba_profiles p4\n WHERE p1.profile=p2.profile\n AND p3.profile='DEFAULT'\n AND p4.profile='DEFAULT'\n AND p1.resource_name='PASSWORD_LIFE_TIME'\n AND p2.resource_name='PASSWORD_GRACE_TIME'\n AND p3.resource_name='PASSWORD_LIFE_TIME' -- from DEFAULT profile\n AND p4.resource_name='PASSWORD_GRACE_TIME' -- from DEFAULT profile\n order by 1;\n\n If the “effective_life_time” is greater than “60” for any profile applied to\n user accounts, and the need for this has not been documented and approved by\n the ISSO, this is a finding.\n\n If the value is greater than 35 for any profile applied to user accounts, and\n the DBMS is configured to use Password Lifetime to disable inactive accounts,\n this is a finding.", - "fix": "For user accounts managed by Oracle: Modify DBMS settings to\n force users to periodically change their passwords. For example, using PPPPPP\n to stand for a profile name:\n ALTER PROFILE PPPPPP LIMIT PASSWORD_LIFE_TIME 35 PASSWORD_GRACE_TIME 0;\n Do this for each profile applied to user accounts.\n\n (Note: Although the DoD requirement is for a password change every 60 days,\n using a value of “35” facilitates the use of “PASSWORD_LIFE_TIME” as a means of\n locking accounts inactive for 35 days. But if “35” is not a practical or\n acceptable limit for password lifetime, set it to the standard DoD value of\n “60”.)\n\n Where a password lifetime longer than “60” is needed, document the reasons and\n obtain ISSO approval." + "check": "Review auditing configuration.\n\n If it is possible for a privileged user/role to access non-security functions\n or information without having the action recorded in the audit log, this is a\n finding.\n\n To obtain a list of unified auditing policies that have been defined, run the\n query:\n SELECT unique policy_name from AUDIT_UNIFIED_POLICIES;\n\n To obtain a list of unified auditing policies that have been enabled and the\n users for which it has been enabled, run the query:\n SELECT unique policy_name, user_name from AUDIT_UNIFIED_ENABLED_POLICIES;\n\n Unless otherwise required, verify that user_name is set to 'ALL USERS' to\n insure that the activity of administrative users is being logged.", + "fix": "Configure DBMS auditing so that all use of privileged accounts is\n recorded in the audit log." }, - "code": "control 'V-61739' do\n title 'The DBMS must enforce password maximum lifetime restrictions.'\n desc \"Password maximum lifetime is the maximum period of time, (typically in\n days) a user's password may be in effect before the user is forced to change it.\n\n Passwords need to be changed at specific policy-based intervals as per\n policy. Any password, no matter how complex, can eventually be cracked.\n\n One method of minimizing this risk is to use complex passwords and\n periodically change them. If the application does not limit the lifetime of\n passwords and force users to change their passwords, there is the risk that the\n system and/or application passwords could be compromised.\n\n The “PASSWORD_LIFE_TIME” parameter defines the number of days a password\n remains valid. This can, but must not be, set to “UNLIMITED”. Further, the\n “PASSWORD_GRACE_TIME” parameter, if set to “UNLIMITED”, can nullify the\n “PASSWORD_LIFE_TIME”. “PASSWORD_GRACE_TIME” must be set to “0” days (or another\n small integer).\n\n Note: 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. With respect to Oracle, this requirement applies to cases\n where it is necessary to have accounts directly managed by Oracle.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000174-DB-000080'\n tag \"gid\": 'V-61739'\n tag \"rid\": 'SV-76229r3_rule'\n tag \"stig_id\": 'O121-C2-015200'\n tag \"fix_id\": 'F-67655r5_fix'\n tag \"cci\": ['CCI-000199']\n tag \"nist\": ['IA-5 (1) (d)', '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 Review DBMS settings to determine if passwords must be changed periodically. If\n not, this is a finding:\n\n SELECT p1.profile,\n CASE p1.limit WHEN 'UNLIMITED' THEN 'UNLIMITED' ELSE\n CASE p2.limit WHEN 'UNLIMITED' THEN 'UNLIMITED' ELSE\n CASE p3.limit WHEN 'UNLIMITED' THEN 'UNLIMITED' ELSE\n CASE p4.limit WHEN 'UNLIMITED' THEN 'UNLIMITED' ELSE\n TO_CHAR(DECODE(p1.limit, 'DEFAULT', p3.limit, p1.limit) + DECODE(p2.limit,\n 'DEFAULT', p4.limit, p2.limit))\n END\n END\n END\n END effective_life_time\n FROM dba_profiles p1, dba_profiles p2, dba_profiles p3, dba_profiles p4\n WHERE p1.profile=p2.profile\n AND p3.profile='DEFAULT'\n AND p4.profile='DEFAULT'\n AND p1.resource_name='PASSWORD_LIFE_TIME'\n AND p2.resource_name='PASSWORD_GRACE_TIME'\n AND p3.resource_name='PASSWORD_LIFE_TIME' -- from DEFAULT profile\n AND p4.resource_name='PASSWORD_GRACE_TIME' -- from DEFAULT profile\n order by 1;\n\n If the “effective_life_time” is greater than “60” for any profile applied to\n user accounts, and the need for this has not been documented and approved by\n the ISSO, this is a finding.\n\n If the value is greater than 35 for any profile applied to user accounts, and\n the DBMS is configured to use Password Lifetime to disable inactive accounts,\n this is a finding.\"\n tag \"fix\": \"For user accounts managed by Oracle: Modify DBMS settings to\n force users to periodically change their passwords. For example, using PPPPPP\n to stand for a profile name:\n ALTER PROFILE PPPPPP LIMIT PASSWORD_LIFE_TIME 35 PASSWORD_GRACE_TIME 0;\n Do this for each profile applied to user accounts.\n\n (Note: Although the DoD requirement is for a password change every 60 days,\n using a value of “35” facilitates the use of “PASSWORD_LIFE_TIME” as a means of\n locking accounts inactive for 35 days. But if “35” is not a practical or\n acceptable limit for password lifetime, set it to the standard DoD value of\n “60”.)\n\n Where a password lifetime longer than “60” is needed, document the reasons and\n obtain ISSO approval.\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n get_effective_life_time = sql.query(\"SELECT p1.profile,\n CASE p1.limit WHEN 'UNLIMITED' THEN 'UNLIMITED' ELSE\n CASE p2.limit WHEN 'UNLIMITED' THEN 'UNLIMITED' ELSE\n CASE p3.limit WHEN 'UNLIMITED' THEN 'UNLIMITED' ELSE\n CASE p4.limit WHEN 'UNLIMITED' THEN 'UNLIMITED' ELSE\n TO_CHAR(DECODE(p1.limit, 'DEFAULT', p3.limit, p1.limit) + DECODE(p2.limit,\n 'DEFAULT', p4.limit, p2.limit))\n END\n END\n END\n END effective_life_time\n FROM dba_profiles p1, dba_profiles p2, dba_profiles p3, dba_profiles p4\n WHERE p1.profile=p2.profile\n AND p3.profile='DEFAULT'\n AND p4.profile='DEFAULT'\n AND p1.resource_name='PASSWORD_LIFE_TIME'\n AND p2.resource_name='PASSWORD_GRACE_TIME'\n AND p3.resource_name='PASSWORD_LIFE_TIME' -- from DEFAULT profile\n AND p4.resource_name='PASSWORD_GRACE_TIME' -- from DEFAULT profile\n order by 1;\").column('effective_life_time')\n\n get_effective_life_time.each do |effective_life_time|\n\n describe 'The oracle database account effective life time limit' do\n subject { effective_life_time }\n it { should cmp >= 60 }\n end\n end\n describe get_effective_life_time do\n it { should_not be_empty }\n end\nend\n", + "code": "control 'V-61595' do\n title 'All use of privileged accounts must be audited.'\n desc \"This is intended to limit exposure, by making it possible to trace any\n unauthorized access, by a privileged user account or role that has permissions\n on security functions or security-relevant information, to other data or\n functionality.\"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000063-DB-000018'\n tag \"gid\": 'V-61595'\n tag \"rid\": 'SV-76085r2_rule'\n tag \"stig_id\": 'O121-C2-004200'\n tag \"fix_id\": 'F-67511r1_fix'\n tag \"cci\": ['CCI-000366']\n tag \"nist\": ['CM-6 b', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Review auditing configuration.\n\n If it is possible for a privileged user/role to access non-security functions\n or information without having the action recorded in the audit log, this is a\n finding.\n\n To obtain a list of unified auditing policies that have been defined, run the\n query:\n SELECT unique policy_name from AUDIT_UNIFIED_POLICIES;\n\n To obtain a list of unified auditing policies that have been enabled and the\n users for which it has been enabled, run the query:\n SELECT unique policy_name, user_name from AUDIT_UNIFIED_ENABLED_POLICIES;\n\n Unless otherwise required, verify that user_name is set to 'ALL USERS' to\n insure that the activity of administrative users is being logged.\"\n tag \"fix\": \"Configure DBMS auditing so that all use of privileged accounts is\n recorded in the audit log.\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n unified_auditing_policies_defined = sql.query('SELECT unique policy_name from AUDIT_UNIFIED_POLICIES;').column('policy_name')\n\n describe 'The list of unified auditing policies defined' do\n subject { unified_auditing_policies_defined }\n it { should_not be_empty }\n end\n\n users_being_audited = sql.query('SELECT unique user_name from AUDIT_UNIFIED_ENABLED_POLICIES;').column('user_name')\n\n describe 'The list of users being audited' do\n subject { users_being_audited }\n it { should include 'ALL USERS' }\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61739.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61595.rb", "line": 1 }, - "id": "V-61739" + "id": "V-61595" }, { - "title": "The DBMS must provide a mechanism to automatically terminate accounts\n designated as temporary or emergency accounts after an organization-defined\n time period.", - "desc": "Temporary application accounts could ostensibly be used in the event\n of a vendor support visit where a support representative requires a temporary\n unique account in order to perform diagnostic testing or conduct some other\n support related activity. When these types of accounts are created, there is a\n risk that the temporary account may remain in place and active after the\n support representative has left.\n\n To address this, in the event temporary application accounts are required,\n the application must ensure accounts designated as temporary in nature shall\n automatically terminate these accounts after an organization-defined time\n period. Such a process and capability greatly reduces the risk that accounts\n will be misused, hijacked, or data compromised.\n\n Note that user authentication and account management should be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP. This requirement applies to cases where it is necessary to\n have accounts directly managed by Oracle.\n\n Temporary database accounts must be automatically terminated after an\n organization-defined time period in order to mitigate the risk of the account\n being used beyond its original purpose or timeframe.", + "title": "Remote database or other external access must use fully-qualified\n names.", + "desc": "The Oracle GLOBAL_NAMES parameter is used to set the requirement for\n database link names to be the same name as the remote database whose connection\n they define. By using the same name for both, ambiguity is avoided and\n unauthorized or unintended connections to remote databases are less likely.", "descriptions": { - "default": "Temporary application accounts could ostensibly be used in the event\n of a vendor support visit where a support representative requires a temporary\n unique account in order to perform diagnostic testing or conduct some other\n support related activity. When these types of accounts are created, there is a\n risk that the temporary account may remain in place and active after the\n support representative has left.\n\n To address this, in the event temporary application accounts are required,\n the application must ensure accounts designated as temporary in nature shall\n automatically terminate these accounts after an organization-defined time\n period. Such a process and capability greatly reduces the risk that accounts\n will be misused, hijacked, or data compromised.\n\n Note that user authentication and account management should be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP. This requirement applies to cases where it is necessary to\n have accounts directly managed by Oracle.\n\n Temporary database accounts must be automatically terminated after an\n organization-defined time period in order to mitigate the risk of the account\n being used beyond its original purpose or timeframe." + "default": "The Oracle GLOBAL_NAMES parameter is used to set the requirement for\n database link names to be the same name as the remote database whose connection\n they define. By using the same name for both, ambiguity is avoided and\n unauthorized or unintended connections to remote databases are less likely." }, "impact": 0.5, "refs": [], "tags": { - "gtitle": "SRG-APP-000024-DB-000003", - "gid": "V-61561", - "rid": "SV-76051r3_rule", - "stig_id": "O121-C2-002000", - "fix_id": "F-67477r1_fix", + "gtitle": "SRG-APP-000516-DB-999900", + "gid": "V-61529", + "rid": "SV-76019r1_rule", + "stig_id": "O121-BP-026300", + "fix_id": "F-67445r1_fix", "cci": [ - "CCI-000016" + "CCI-000366" ], "nist": [ - "AC-2 (2)", + "CM-6 b", "Rev_4" ], "false_negatives": null, @@ -3374,35 +3474,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "If the organization has a policy, consistently enforced,\n forbidding the creation of emergency or temporary accounts, this is not a\n finding.\n\n If all user accounts are authenticated by the OS or an enterprise-level\n authentication/access mechanism, and not by Oracle, this is not a finding.\n\n Check DBMS settings, OS settings, and/or enterprise-level authentication/access\n mechanisms settings to determine if the site utilizes a mechanism whereby\n temporary or emergency accounts can be terminated after an organization-defined\n time period. If not, this is a finding.\n\n Check the profiles to see what the password_life_time is set to in the table\n dba_profiles. The password_life_time is a value stored in the LIMIT column, and\n identified by the value PASSWORD_LIFE_TIME in the RESOURCE_NAME column.\n\n SQL>select\n profile,\n resource_name,\n resource_type,\n limit\n from dba_profiles\n where upper(resource_name) like 'PASSWORD_LIFE_TIME';\n\n Verify that the user in question is assigned to a profile with the\n PASSWORD_LIFE_TIME set to the amount of time the user is expected to be using\n the password. If not, this is a finding.", - "fix": "If using database mechanisms to satisfy this requirement, use a\n profile with a distinctive name (for example, TEMPORARY_USERS), so that\n temporary users can be easily identified. Whenever a temporary user account is\n created, assign it to this profile.\n\n Create a job to lock accounts under this profile that are more than n days old,\n where n is the organization-defined time period." + "check": "From SQL*Plus:\n\n select value from v$parameter where name = 'global_names';\n\n If the value returned is FALSE, this is a finding.", + "fix": "From SQL*Plus:\n\n alter system set global_names = TRUE scope = spfile;\n\n Note: This parameter, if changed, will affect all currently defined Oracle\n database links.\n\n The above SQL*Plus command will set the parameter to take effect at next system\n startup." }, - "code": "control 'V-61561' do\n title \"The DBMS must provide a mechanism to automatically terminate accounts\n designated as temporary or emergency accounts after an organization-defined\n time period.\"\n desc \"Temporary application accounts could ostensibly be used in the event\n of a vendor support visit where a support representative requires a temporary\n unique account in order to perform diagnostic testing or conduct some other\n support related activity. When these types of accounts are created, there is a\n risk that the temporary account may remain in place and active after the\n support representative has left.\n\n To address this, in the event temporary application accounts are required,\n the application must ensure accounts designated as temporary in nature shall\n automatically terminate these accounts after an organization-defined time\n period. Such a process and capability greatly reduces the risk that accounts\n will be misused, hijacked, or data compromised.\n\n Note that user authentication and account management should be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP. This requirement applies to cases where it is necessary to\n have accounts directly managed by Oracle.\n\n Temporary database accounts must be automatically terminated after an\n organization-defined time period in order to mitigate the risk of the account\n being used beyond its original purpose or timeframe.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000024-DB-000003'\n tag \"gid\": 'V-61561'\n tag \"rid\": 'SV-76051r3_rule'\n tag \"stig_id\": 'O121-C2-002000'\n tag \"fix_id\": 'F-67477r1_fix'\n tag \"cci\": ['CCI-000016']\n tag \"nist\": ['AC-2 (2)', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"If the organization has a policy, consistently enforced,\n forbidding the creation of emergency or temporary accounts, this is not a\n finding.\n\n If all user accounts are authenticated by the OS or an enterprise-level\n authentication/access mechanism, and not by Oracle, this is not a finding.\n\n Check DBMS settings, OS settings, and/or enterprise-level authentication/access\n mechanisms settings to determine if the site utilizes a mechanism whereby\n temporary or emergency accounts can be terminated after an organization-defined\n time period. If not, this is a finding.\n\n Check the profiles to see what the password_life_time is set to in the table\n dba_profiles. The password_life_time is a value stored in the LIMIT column, and\n identified by the value PASSWORD_LIFE_TIME in the RESOURCE_NAME column.\n\n SQL>select\n profile,\n resource_name,\n resource_type,\n limit\n from dba_profiles\n where upper(resource_name) like 'PASSWORD_LIFE_TIME';\n\n Verify that the user in question is assigned to a profile with the\n PASSWORD_LIFE_TIME set to the amount of time the user is expected to be using\n the password. If not, this is a finding.\"\n tag \"fix\": \"If using database mechanisms to satisfy this requirement, use a\n profile with a distinctive name (for example, TEMPORARY_USERS), so that\n temporary users can be easily identified. Whenever a temporary user account is\n created, assign it to this profile.\n\n Create a job to lock accounts under this profile that are more than n days old,\n where n is the organization-defined time period.\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n query = %{\n SELECT PROFILE, RESOURCE_NAME, LIMIT FROM DBA_PROFILES WHERE PROFILE =\n '%s' AND RESOURCE_NAME = 'PASSWORD_LIFE_TIME'\n }\n\n user_profiles = sql.query('SELECT profile FROM dba_users;').column('profile').uniq\n\n if user_profiles.empty?\n describe 'There are no oracle user profiles, therefore this control is N/A' do\n skip 'There are no oracle user profiles, therefore this control is N/A'\n end\n end\n\n if !user_profiles.empty?\n user_profiles.each do |profile|\n unless input('emergency_profile_list').include?(profile)\n \tdescribe \"The profile #{profile} \" do\n\t subject { profile }\n\t it \"should not be in the org-defined list of profiles for emergency or temporary account management\" do\n\t expect(subject).should_not be_in(input('emergency_profile_list')) \n\t end\n end\n\tnext\n end\n password_life_time = sql.query(format(query, profile: profile)).column('limit')\n\n describe \"The oracle database account password life time for profile: #{profile}\" do\n subject { password_life_time }\n it { should cmp <= input('password_life_time') }\n end\n end\n end\nend\n", + "code": "control 'V-61529' do\n title \"Remote database or other external access must use fully-qualified\n names.\"\n desc \"The Oracle GLOBAL_NAMES parameter is used to set the requirement for\n database link names to be the same name as the remote database whose connection\n they define. By using the same name for both, ambiguity is avoided and\n unauthorized or unintended connections to remote databases are less likely.\"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000516-DB-999900'\n tag \"gid\": 'V-61529'\n tag \"rid\": 'SV-76019r1_rule'\n tag \"stig_id\": 'O121-BP-026300'\n tag \"fix_id\": 'F-67445r1_fix'\n tag \"cci\": ['CCI-000366']\n tag \"nist\": ['CM-6 b', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"From SQL*Plus:\n\n select value from v$parameter where name = 'global_names';\n\n If the value returned is FALSE, this is a finding.\"\n tag \"fix\": \"From SQL*Plus:\n\n alter system set global_names = TRUE scope = spfile;\n\n Note: This parameter, if changed, will affect all currently defined Oracle\n database links.\n\n The above SQL*Plus command will set the parameter to take effect at next system\n startup.\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n parameter = sql.query(\"select value from v$parameter where name = 'global_names';\").column('value')\n\n describe 'The oracle database GLOBAL_NAMES parameter' do\n subject { parameter }\n it { should_not cmp 'FALSE' }\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61561.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61529.rb", "line": 1 }, - "id": "V-61561" + "id": "V-61529" }, { - "title": "Unauthorized database links must not be defined and active.", - "desc": "DBMS links provide a communication and data transfer path definition\n between two databases that may be used by malicious users to discover and\n obtain unauthorized access to remote systems. Database links between production\n and development DBMSs provide a means for developers to access production data\n not authorized for their access or to introduce untested or unauthorized\n applications to the production database. Only protected, controlled, and\n authorized downloads of any production data to use for development may be\n allowed. Only applications that have completed the configuration management\n process may be introduced by the application object owner account to the\n production system.", + "title": "The DBMS must have its auditing configured to reduce the likelihood of\n storage capacity being exceeded.", + "desc": "Applications need to be cognizant of potential audit log storage\n capacity issues. During the installation and/or configuration process,\n applications should detect and determine if adequate storage capacity has been\n allocated for audit logs.\n\n During the installation process, a notification may be provided to the\n installer indicating, based on the auditing configuration chosen and the amount\n of storage space allocated for audit logs, the amount of storage capacity\n available is not sufficient to meet storage requirements.\n\n Logging must be configured appropriately. If the logs generated outstrip\n the amount of space reserved for those logs, the system may shut down or take\n other measures to stop processing in order to protect transactions from\n continuing unlogged.", "descriptions": { - "default": "DBMS links provide a communication and data transfer path definition\n between two databases that may be used by malicious users to discover and\n obtain unauthorized access to remote systems. Database links between production\n and development DBMSs provide a means for developers to access production data\n not authorized for their access or to introduce untested or unauthorized\n applications to the production database. Only protected, controlled, and\n authorized downloads of any production data to use for development may be\n allowed. Only applications that have completed the configuration management\n process may be introduced by the application object owner account to the\n production system." + "default": "Applications need to be cognizant of potential audit log storage\n capacity issues. During the installation and/or configuration process,\n applications should detect and determine if adequate storage capacity has been\n allocated for audit logs.\n\n During the installation process, a notification may be provided to the\n installer indicating, based on the auditing configuration chosen and the amount\n of storage space allocated for audit logs, the amount of storage capacity\n available is not sufficient to meet storage requirements.\n\n Logging must be configured appropriately. If the logs generated outstrip\n the amount of space reserved for those logs, the system may shut down or take\n other measures to stop processing in order to protect transactions from\n continuing unlogged." }, - "impact": 0, + "impact": 0.5, "refs": [], "tags": { - "gtitle": "SRG-APP-000516-DB-999900", - "gid": "V-61451", - "rid": "SV-75941r1_rule", - "stig_id": "O121-BP-023200", - "fix_id": "F-67367r1_fix", + "gtitle": "SRG-APP-000071-DB-000047", + "gid": "V-61613", + "rid": "SV-76103r1_rule", + "stig_id": "O121-C2-005600", + "fix_id": "F-67529r1_fix", "cci": [ - "CCI-000366" + "CCI-001849" ], "nist": [ - "CM-6 b", + "AU-4", "Rev_4" ], "false_negatives": null, @@ -3415,39 +3515,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "From SQL*Plus:\n select db_link||': '||host from dba_db_links;\n\n If no links are returned, this check is not a finding.\n\n Review documentation for definitions of authorized database links to external\n interfaces.\n\n The documentation should include:\n\n - Any remote access to the database\n - The purpose or function of the remote connection\n - Any access to data or procedures stored externally to the local DBMS\n - Any network ports or protocols used by remote connections, whether the remote\n connection is to a production, test, or development system\n - Any security accounts used by DBMS to access remote resources or objects\n\n If any unauthorized database links are defined or the definitions do not match\n the documentation, this is a finding.\n\n Note: findings for production-development links under this check are assigned\n to the production database only.\n\n If any database links are defined between the production database and any test\n or development databases, this is a finding.\n\n If remote interface documentation does not exist or is incomplete, this is a\n finding.", - "fix": "Document all remote or external interfaces used by the DBMS to\n connect to or allow connections from remote or external sources.\n\n Include with the documentation as appropriate, any network ports or protocols,\n security accounts, and the sensitivity of any data exchanged.\n\n Do not define or configure database links between production databases and test\n or development databases.\n\n Note: Oracle Database Advanced Replication is deprecated in Oracle Database\n 12c. Use Oracle GoldenGate to replace all features of Advanced Replication,\n including multimaster replication, updatable materialized views, hierarchical\n materialized views, and deployment templates." + "check": "Review the DBMS settings to determine whether audit logging is\n configured to produce logs consistent with the amount of space allocated for\n logging. If auditing will generate excessive logs so that they may outgrow the\n space reserved for logging, this is a finding.\n\n If file-based auditing is in use, check that sufficient space is available to\n support the file(s). If not, this is a finding\n\n If standard, table-based auditing is used: The audit logs are written to a\n table called AUD$, and if a Virtual Private Database is deployed, we also\n create a table called FGA_LOG$. First check the current location of the audit\n trail tables.\n\n CONN / AS SYSDBA\n\n SELECT table_name, tablespace_name\n FROM dba_tables\n WHERE table_name IN ('AUD$', 'FGA_LOG$')\n ORDER BY table_name;\n\n TABLE_NAME TABLESPACE_NAME\n -------------- ------------------\n AUD$ SYSTEM\n FGA_LOG$ SYSTEM\n\n If the tablespace_name is SYSTEM, the table needs to be relocated to its own\n tablespace. Ensure that adequate space is allocated to that tablespace.\n\n If Unified Auditing is used:\n Audit logs are written to tables in the AUDSYS schema. The default tablespace\n for AUDSYS is USERS. A separate tablespace should be created to contain audit\n data. Ensure that adequate space is allocated to that tablespace.", + "fix": "Allocate sufficient disk space for file-based audit.\n\n Ensure that audit tables are in their own tablespaces and that the tablespaces\n have enough room for the volume of log data that will be produced." }, - "code": "control 'V-61451' do\n title 'Unauthorized database links must not be defined and active.'\n desc \"DBMS links provide a communication and data transfer path definition\n between two databases that may be used by malicious users to discover and\n obtain unauthorized access to remote systems. Database links between production\n and development DBMSs provide a means for developers to access production data\n not authorized for their access or to introduce untested or unauthorized\n applications to the production database. Only protected, controlled, and\n authorized downloads of any production data to use for development may be\n allowed. Only applications that have completed the configuration management\n process may be introduced by the application object owner account to the\n production system.\"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000516-DB-999900'\n tag \"gid\": 'V-61451'\n tag \"rid\": 'SV-75941r1_rule'\n tag \"stig_id\": 'O121-BP-023200'\n tag \"fix_id\": 'F-67367r1_fix'\n tag \"cci\": ['CCI-000366']\n tag \"nist\": ['CM-6 b', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"From SQL*Plus:\n select db_link||': '||host from dba_db_links;\n\n If no links are returned, this check is not a finding.\n\n Review documentation for definitions of authorized database links to external\n interfaces.\n\n The documentation should include:\n\n - Any remote access to the database\n - The purpose or function of the remote connection\n - Any access to data or procedures stored externally to the local DBMS\n - Any network ports or protocols used by remote connections, whether the remote\n connection is to a production, test, or development system\n - Any security accounts used by DBMS to access remote resources or objects\n\n If any unauthorized database links are defined or the definitions do not match\n the documentation, this is a finding.\n\n Note: findings for production-development links under this check are assigned\n to the production database only.\n\n If any database links are defined between the production database and any test\n or development databases, this is a finding.\n\n If remote interface documentation does not exist or is incomplete, this is a\n finding.\"\n tag \"fix\": \"Document all remote or external interfaces used by the DBMS to\n connect to or allow connections from remote or external sources.\n\n Include with the documentation as appropriate, any network ports or protocols,\n security accounts, and the sensitivity of any data exchanged.\n\n Do not define or configure database links between production databases and test\n or development databases.\n\n Note: Oracle Database Advanced Replication is deprecated in Oracle Database\n 12c. Use Oracle GoldenGate to replace all features of Advanced Replication,\n including multimaster replication, updatable materialized views, hierarchical\n materialized views, and deployment templates.\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n db_links = sql.query('SELECT DB_LINK FROM DBA_DB_LINKS;').column('db_link').uniq\n if db_links.empty?\n impact 0.0\n describe 'There are no oracle database links defined, control N/A' do\n skip 'There are no oracle database links defined, control N/A'\n end\n else\n db_links.each do |link|\n describe \"The defined oracle database link: #{link}\" do\n subject { link }\n it { should be_in input('allowed_db_links') }\n end\n end\n end\nend\n", + "code": "control 'V-61613' do\n title \"The DBMS must have its auditing configured to reduce the likelihood of\n storage capacity being exceeded.\"\n desc \"Applications need to be cognizant of potential audit log storage\n capacity issues. During the installation and/or configuration process,\n applications should detect and determine if adequate storage capacity has been\n allocated for audit logs.\n\n During the installation process, a notification may be provided to the\n installer indicating, based on the auditing configuration chosen and the amount\n of storage space allocated for audit logs, the amount of storage capacity\n available is not sufficient to meet storage requirements.\n\n Logging must be configured appropriately. If the logs generated outstrip\n the amount of space reserved for those logs, the system may shut down or take\n other measures to stop processing in order to protect transactions from\n continuing unlogged.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000071-DB-000047'\n tag \"gid\": 'V-61613'\n tag \"rid\": 'SV-76103r1_rule'\n tag \"stig_id\": 'O121-C2-005600'\n tag \"fix_id\": 'F-67529r1_fix'\n tag \"cci\": ['CCI-001849']\n tag \"nist\": ['AU-4', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Review the DBMS settings to determine whether audit logging is\n configured to produce logs consistent with the amount of space allocated for\n logging. If auditing will generate excessive logs so that they may outgrow the\n space reserved for logging, this is a finding.\n\n If file-based auditing is in use, check that sufficient space is available to\n support the file(s). If not, this is a finding\n\n If standard, table-based auditing is used: The audit logs are written to a\n table called AUD$, and if a Virtual Private Database is deployed, we also\n create a table called FGA_LOG$. First check the current location of the audit\n trail tables.\n\n CONN / AS SYSDBA\n\n SELECT table_name, tablespace_name\n FROM dba_tables\n WHERE table_name IN ('AUD$', 'FGA_LOG$')\n ORDER BY table_name;\n\n TABLE_NAME TABLESPACE_NAME\n -------------- ------------------\n AUD$ SYSTEM\n FGA_LOG$ SYSTEM\n\n If the tablespace_name is SYSTEM, the table needs to be relocated to its own\n tablespace. Ensure that adequate space is allocated to that tablespace.\n\n If Unified Auditing is used:\n Audit logs are written to tables in the AUDSYS schema. The default tablespace\n for AUDSYS is USERS. A separate tablespace should be created to contain audit\n data. Ensure that adequate space is allocated to that tablespace.\"\n tag \"fix\": \"Allocate sufficient disk space for file-based audit.\n\n Ensure that audit tables are in their own tablespaces and that the tablespaces\n have enough room for the volume of log data that will be produced.\"\n describe 'A manual review is required to ensure the DBMS has its auditing configured to reduce the likelihood of\n storage capacity being exceeded' do\n skip 'A manual review is required to ensure the DBMS has its auditing configured to reduce the likelihood of\n storage capacity being exceeded'\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61451.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61613.rb", "line": 1 }, - "id": "V-61451" + "id": "V-61613" }, { - "title": "Network client connections must be restricted to supported versions.", - "desc": "Unsupported Oracle network client installations may introduce\n vulnerabilities to the database. Restriction to use of supported versions helps\n to protect the database and helps to enforce newer, more robust security\n controls.", + "title": "Default demonstration and sample databases, database objects, and\n applications must be removed.", + "desc": "Information systems are capable of providing a wide variety of\n functions and services. Some of the functions and services, provided by\n default, may not be necessary to support essential organizational operations\n (e.g., key missions, functions).\n\n It is detrimental for applications to provide, or install by default,\n functionality exceeding requirements or mission objectives. Examples include,\n but are not limited to, installing advertising software, demonstrations, or\n browser plugins not related to requirements or providing a wide array of\n functionality not required for the mission.\n\n Applications must adhere to the principles of least functionality by\n providing only essential capabilities.\n\n Demonstration and sample database objects and applications present publicly\n known attack points for malicious users. These demonstration and sample objects\n are meant to provide simple examples of coding specific functions and are not\n developed to prevent vulnerabilities from being introduced to the DBMS and host\n system.", "descriptions": { - "default": "Unsupported Oracle network client installations may introduce\n vulnerabilities to the database. Restriction to use of supported versions helps\n to protect the database and helps to enforce newer, more robust security\n controls." + "default": "Information systems are capable of providing a wide variety of\n functions and services. Some of the functions and services, provided by\n default, may not be necessary to support essential organizational operations\n (e.g., key missions, functions).\n\n It is detrimental for applications to provide, or install by default,\n functionality exceeding requirements or mission objectives. Examples include,\n but are not limited to, installing advertising software, demonstrations, or\n browser plugins not related to requirements or providing a wide array of\n functionality not required for the mission.\n\n Applications must adhere to the principles of least functionality by\n providing only essential capabilities.\n\n Demonstration and sample database objects and applications present publicly\n known attack points for malicious users. These demonstration and sample objects\n are meant to provide simple examples of coding specific functions and are not\n developed to prevent vulnerabilities from being introduced to the DBMS and host\n system." }, - "impact": 0, - "refs": [ - { - "ref": [] - } - ], + "impact": 0.5, + "refs": [], "tags": { - "gtitle": "SRG-APP-000516-DB-999900", - "gid": "V-61535", - "rid": "SV-76025r2_rule", - "stig_id": "O121-BP-026600", - "fix_id": "F-67451r1_fix", + "gtitle": "SRG-APP-000141-DB-000090", + "gid": "V-61677", + "rid": "SV-76167r3_rule", + "stig_id": "O121-C2-011500", + "fix_id": "F-67591r1_fix", "cci": [ - "CCI-000366" + "CCI-000381" ], "nist": [ - "CM-6 b", + "CM-7 a", "Rev_4" ], "false_negatives": null, @@ -3460,39 +3556,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Note: The SQLNET.ALLOWED_LOGON_VERSION parameter is deprecated\n in Oracle Database 12c. This parameter has been replaced with two new Oracle\n Net Services parameters:\n\n SQLNET.ALLOWED_LOGON_VERSION_SERVER\n SQLNET.ALLOWED_LOGON_VERSION_CLIENT\n\n View the SQLNET.ORA file in the ORACLE_HOME/network/admin directory or the\n directory specified in the TNS_ADMIN environment variable. (Please see the\n supplemental file \"Non-default sqlnet.ora configurations.pdf\" for how to find\n multiple and/or differently located sqlnet.ora files.)\n\n Locate the following entries:\n\n SQLNET.ALLOWED_LOGON_VERSION_SERVER = 11\n SQLNET.ALLOWED_LOGON_VERSION_CLIENT=11\n\n If the parameters do not exist, this is a finding.\n\n If the parameters are not set to a value of 11 or higher, this is a finding.\n\n Note: Attempting to connect with a client version lower than specified in these\n parameters may result in a misleading error:\n ORA-01017: invalid username/password: logon denied", - "fix": "Edit the SQLNET.ORA file to add or edit the entries:\n\n SQLNET.ALLOWED_LOGON_VERSION_SERVER = 11\n SQLNET.ALLOWED_LOGON_VERSION_CLIENT=11\n\n Set the value to 11 or higher.\n Valid values for SQLNET.ALLOWED_LOGON_VERSION_SERVER are: 8,9,10,11,12 and 12a\n\n Valid values for SQLNET.ALLOWED_LOGON_VERSION_CLIENT are: 8,10,11,12 and 12a\n\n For more information on sqlnet.ora parameters refer to the following document:\n \"Database Net Services Reference\"\n http://docs.oracle.com/database/121/NETRF/sqlnet.htm#NETRF006" + "check": "If Oracle is hosted on a server that does not support\n production systems, and is designated for the deployment of samples and\n demonstrations, this is not applicable (NA).\n\n Review documentation and websites from Oracle and any other relevant vendors\n for vendor-provided demonstration or sample databases, database applications,\n schemas, objects, and files.\n\n Review the Oracle DBMS to determine if any of the demonstration and sample\n databases, schemas, database applications, or files are installed in the\n database or are included with the DBMS application. If any are present in the\n database or are included with the DBMS application, this is a finding.\n\n The Oracle Default Sample Schema User Accounts are:\n\n BI\n Owns the Business Intelligence schema included in the Oracle Sample Schemas.\n\n HR\n Manages the Human Resources schema. Schema stores information about the\n employees and the facilities of the company.\n\n OE\n Manages the Order Entry schema. Schema stores product inventories and sales of\n the company's products through various channels.\n\n PM\n Manages the Product Media schema. Schema contains descriptions and detailed\n information about each product sold by the company.\n\n IX\n Manages the Information Exchange schema. Schema manages shipping through\n business-to-business (B2B) applications database.\n\n SH\n Manages the Sales schema. Schema stores statistics to facilitate business\n decisions.\n\n SCOTT\n A demonstration account with a simple schema.\n\n Connect to Oracle as SYSDBA; run the following SQL to check for presence of\n Oracle Default Sample Schema User Accounts:\n select distinct(username) from dba_users where username in\n ('BI','HR','OE','PM','IX','SH','SCOTT');\n\n If any of the users listed above is returned it means that there are demo\n programs installed, so this is a finding.\n ", + "fix": "Remove any demonstration and sample databases, database\n applications, objects, and files from the DBMS.\n\n To remove an account and all objects owned by that account (using BI as an\n example):\n DROP USER BI CASCADE;\n\n To remove objects without removing their owner, use the appropriate DROP\n statement (DROP TABLE, DROP VIEW, etc.)." }, - "code": " control 'V-61535' do\n impact 0.0\n describe 'This control is not applicable on oracle within aws rds, as aws manages the operating system in which the oracle database is running on' do\n skip 'This control is not applicable on oracle within aws rds, as aws manages the operating system in which the oracle database is running on'\n end\n end\n", + "code": "control 'V-61677' do\n title \"Default demonstration and sample databases, database objects, and\n applications must be removed.\"\n desc \"Information systems are capable of providing a wide variety of\n functions and services. Some of the functions and services, provided by\n default, may not be necessary to support essential organizational operations\n (e.g., key missions, functions).\n\n It is detrimental for applications to provide, or install by default,\n functionality exceeding requirements or mission objectives. Examples include,\n but are not limited to, installing advertising software, demonstrations, or\n browser plugins not related to requirements or providing a wide array of\n functionality not required for the mission.\n\n Applications must adhere to the principles of least functionality by\n providing only essential capabilities.\n\n Demonstration and sample database objects and applications present publicly\n known attack points for malicious users. These demonstration and sample objects\n are meant to provide simple examples of coding specific functions and are not\n developed to prevent vulnerabilities from being introduced to the DBMS and host\n system.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000141-DB-000090'\n tag \"gid\": 'V-61677'\n tag \"rid\": 'SV-76167r3_rule'\n tag \"stig_id\": 'O121-C2-011500'\n tag \"fix_id\": 'F-67591r1_fix'\n tag \"cci\": ['CCI-000381']\n tag \"nist\": ['CM-7 a', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"If Oracle is hosted on a server that does not support\n production systems, and is designated for the deployment of samples and\n demonstrations, this is not applicable (NA).\n\n Review documentation and websites from Oracle and any other relevant vendors\n for vendor-provided demonstration or sample databases, database applications,\n schemas, objects, and files.\n\n Review the Oracle DBMS to determine if any of the demonstration and sample\n databases, schemas, database applications, or files are installed in the\n database or are included with the DBMS application. If any are present in the\n database or are included with the DBMS application, this is a finding.\n\n The Oracle Default Sample Schema User Accounts are:\n\n BI\n Owns the Business Intelligence schema included in the Oracle Sample Schemas.\n\n HR\n Manages the Human Resources schema. Schema stores information about the\n employees and the facilities of the company.\n\n OE\n Manages the Order Entry schema. Schema stores product inventories and sales of\n the company's products through various channels.\n\n PM\n Manages the Product Media schema. Schema contains descriptions and detailed\n information about each product sold by the company.\n\n IX\n Manages the Information Exchange schema. Schema manages shipping through\n business-to-business (B2B) applications database.\n\n SH\n Manages the Sales schema. Schema stores statistics to facilitate business\n decisions.\n\n SCOTT\n A demonstration account with a simple schema.\n\n Connect to Oracle as SYSDBA; run the following SQL to check for presence of\n Oracle Default Sample Schema User Accounts:\n select distinct(username) from dba_users where username in\n ('BI','HR','OE','PM','IX','SH','SCOTT');\n\n If any of the users listed above is returned it means that there are demo\n programs installed, so this is a finding.\n \"\n tag \"fix\": \"Remove any demonstration and sample databases, database\n applications, objects, and files from the DBMS.\n\n To remove an account and all objects owned by that account (using BI as an\n example):\n DROP USER BI CASCADE;\n\n To remove objects without removing their owner, use the appropriate DROP\n statement (DROP TABLE, DROP VIEW, etc.).\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n sample_schema_user_accounts = sql.query(\"select distinct(username) from dba_users where username in\n ('BI','HR','OE','PM','IX','SH','SCOTT');\").column('username')\n\n describe 'The list of oracle default sample schema user accounts' do\n subject { sample_schema_user_accounts }\n it { should be_empty }\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61535.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61677.rb", "line": 1 }, - "id": "V-61535" + "id": "V-61677" }, { - "title": "The DBMS must support organizational requirements to enforce minimum\n password length.", - "desc": "Password complexity, or strength, is a measure of the effectiveness of\n a password in resisting attempts at guessing and brute-force attacks.\n\n To meet password policy requirements, passwords need to be changed at\n specific policy-based intervals.\n\n If the information system or application allows the user to consecutively\n reuse their password when that password has exceeded its defined lifetime, the\n end result is a password that is not changed as per policy requirements.\n\n Weak passwords are a primary target for attack to gain unauthorized access\n to databases and other systems. Where username/password is used for\n identification and authentication to the database, requiring the use of strong\n passwords can help prevent simple and more sophisticated methods for guessing\n at passwords.\n\n Note that user authentication and account management must be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP. This requirement applies to cases where it is necessary to\n have accounts directly managed by Oracle.", + "title": "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": "Password complexity, or strength, is a measure of the effectiveness of\n a password in resisting attempts at guessing and brute-force attacks.\n\n To meet password policy requirements, passwords need to be changed at\n specific policy-based intervals.\n\n If the information system or application allows the user to consecutively\n reuse their password when that password has exceeded its defined lifetime, the\n end result is a password that is not changed as per policy requirements.\n\n Weak passwords are a primary target for attack to gain unauthorized access\n to databases and other systems. Where username/password is used for\n identification and authentication to the database, requiring the use of strong\n passwords can help prevent simple and more sophisticated methods for guessing\n at passwords.\n\n Note that user authentication and account management must be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP. This requirement applies to cases where it is necessary to\n have accounts directly managed by Oracle." + "default": "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.5, - "refs": [ - { - "ref": [] - } - ], + "refs": [], "tags": { - "gtitle": "SRG-APP-000164-DB-000082", - "gid": "V-61719", - "rid": "SV-76209r1_rule", - "stig_id": "O121-C2-013900", - "fix_id": "F-67635r1_fix", + "gtitle": "SRG-APP-000063-DB-000018", + "gid": "V-61597", + "rid": "SV-76087r1_rule", + "stig_id": "O121-C2-004210", + "fix_id": "F-67513r1_fix", "cci": [ - "CCI-000205" + "CCI-000366" ], "nist": [ - "IA-5 (1) (a)", + "CM-6 b", "Rev_4" ], "false_negatives": null, @@ -3505,35 +3597,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "If all user accounts are authenticated by the OS or an\n enterprise-level authentication/access mechanism, and not by Oracle, this is\n not a finding.\n\n For each profile that can be applied to accounts where authentication is under\n Oracle's control, determine the password verification function, if any, that is\n in use:\n\n SELECT * FROM SYS.DBA_PROFILES\n WHERE RESOURCE_NAME = 'PASSWORD_VERIFY_FUNCTION'\n [AND PROFILE NOT IN ()]\n ORDER BY PROFILE;\n\n Bearing in mind that a profile can inherit from another profile, and the root\n profile is called DEFAULT, determine the name of the password verification\n function effective for each profile.\n\n If, for any profile, the function name is null, this is a finding.\n\n For each password verification function, examine its source code.\n\n If it does not enforce the DoD-defined minimum length (15 unless otherwise\n specified), this is a finding.", - "fix": "If all user accounts are authenticated by the OS or an\n enterprise-level authentication/access mechanism, and not by Oracle, no fix to\n the DBMS is required.\n\n If any user accounts are managed by Oracle: Develop, test and implement a\n password verification function that enforces DoD requirements.\n\n (Oracle supplies a sample function called ORA12C_STRONG_VERIFY_FUNCTION, in the\n script file\n /RDBMS/ADMIN/utlpwdmg.sql. This can be used as the starting point\n for a customized function.)" + "check": "Review 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-61719' do\n title \"The DBMS must support organizational requirements to enforce minimum\n password length.\"\n desc \"Password complexity, or strength, is a measure of the effectiveness of\n a password in resisting attempts at guessing and brute-force attacks.\n\n To meet password policy requirements, passwords need to be changed at\n specific policy-based intervals.\n\n If the information system or application allows the user to consecutively\n reuse their password when that password has exceeded its defined lifetime, the\n end result is a password that is not changed as per policy requirements.\n\n Weak passwords are a primary target for attack to gain unauthorized access\n to databases and other systems. Where username/password is used for\n identification and authentication to the database, requiring the use of strong\n passwords can help prevent simple and more sophisticated methods for guessing\n at passwords.\n\n Note that user authentication and account management must be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP. This requirement applies to cases where it is necessary to\n have accounts directly managed by Oracle.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000164-DB-000082'\n tag \"gid\": 'V-61719'\n tag \"rid\": 'SV-76209r1_rule'\n tag \"stig_id\": 'O121-C2-013900'\n tag \"fix_id\": 'F-67635r1_fix'\n tag \"cci\": ['CCI-000205']\n tag \"nist\": ['IA-5 (1) (a)', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"If all user accounts are authenticated by the OS or an\n enterprise-level authentication/access mechanism, and not by Oracle, this is\n not a finding.\n\n For each profile that can be applied to accounts where authentication is under\n Oracle's control, determine the password verification function, if any, that is\n in use:\n\n SELECT * FROM SYS.DBA_PROFILES\n WHERE RESOURCE_NAME = 'PASSWORD_VERIFY_FUNCTION'\n [AND PROFILE NOT IN ()]\n ORDER BY PROFILE;\n\n Bearing in mind that a profile can inherit from another profile, and the root\n profile is called DEFAULT, determine the name of the password verification\n function effective for each profile.\n\n If, for any profile, the function name is null, this is a finding.\n\n For each password verification function, examine its source code.\n\n If it does not enforce the DoD-defined minimum length (15 unless otherwise\n specified), this is a finding.\"\n tag \"fix\": \"If all user accounts are authenticated by the OS or an\n enterprise-level authentication/access mechanism, and not by Oracle, no fix to\n the DBMS is required.\n\n If any user accounts are managed by Oracle: Develop, test and implement a\n password verification function that enforces DoD requirements.\n\n (Oracle supplies a sample function called ORA12C_STRONG_VERIFY_FUNCTION, in the\n script file\n /RDBMS/ADMIN/utlpwdmg.sql. This can be used as the starting point\n for a customized function.)\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n query = %{\n SELECT PROFILE, RESOURCE_NAME, LIMIT FROM DBA_PROFILES WHERE PROFILE =\n '%s' AND RESOURCE_NAME = 'PASSWORD_VERIFY_FUNCTION'\n }\n\n user_profiles = sql.query('SELECT profile FROM dba_users;').column('profile').uniq\n\n user_profiles.each do |profile|\n next if profile == \"RDSADMIN\"\n password_verify_function = sql.query(format(query, profile: profile)).column('limit')\n\n describe \"The oracle database account password verify function for profile: #{profile}\" do\n subject { password_verify_function }\n it { should_not eq ['NULL'] }\n end\n end\n if user_profiles.empty?\n describe 'There are no user profiles, therefore this control is NA' do\n skip 'There are no user profiles, therefore this control is NA'\n end\n end\nend\n", + "code": "control 'V-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-61719.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61597.rb", "line": 1 }, - "id": "V-61719" + "id": "V-61597" }, { - "title": "Recovery procedures and technical system features must exist to ensure\n recovery is done in a secure and verifiable manner.", - "desc": "Application recovery and reconstitution constitutes executing an\ninformation system contingency plan comprised of activities that restore\nessential missions and business functions.\n\n Database management systems and transaction-based processing systems are\nexamples of information systems that are transaction-based. Transaction\nrollback and transaction journaling are examples of mechanisms supporting\ntransaction recovery.\n\n A DBMS may be vulnerable to use of compromised data or other critical files\nduring recovery. Use of compromised files could introduce maliciously altered\napplication code, relaxed security settings or loss of data integrity. Where\navailable, DBMS mechanisms to ensure use of only trusted files can help protect\nthe database from this type of compromise during DBMS recovery.", + "title": "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": "Application recovery and reconstitution constitutes executing an\ninformation system contingency plan comprised of activities that restore\nessential missions and business functions.\n\n Database management systems and transaction-based processing systems are\nexamples of information systems that are transaction-based. Transaction\nrollback and transaction journaling are examples of mechanisms supporting\ntransaction recovery.\n\n A DBMS may be vulnerable to use of compromised data or other critical files\nduring recovery. Use of compromised files could introduce maliciously altered\napplication code, relaxed security settings or loss of data integrity. Where\navailable, DBMS mechanisms to ensure use of only trusted files can help protect\nthe database from this type of compromise during DBMS recovery." + "default": "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-000144-DB-000101", - "gid": "V-61689", - "rid": "SV-76179r1_rule", - "stig_id": "O121-C2-012000", - "fix_id": "F-67603r1_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-000553" + "CCI-001083" ], "nist": [ - "CP-10 (2)", + "SC-2 (1)", "Rev_4" ], "false_negatives": null, @@ -3546,35 +3638,39 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Review DBMS recovery procedures and technical system features\n to determine if mechanisms exist and are in place to specify use of trusted\n files during DBMS recovery.\n\n If recovery procedures do not exist or are not sufficient to ensure recovery is\n done in a secure and verifiable manner, this is a finding.\n\n If system features exist and are not employed or not employed sufficiently,\n this is a finding.\n\n If circumstances that can inhibit a trusted recovery are not documented and\n appropriate mitigating procedures have not been put in place, this is a finding.\n\n Review the database backup strategy with the system administrator. Consider\n using Oracle RMAN with an encrypted backup to insure the backed up files can be\n trusted not to be compromised.", - "fix": "Implement DBMS recovery procedures and employ technical system\n features to specify trusted files during DBMS recovery. Test the solution and\n review the site-specific criteria to ensure that the backup and recovery\n process uses trusted files.\n\n Ensure circumstances that can inhibit a trusted recovery are documented and\n appropriate mitigating procedures have been put in place.\n\n Oracle recommends using RMAN Backup and encrypting backup files. With\n encrypted files stored on a mount point with limited access, the integrity of\n the files can be trusted.\n\n - - - - -\n Notes on Oracle Backup and Recovery Solutions\n\n When implementing a backup and recovery strategy, have the following solutions\n available:\n\n -- Recovery Manager (RMAN)\n Recovery Manager is fully integrated with the Oracle database to perform a\n range of backup and recovery activities, including maintaining an RMAN\n repository of historical data about backups. Can access RMAN through the\n command line or through Oracle Enterprise Manager.\n\n -- User-managed backup and recovery\n In this solution, perform backup and recovery with a mixture of host operating\n system commands and SQL*Plus recovery commands. Responsible for determining all\n aspects of when and how backups and recovery are done.\n\n -- Media management\n If not wanting to use RMAN with an encrypted backup, consider configuring RMAN\n to make backups to a media manager. On most platforms, to back up to and\n restore from sequential media such as tape, must integrate a media manager with\n the Oracle database. Can use Oracle Secure Backup, which supports both database\n and file system backups to tape, as the media manager. See Oracle Secure Backup\n Administrator's Guide to learn how to set up RMAN for use specifically with\n Oracle Secure Backup.\n\n These solutions are supported by Oracle and are fully documented, but RMAN is\n the preferred solution for database backup and recovery. RMAN provides a common\n interface for backup tasks across different host operating systems and offers\n several backup techniques not available through user-managed methods.\n\n -- Incremental backups:\n An incremental backup stores only blocks changed since a previous backup.\n Thus, they provide more compact backups and faster recovery, thereby reducing\n the need to apply redo during data file media recovery. If enabling block\n change tracking, then can improve performance by avoiding full scans of every\n input data file. Can use the BACKUP INCREMENTAL command to perform incremental\n backups.\n\n -- Block media recovery:\n Can repair a data file with only a small number of corrupt data blocks without\n taking it off-line or restoring it from backup. Can use the RECOVER BLOCK\n command to perform block media recovery.\n\n -- Binary compression:\n A binary compression mechanism integrated into Oracle Database reduces the size\n of backups.\n\n -- Encrypted backups:\n RMAN uses backup encryption capabilities integrated into Oracle Database to\n store backup sets in an encrypted format. To create encrypted backups on disk,\n the database must use the Advanced Security Option. To create encrypted backups\n directly on tape, RMAN must use the Oracle Secure Backup SBT interface but does\n not require the Advanced Security Option.\n\n -- Automated database duplication:\n Easily creates a copy of the database, supporting various storage\n configurations, including direct duplication between ASM databases.\n\n -- Cross-platform data conversion:\n Whether using RMAN or user-managed methods, can supplement physical backups\n with logical backups of schema objects made with Data Pump Export utility. Can\n later use Data Pump Import to re-create data after restore and recovery.\n Logical backups are mostly beyond the scope of the backup and recovery\n documentation." + "check": "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-61689' do\n title \"Recovery procedures and technical system features must exist to ensure\n recovery is done in a secure and verifiable manner.\"\n desc \"Application recovery and reconstitution constitutes executing an\ninformation system contingency plan comprised of activities that restore\nessential missions and business functions.\n\n Database management systems and transaction-based processing systems are\nexamples of information systems that are transaction-based. Transaction\nrollback and transaction journaling are examples of mechanisms supporting\ntransaction recovery.\n\n A DBMS may be vulnerable to use of compromised data or other critical files\nduring recovery. Use of compromised files could introduce maliciously altered\napplication code, relaxed security settings or loss of data integrity. Where\navailable, DBMS mechanisms to ensure use of only trusted files can help protect\nthe database from this type of compromise during DBMS recovery.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000144-DB-000101'\n tag \"gid\": 'V-61689'\n tag \"rid\": 'SV-76179r1_rule'\n tag \"stig_id\": 'O121-C2-012000'\n tag \"fix_id\": 'F-67603r1_fix'\n tag \"cci\": ['CCI-000553']\n tag \"nist\": ['CP-10 (2)', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Review DBMS recovery procedures and technical system features\n to determine if mechanisms exist and are in place to specify use of trusted\n files during DBMS recovery.\n\n If recovery procedures do not exist or are not sufficient to ensure recovery is\n done in a secure and verifiable manner, this is a finding.\n\n If system features exist and are not employed or not employed sufficiently,\n this is a finding.\n\n If circumstances that can inhibit a trusted recovery are not documented and\n appropriate mitigating procedures have not been put in place, this is a finding.\n\n Review the database backup strategy with the system administrator. Consider\n using Oracle RMAN with an encrypted backup to insure the backed up files can be\n trusted not to be compromised.\"\n tag \"fix\": \"Implement DBMS recovery procedures and employ technical system\n features to specify trusted files during DBMS recovery. Test the solution and\n review the site-specific criteria to ensure that the backup and recovery\n process uses trusted files.\n\n Ensure circumstances that can inhibit a trusted recovery are documented and\n appropriate mitigating procedures have been put in place.\n\n Oracle recommends using RMAN Backup and encrypting backup files. With\n encrypted files stored on a mount point with limited access, the integrity of\n the files can be trusted.\n\n - - - - -\n Notes on Oracle Backup and Recovery Solutions\n\n When implementing a backup and recovery strategy, have the following solutions\n available:\n\n -- Recovery Manager (RMAN)\n Recovery Manager is fully integrated with the Oracle database to perform a\n range of backup and recovery activities, including maintaining an RMAN\n repository of historical data about backups. Can access RMAN through the\n command line or through Oracle Enterprise Manager.\n\n -- User-managed backup and recovery\n In this solution, perform backup and recovery with a mixture of host operating\n system commands and SQL*Plus recovery commands. Responsible for determining all\n aspects of when and how backups and recovery are done.\n\n -- Media management\n If not wanting to use RMAN with an encrypted backup, consider configuring RMAN\n to make backups to a media manager. On most platforms, to back up to and\n restore from sequential media such as tape, must integrate a media manager with\n the Oracle database. Can use Oracle Secure Backup, which supports both database\n and file system backups to tape, as the media manager. See Oracle Secure Backup\n Administrator's Guide to learn how to set up RMAN for use specifically with\n Oracle Secure Backup.\n\n These solutions are supported by Oracle and are fully documented, but RMAN is\n the preferred solution for database backup and recovery. RMAN provides a common\n interface for backup tasks across different host operating systems and offers\n several backup techniques not available through user-managed methods.\n\n -- Incremental backups:\n An incremental backup stores only blocks changed since a previous backup.\n Thus, they provide more compact backups and faster recovery, thereby reducing\n the need to apply redo during data file media recovery. If enabling block\n change tracking, then can improve performance by avoiding full scans of every\n input data file. Can use the BACKUP INCREMENTAL command to perform incremental\n backups.\n\n -- Block media recovery:\n Can repair a data file with only a small number of corrupt data blocks without\n taking it off-line or restoring it from backup. Can use the RECOVER BLOCK\n command to perform block media recovery.\n\n -- Binary compression:\n A binary compression mechanism integrated into Oracle Database reduces the size\n of backups.\n\n -- Encrypted backups:\n RMAN uses backup encryption capabilities integrated into Oracle Database to\n store backup sets in an encrypted format. To create encrypted backups on disk,\n the database must use the Advanced Security Option. To create encrypted backups\n directly on tape, RMAN must use the Oracle Secure Backup SBT interface but does\n not require the Advanced Security Option.\n\n -- Automated database duplication:\n Easily creates a copy of the database, supporting various storage\n configurations, including direct duplication between ASM databases.\n\n -- Cross-platform data conversion:\n Whether using RMAN or user-managed methods, can supplement physical backups\n with logical backups of schema objects made with Data Pump Export utility. Can\n later use Data Pump Import to re-create data after restore and recovery.\n Logical backups are mostly beyond the scope of the backup and recovery\n documentation.\"\n describe 'A manual review is required to ensure recovery procedures and technical system features exist to ensure\n recovery is done in a secure and verifiable manner' do\n skip 'A manual review is required to ensure recovery procedures and technical system features exist to ensure\n recovery is done in a secure and verifiable manner'\n end\nend\n", + "code": "control 'V-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-61689.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61885.rb", "line": 1 }, - "id": "V-61689" + "id": "V-61885" }, { - "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": "The DBMS must use organization-defined replay-resistant authentication\n mechanisms for network access to privileged accounts.", + "desc": "An authentication process resists replay attacks if it is impractical\n to achieve a successful authentication by recording and replaying a previous\n authentication message.\n\n Techniques used to address this include protocols using nonces (e.g.,\n numbers generated for a specific one-time use) or challenges (e.g., TLS,\n WS_Security), and time synchronous or challenge-response one-time\n authenticators.\n\n Replay attacks, if successfully used against a database account, could\n result in unfettered access to the database settings and data. A successful\n replay attack against a privileged database account could result in a complete\n compromise of the database.\n\n Oracle Database enables you to encrypt data that is sent over a network.\n There is no distinction between privileged and non-privileged accounts.\n\n Encryption of network data provides data privacy so that unauthorized\n parties are not able to view plaintext data as it passes over the network.\n Oracle Database also provides protection against two forms of active attacks.\n\n Data modification attack: An unauthorized party intercepting data in\n transit, altering it, and retransmitting it is a data modification attack. For\n example, intercepting a $100 bank deposit, changing the amount to $10,000, and\n retransmitting the higher amount is a data modification attack.\n\n Replay attack: Repetitively retransmitting an entire set of valid data is\n a replay attack, such as intercepting a $100 bank withdrawal and retransmitting\n it ten times, thereby receiving $1,000.\n\n AES and Triple-DES operate in outer Cipher Block Chaining (CBC) mode.\n\n The DES algorithm uses a 56-bit key length.\n\n SHA-1 is in the process of being removed from service within the DoD and\n it's use is to be limited during the transition to SHA-2. Use of SHA-1 for\n digital signature generation is prohibited. Allowable uses during the\n transition include CHECKSUM usage and verification of legacy certificate\n signatures. SHA-1 is considered a temporary solution during legacy application\n transitionary periods and should not be engineered into new applications. SHA-2\n is the path forward for DoD.", "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": "An authentication process resists replay attacks if it is impractical\n to achieve a successful authentication by recording and replaying a previous\n authentication message.\n\n Techniques used to address this include protocols using nonces (e.g.,\n numbers generated for a specific one-time use) or challenges (e.g., TLS,\n WS_Security), and time synchronous or challenge-response one-time\n authenticators.\n\n Replay attacks, if successfully used against a database account, could\n result in unfettered access to the database settings and data. A successful\n replay attack against a privileged database account could result in a complete\n compromise of the database.\n\n Oracle Database enables you to encrypt data that is sent over a network.\n There is no distinction between privileged and non-privileged accounts.\n\n Encryption of network data provides data privacy so that unauthorized\n parties are not able to view plaintext data as it passes over the network.\n Oracle Database also provides protection against two forms of active attacks.\n\n Data modification attack: An unauthorized party intercepting data in\n transit, altering it, and retransmitting it is a data modification attack. For\n example, intercepting a $100 bank deposit, changing the amount to $10,000, and\n retransmitting the higher amount is a data modification attack.\n\n Replay attack: Repetitively retransmitting an entire set of valid data is\n a replay attack, such as intercepting a $100 bank withdrawal and retransmitting\n it ten times, thereby receiving $1,000.\n\n AES and Triple-DES operate in outer Cipher Block Chaining (CBC) mode.\n\n The DES algorithm uses a 56-bit key length.\n\n SHA-1 is in the process of being removed from service within the DoD and\n it's use is to be limited during the transition to SHA-2. Use of SHA-1 for\n digital signature generation is prohibited. Allowable uses during the\n transition include CHECKSUM usage and verification of legacy certificate\n signatures. SHA-1 is considered a temporary solution during legacy application\n transitionary periods and should not be engineered into new applications. SHA-2\n is the path forward for DoD." }, - "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-000156-DB-000111", + "gid": "V-61713", + "rid": "SV-76203r4_rule", + "stig_id": "O121-C2-013600", + "fix_id": "F-67629r1_fix", "cci": [ - "CCI-001499" + "CCI-001941" ], "nist": [ - "CM-5 (6)", + "IA-2 (8)", "Rev_4" ], "false_negatives": null, @@ -3587,35 +3683,39 @@ "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 DBMS settings, OS settings, and/or enterprise-level\n authentication/access mechanism settings to determine whether\n organization-defined replay-resistant authentication mechanisms for network\n access to privileged accounts exist.\n\n If these mechanisms do not exist, this is a finding.\n\n To check that network encryption is enabled and using site-specified encryption\n procedures, look in SQLNET.ORA, located at\n $ORACLE_HOME/network/admin/sqlnet.ora. (Note: This assumes that a single\n sqlnet.ora file, in the default location, is in use. Please see the\n supplemental file \"Non-default sqlnet.ora configurations.pdf\" for how to find\n multiple and/or differently located sqlnet.ora files.) If encryption is set,\n entries like the following will be present:\n\n SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER= (SHA384)\n SQLNET.ENCRYPTION_TYPES_SERVER=(AES256)\n SQLNET.CRYPTO_CHECKSUM_SERVER = required\n\n SQLNET.CRYPTO_CHECKSUM_TYPES_CLIENT= (SHA384)\n SQLNET.ENCRYPTION_TYPES_CLIENT= (AES256)\n SQLNET.CRYPTO_CHECKSUM_CLIENT = requested\n\n (The values assigned to the parameters may be different, the combination of\n parameters may be different, and not all of the example parameters will\n necessarily exist in the file.)", + "fix": "Configure DBMS, OS and/or enterprise-level authentication/access\n mechanism to utilize replay-resistant authentication mechanisms such as nonces\n (e.g., numbers generated for a specific one-time use) or challenges (e.g., TLS,\n WS_Security), and time synchronous or challenge-response one-time\n authenticators.\n\n If appropriate, apply Oracle Data Network Encryption to protect against replay\n mechanisms." }, - "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-61713' 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-61713.rb", "line": 1 }, - "id": "V-61539" + "id": "V-61713" }, { - "title": "DBMS default accounts must be protected from misuse.", - "desc": "The Security Requirements Guide says, Default accounts are usually\n accounts that have special privileges required to administer the database.\n Well-known DBMS account names are targeted most frequently by attackers and are\n thus more prone to providing unauthorized access to the database.\n\n If default account names are not changed, an attacker has a predefined\n list of accounts to target. Since most default accounts are administrative in\n nature, the compromise of a default account can have catastrophic consequences,\n including the complete loss of control over the information system.\n\n However, Oracle does not provide for changing user names directly.\n Workarounds to achieve the effect of a name change are cumbersome. In\n addition, names of essential system accounts such as SYS are baked into the\n product, with thousands of dependencies involved. Making such a change would\n risk making the DBMS inoperative, and would interfere with getting support from\n Oracle.\n\n The Check and Fix, therefore, relate to good practices for protecting the\n essential system accounts from misuse.", + "title": "The DBMS must support organizational requirements to enforce password\n complexity by the number of lower-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.", "descriptions": { - "default": "The Security Requirements Guide says, Default accounts are usually\n accounts that have special privileges required to administer the database.\n Well-known DBMS account names are targeted most frequently by attackers and are\n thus more prone to providing unauthorized access to the database.\n\n If default account names are not changed, an attacker has a predefined\n list of accounts to target. Since most default accounts are administrative in\n nature, the compromise of a default account can have catastrophic consequences,\n including the complete loss of control over the information system.\n\n However, Oracle does not provide for changing user names directly.\n Workarounds to achieve the effect of a name change are cumbersome. In\n addition, names of essential system accounts such as SYS are baked into the\n product, with thousands of dependencies involved. Making such a change would\n risk making the DBMS inoperative, and would interfere with getting support from\n Oracle.\n\n The Check and Fix, therefore, relate to good practices for protecting the\n essential system accounts from misuse." + "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." }, "impact": 0.5, - "refs": [], + "refs": [ + { + "ref": [] + } + ], "tags": { - "gtitle": "SRG-APP-000063-DB-000023", - "gid": "V-61849", - "rid": "SV-76339r1_rule", - "stig_id": "O121-N2-004701", - "fix_id": "F-67765r1_fix", + "gtitle": "SRG-APP-000167-DB-000071", + "gid": "V-61725", + "rid": "SV-76215r1_rule", + "stig_id": "O121-C2-014200", + "fix_id": "F-67641r1_fix", "cci": [ - "CCI-000366" + "CCI-000193" ], "nist": [ - "CM-6 b", + "IA-5 (1) (a)", "Rev_4" ], "false_negatives": null, @@ -3628,35 +3728,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Review the use of the essential system accounts with the\n DBA(s). Request evidence that administrators have individual administrative\n accounts and that they use these rather than SYS, SYSTEM, SYSMAN, etc., in\n carrying out their duties.\n\n If the evidence indicates otherwise, this is a finding.\n\n Review the status of the essential system accounts, in the view DBA_USERS. If\n any of these accounts is not locked, or is not documented as a requirement,\n this is a finding.", - "fix": "Ensure that all individuals with DBA responsibilities always log\n on under their individual administrative accounts.\n\n Ensure that the passwords for essential system accounts such as SYS are\n available only to authorized administrators and tightly guarded to avoid\n misuse. Ensure that these accounts are kept locked except when it is\n specifically necessary to use them." + "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\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 lower-case\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.)" }, - "code": "control 'V-61849' do\n title 'DBMS default accounts must be protected from misuse.'\n desc \"The Security Requirements Guide says, Default accounts are usually\n accounts that have special privileges required to administer the database.\n Well-known DBMS account names are targeted most frequently by attackers and are\n thus more prone to providing unauthorized access to the database.\n\n If default account names are not changed, an attacker has a predefined\n list of accounts to target. Since most default accounts are administrative in\n nature, the compromise of a default account can have catastrophic consequences,\n including the complete loss of control over the information system.\n\n However, Oracle does not provide for changing user names directly.\n Workarounds to achieve the effect of a name change are cumbersome. In\n addition, names of essential system accounts such as SYS are baked into the\n product, with thousands of dependencies involved. Making such a change would\n risk making the DBMS inoperative, and would interfere with getting support from\n Oracle.\n\n The Check and Fix, therefore, relate to good practices for protecting the\n essential system accounts from misuse.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000063-DB-000023'\n tag \"gid\": 'V-61849'\n tag \"rid\": 'SV-76339r1_rule'\n tag \"stig_id\": 'O121-N2-004701'\n tag \"fix_id\": 'F-67765r1_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 use of the essential system accounts with the\n DBA(s). Request evidence that administrators have individual administrative\n accounts and that they use these rather than SYS, SYSTEM, SYSMAN, etc., in\n carrying out their duties.\n\n If the evidence indicates otherwise, this is a finding.\n\n Review the status of the essential system accounts, in the view DBA_USERS. If\n any of these accounts is not locked, or is not documented as a requirement,\n this is a finding.\"\n tag \"fix\": \"Ensure that all individuals with DBA responsibilities always log\n on under their individual administrative accounts.\n\n Ensure that the passwords for essential system accounts such as SYS are\n available only to authorized administrators and tightly guarded to avoid\n misuse. Ensure that these accounts are kept locked except when it is\n specifically necessary to use them.\"\n describe 'A manual review is required to ensure the DBMS default accounts are protected from misuse' do\n skip 'A manual review is required to ensure the DBMS default accounts are protected from misuse'\n end\nend\n", + "code": "control 'V-61725' do\n title \"The DBMS must support organizational requirements to enforce password\n complexity by the number of lower-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-000167-DB-000071'\n tag \"gid\": 'V-61725'\n tag \"rid\": 'SV-76215r1_rule'\n tag \"stig_id\": 'O121-C2-014200'\n tag \"fix_id\": 'F-67641r1_fix'\n tag \"cci\": ['CCI-000193']\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\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 lower-case\n characters (1 unless otherwise specified), this is a finding.\"\n tag \"fix\": \"If all user accounts are authenticated by the OS or an\n enterprise-level authentication/access mechanism, and not by Oracle, no fix to\n the DBMS is required.\n\n If any user accounts are managed by Oracle: Develop, test and implement a\n password verification function that enforces DoD requirements.\n\n (Oracle supplies a sample function called ORA12C_STRONG_VERIFY_FUNCTION, in the\n script file\n /RDBMS/ADMIN/utlpwdmg.sql. This can be used as the starting point\n for a customized function.)\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n query = %{\n SELECT PROFILE, RESOURCE_NAME, LIMIT FROM DBA_PROFILES WHERE PROFILE =\n '%s' AND RESOURCE_NAME = 'PASSWORD_VERIFY_FUNCTION'\n }\n\n user_profiles = sql.query('SELECT profile FROM dba_users;').column('profile').uniq\n\n user_profiles.each do |profile|\n next if profile == \"RDSADMIN\"\n password_verify_function = sql.query(format(query, profile: profile)).column('limit')\n\n describe \"The oracle database account password verify function for profile: #{profile}\" do\n subject { password_verify_function }\n it { should_not eq ['NULL'] }\n end\n end\n if user_profiles.empty?\n describe 'There are no user profiles, therefore this control is NA' do\n skip 'There are no user profiles, therefore this control is NA'\n end\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61849.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61725.rb", "line": 1 }, - "id": "V-61849" + "id": "V-61725" }, { - "title": "The DBMS must terminate user sessions upon user logoff or any other\n organization or policy-defined session termination events, such as idle time\n limit exceeded.", - "desc": "This requirement focuses on communications protection at the\n application session, versus network packet, level.\n\n Session IDs are tokens generated by web applications to uniquely identify\n an application user's session. Applications will make application decisions\n and execute business logic based on the session ID. Unique session identifiers\n or IDs are the opposite of sequentially generated session IDs, which can be\n easily guessed by an attacker. Unique session IDs help to reduce predictability\n of said identifiers. Unique session IDs address man-in-the-middle attacks,\n including session hijacking or insertion of false information into a session.\n If the attackers are unable to identify or guess the session information\n related to pending application traffic, they will have more difficulty in\n hijacking the session or otherwise manipulating valid sessions. When a user\n logs out, or when any other session termination event occurs, the application\n must terminate the user session to minimize the potential for an attacker to\n hijack that particular user session.\n\n Database sessions must be terminated when no longer in use in order to\n prevent session hijacking.", + "title": "Recovery procedures and technical system features must exist to ensure\n recovery is done in a secure and verifiable manner.", + "desc": "Application recovery and reconstitution constitutes executing an\ninformation system contingency plan comprised of activities that restore\nessential missions and business functions.\n\n Database management systems and transaction-based processing systems are\nexamples of information systems that are transaction-based. Transaction\nrollback and transaction journaling are examples of mechanisms supporting\ntransaction recovery.\n\n A DBMS may be vulnerable to use of compromised data or other critical files\nduring recovery. Use of compromised files could introduce maliciously altered\napplication code, relaxed security settings or loss of data integrity. Where\navailable, DBMS mechanisms to ensure use of only trusted files can help protect\nthe database from this type of compromise during DBMS recovery.", "descriptions": { - "default": "This requirement focuses on communications protection at the\n application session, versus network packet, level.\n\n Session IDs are tokens generated by web applications to uniquely identify\n an application user's session. Applications will make application decisions\n and execute business logic based on the session ID. Unique session identifiers\n or IDs are the opposite of sequentially generated session IDs, which can be\n easily guessed by an attacker. Unique session IDs help to reduce predictability\n of said identifiers. Unique session IDs address man-in-the-middle attacks,\n including session hijacking or insertion of false information into a session.\n If the attackers are unable to identify or guess the session information\n related to pending application traffic, they will have more difficulty in\n hijacking the session or otherwise manipulating valid sessions. When a user\n logs out, or when any other session termination event occurs, the application\n must terminate the user session to minimize the potential for an attacker to\n hijack that particular user session.\n\n Database sessions must be terminated when no longer in use in order to\n prevent session hijacking." + "default": "Application recovery and reconstitution constitutes executing an\ninformation system contingency plan comprised of activities that restore\nessential missions and business functions.\n\n Database management systems and transaction-based processing systems are\nexamples of information systems that are transaction-based. Transaction\nrollback and transaction journaling are examples of mechanisms supporting\ntransaction recovery.\n\n A DBMS may be vulnerable to use of compromised data or other critical files\nduring recovery. Use of compromised files could introduce maliciously altered\napplication code, relaxed security settings or loss of data integrity. Where\navailable, DBMS mechanisms to ensure use of only trusted files can help protect\nthe database from this type of compromise during DBMS recovery." }, "impact": 0.5, "refs": [], "tags": { - "gtitle": "SRG-APP-000220-DB-000149", - "gid": "V-61765", - "rid": "SV-76255r2_rule", - "stig_id": "O121-C2-017600", - "fix_id": "F-67681r4_fix", + "gtitle": "SRG-APP-000144-DB-000101", + "gid": "V-61689", + "rid": "SV-76179r1_rule", + "stig_id": "O121-C2-012000", + "fix_id": "F-67603r1_fix", "cci": [ - "CCI-001185" + "CCI-000553" ], "nist": [ - "SC-23 (1)", + "CP-10 (2)", "Rev_4" ], "false_negatives": null, @@ -3669,39 +3769,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Review DBMS settings and vendor documentation to verify user\n sessions are terminated upon user logout. If they are not, this is a finding.\n\n Review system documentation and organization policy to identify other events\n that should result in session terminations. If other session termination events\n are defined, review DBMS settings to verify occurrences of these events would\n cause session termination.\n\n If occurrences of defined session-terminating events do not cause session\n terminations, this is a finding.\n\n When a user logs off of an Oracle session gracefully or has the session\n terminated for an idle timeout or any other reason, the session is terminated,\n and the resources are returned to the system. Check with the DBA to see what\n mechanism is used to disconnect the session and what events the site uses to\n determine if a connection needs to be terminated.\n\n To test for timeout, open a connection and leave it idle for a period greater\n than the defined idle timeout setting enforced by the system. Then try to use\n the connection. If the connection is no longer active, then the mechanism\n deployed to terminate the connection is active and working.", - "fix": "Configure DBMS settings to terminate sessions upon user logoff.\n Configure DBMS settings to terminate sessions upon the occurrence of any\n organization or policy-defined session termination event.\n\n - - - - -\n\n To configure specific session termination processes, we need to define the\n organization or policy-defined session termination event. Below are some\n examples.\n\n Oracle has several ways to disconnect idle sessions, both from within SQL*Plus\n via resources profiles (connect_time, idle_time) and with the SQL*net expire\n time parameter.\n\n Can use profiles to set the connect time and idle time with \"alter profile\"\n statements:\n\n alter profile senior_claim_analyst limit\n connect_time 15\n sessions_per_user 2\n ldle_time 10;\n\n Profiles comprise a named set of resource limits. By default, when users are\n created, they are given the default profile, which provides unlimited use of\n all resources.\n\n The syntax to create a profile follows:\n\n CREATE PROFILE LIMIT resource_parameters|password_parameters;\n Resource_parameters:\n [SESSIONS_PER_USER n|UNLIMITED|DEFAULT]\n [CPU_PER_SESSION n|UNLIMITED|DEFAULT]\n [CPU_PER_CALL n|UNLIMITED|DEFAULT]\n [CONNECT_TIME n|UNLIMITED|DEFAULT]\n [IDLE_TIME n|UNLIMITED|DEFAULT]\n\n By setting resource limits, can prevent users from performing operations that\n will tie up the system and prevent other users from performing operations. Can\n use resource limits for security, to ensure that users log off the system, so\n as not to leave the session connected for long periods of time.\n\n The system resource limits can be enforced at the session level, the call\n level, or both. The session level is calculated from the time the user logs on\n to the database until the user exits. The call level applies to each SQL\n command issued. Session-level limits are enforced for each connection. When a\n session-level limit is exceeded, only the last SQL command issued is rolled\n back; no further work can be performed until a commit, rollback, or exit is\n performed.\n\n Using SQLNET.EXPIRE_TIME\n\n The sqlnet.expire_time parameter is used to set a time interval, in minutes, to\n determine how often a probe should be sent verifying that client/server\n connections are active. If there is a need to ensure that connections are not\n left open indefinitely (or up to the time set by operating system-specific\n parameters), set a value that is greater than 0. This protects the system from\n connections left open due to an abnormal client termination.\n\n When the probe detects a terminated connection or a connection no longer in\n use, it signals an error, causing the server process to exit. This setting is\n intended for use on the database server side of the connection, which usually\n handles multiple connections at any one time. Limitations on using this\n terminated (dead) connection detection feature are:\n\n sqlnet.expire_time cannot be used on bequeathed connections.\n\n The SQL*Net expire_time probe packet will generate additional network traffic\n that may downgrade the network's performance, depending on the number of\n connections.\n\n Depending on the operating system that is in use, additional server processing\n may need to be performed to distinguish the connection probe from other events\n that occur. This overhead for detection of probe events can result in\n downgraded network performance.\n\n Turning-on expire_time\n\n To set up these advanced features, simply edit the sqlnet.ora file. If a\n beginner, follow this procedure:\n\n Start the Oracle Network Manager GUI.\n\n In the GUI navigator pane, expand the icons Local >> Profile.\n\n From the list on the right-hand pane, select General.\n\n Click on the Advanced tab.\n\n Next, enter the values for the fields or options to set.\n\n When finished, choose File >> Save Network Configuration to write the changes\n to the sqlnet.ora file. (Note: This assumes that a single sqlnet.ora file, in\n the default location, is in use. Please see the supplemental file \"Non-default\n sqlnet.ora configurations.pdf\" for how to find multiple and/or differently\n located sqlnet.ora files.)\n\n The sqlnet.ora inbound_connect_timeout parameter\n\n The sqlnet.ora inbound_connect_timeout parameter is used to limit the time, set\n in seconds, for a client to connect with the database server and provide the\n required authentication information.\n\n Also see sqlnet.inbound_connect_timeout tips.\n\n To limit consumption of Oracle resources by unauthorized users and enable an\n audit trail, should set time-limit values for the\n sqlnet.inbound_connect_timeout parameter in wall-clock seconds. (This parameter\n does not have default values.) Failure resulting from\n sqlnet.inbound_connect_timeout will throw an ORA-03136 inbound connection timed\n out error. " + "check": "Review DBMS recovery procedures and technical system features\n to determine if mechanisms exist and are in place to specify use of trusted\n files during DBMS recovery.\n\n If recovery procedures do not exist or are not sufficient to ensure recovery is\n done in a secure and verifiable manner, this is a finding.\n\n If system features exist and are not employed or not employed sufficiently,\n this is a finding.\n\n If circumstances that can inhibit a trusted recovery are not documented and\n appropriate mitigating procedures have not been put in place, this is a finding.\n\n Review the database backup strategy with the system administrator. Consider\n using Oracle RMAN with an encrypted backup to insure the backed up files can be\n trusted not to be compromised.", + "fix": "Implement DBMS recovery procedures and employ technical system\n features to specify trusted files during DBMS recovery. Test the solution and\n review the site-specific criteria to ensure that the backup and recovery\n process uses trusted files.\n\n Ensure circumstances that can inhibit a trusted recovery are documented and\n appropriate mitigating procedures have been put in place.\n\n Oracle recommends using RMAN Backup and encrypting backup files. With\n encrypted files stored on a mount point with limited access, the integrity of\n the files can be trusted.\n\n - - - - -\n Notes on Oracle Backup and Recovery Solutions\n\n When implementing a backup and recovery strategy, have the following solutions\n available:\n\n -- Recovery Manager (RMAN)\n Recovery Manager is fully integrated with the Oracle database to perform a\n range of backup and recovery activities, including maintaining an RMAN\n repository of historical data about backups. Can access RMAN through the\n command line or through Oracle Enterprise Manager.\n\n -- User-managed backup and recovery\n In this solution, perform backup and recovery with a mixture of host operating\n system commands and SQL*Plus recovery commands. Responsible for determining all\n aspects of when and how backups and recovery are done.\n\n -- Media management\n If not wanting to use RMAN with an encrypted backup, consider configuring RMAN\n to make backups to a media manager. On most platforms, to back up to and\n restore from sequential media such as tape, must integrate a media manager with\n the Oracle database. Can use Oracle Secure Backup, which supports both database\n and file system backups to tape, as the media manager. See Oracle Secure Backup\n Administrator's Guide to learn how to set up RMAN for use specifically with\n Oracle Secure Backup.\n\n These solutions are supported by Oracle and are fully documented, but RMAN is\n the preferred solution for database backup and recovery. RMAN provides a common\n interface for backup tasks across different host operating systems and offers\n several backup techniques not available through user-managed methods.\n\n -- Incremental backups:\n An incremental backup stores only blocks changed since a previous backup.\n Thus, they provide more compact backups and faster recovery, thereby reducing\n the need to apply redo during data file media recovery. If enabling block\n change tracking, then can improve performance by avoiding full scans of every\n input data file. Can use the BACKUP INCREMENTAL command to perform incremental\n backups.\n\n -- Block media recovery:\n Can repair a data file with only a small number of corrupt data blocks without\n taking it off-line or restoring it from backup. Can use the RECOVER BLOCK\n command to perform block media recovery.\n\n -- Binary compression:\n A binary compression mechanism integrated into Oracle Database reduces the size\n of backups.\n\n -- Encrypted backups:\n RMAN uses backup encryption capabilities integrated into Oracle Database to\n store backup sets in an encrypted format. To create encrypted backups on disk,\n the database must use the Advanced Security Option. To create encrypted backups\n directly on tape, RMAN must use the Oracle Secure Backup SBT interface but does\n not require the Advanced Security Option.\n\n -- Automated database duplication:\n Easily creates a copy of the database, supporting various storage\n configurations, including direct duplication between ASM databases.\n\n -- Cross-platform data conversion:\n Whether using RMAN or user-managed methods, can supplement physical backups\n with logical backups of schema objects made with Data Pump Export utility. Can\n later use Data Pump Import to re-create data after restore and recovery.\n Logical backups are mostly beyond the scope of the backup and recovery\n documentation." }, - "code": "control 'V-61765' do\n title \"The DBMS must terminate user sessions upon user logoff or any other\n organization or policy-defined session termination events, such as idle time\n limit exceeded.\"\n desc \"This requirement focuses on communications protection at the\n application session, versus network packet, level.\n\n Session IDs are tokens generated by web applications to uniquely identify\n an application user's session. Applications will make application decisions\n and execute business logic based on the session ID. Unique session identifiers\n or IDs are the opposite of sequentially generated session IDs, which can be\n easily guessed by an attacker. Unique session IDs help to reduce predictability\n of said identifiers. Unique session IDs address man-in-the-middle attacks,\n including session hijacking or insertion of false information into a session.\n If the attackers are unable to identify or guess the session information\n related to pending application traffic, they will have more difficulty in\n hijacking the session or otherwise manipulating valid sessions. When a user\n logs out, or when any other session termination event occurs, the application\n must terminate the user session to minimize the potential for an attacker to\n hijack that particular user session.\n\n Database sessions must be terminated when no longer in use in order to\n prevent session hijacking.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000220-DB-000149'\n tag \"gid\": 'V-61765'\n tag \"rid\": 'SV-76255r2_rule'\n tag \"stig_id\": 'O121-C2-017600'\n tag \"fix_id\": 'F-67681r4_fix'\n tag \"cci\": ['CCI-001185']\n tag \"nist\": ['SC-23 (1)', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Review DBMS settings and vendor documentation to verify user\n sessions are terminated upon user logout. If they are not, this is a finding.\n\n Review system documentation and organization policy to identify other events\n that should result in session terminations. If other session termination events\n are defined, review DBMS settings to verify occurrences of these events would\n cause session termination.\n\n If occurrences of defined session-terminating events do not cause session\n terminations, this is a finding.\n\n When a user logs off of an Oracle session gracefully or has the session\n terminated for an idle timeout or any other reason, the session is terminated,\n and the resources are returned to the system. Check with the DBA to see what\n mechanism is used to disconnect the session and what events the site uses to\n determine if a connection needs to be terminated.\n\n To test for timeout, open a connection and leave it idle for a period greater\n than the defined idle timeout setting enforced by the system. Then try to use\n the connection. If the connection is no longer active, then the mechanism\n deployed to terminate the connection is active and working.\"\n tag \"fix\": \"Configure DBMS settings to terminate sessions upon user logoff.\n Configure DBMS settings to terminate sessions upon the occurrence of any\n organization or policy-defined session termination event.\n\n - - - - -\n\n To configure specific session termination processes, we need to define the\n organization or policy-defined session termination event. Below are some\n examples.\n\n Oracle has several ways to disconnect idle sessions, both from within SQL*Plus\n via resources profiles (connect_time, idle_time) and with the SQL*net expire\n time parameter.\n\n Can use profiles to set the connect time and idle time with \\\"alter profile\\\"\n statements:\n\n alter profile senior_claim_analyst limit\n connect_time 15\n sessions_per_user 2\n ldle_time 10;\n\n Profiles comprise a named set of resource limits. By default, when users are\n created, they are given the default profile, which provides unlimited use of\n all resources.\n\n The syntax to create a profile follows:\n\n CREATE PROFILE LIMIT resource_parameters|password_parameters;\n Resource_parameters:\n [SESSIONS_PER_USER n|UNLIMITED|DEFAULT]\n [CPU_PER_SESSION n|UNLIMITED|DEFAULT]\n [CPU_PER_CALL n|UNLIMITED|DEFAULT]\n [CONNECT_TIME n|UNLIMITED|DEFAULT]\n [IDLE_TIME n|UNLIMITED|DEFAULT]\n\n By setting resource limits, can prevent users from performing operations that\n will tie up the system and prevent other users from performing operations. Can\n use resource limits for security, to ensure that users log off the system, so\n as not to leave the session connected for long periods of time.\n\n The system resource limits can be enforced at the session level, the call\n level, or both. The session level is calculated from the time the user logs on\n to the database until the user exits. The call level applies to each SQL\n command issued. Session-level limits are enforced for each connection. When a\n session-level limit is exceeded, only the last SQL command issued is rolled\n back; no further work can be performed until a commit, rollback, or exit is\n performed.\n\n Using SQLNET.EXPIRE_TIME\n\n The sqlnet.expire_time parameter is used to set a time interval, in minutes, to\n determine how often a probe should be sent verifying that client/server\n connections are active. If there is a need to ensure that connections are not\n left open indefinitely (or up to the time set by operating system-specific\n parameters), set a value that is greater than 0. This protects the system from\n connections left open due to an abnormal client termination.\n\n When the probe detects a terminated connection or a connection no longer in\n use, it signals an error, causing the server process to exit. This setting is\n intended for use on the database server side of the connection, which usually\n handles multiple connections at any one time. Limitations on using this\n terminated (dead) connection detection feature are:\n\n sqlnet.expire_time cannot be used on bequeathed connections.\n\n The SQL*Net expire_time probe packet will generate additional network traffic\n that may downgrade the network's performance, depending on the number of\n connections.\n\n Depending on the operating system that is in use, additional server processing\n may need to be performed to distinguish the connection probe from other events\n that occur. This overhead for detection of probe events can result in\n downgraded network performance.\n\n Turning-on expire_time\n\n To set up these advanced features, simply edit the sqlnet.ora file. If a\n beginner, follow this procedure:\n\n Start the Oracle Network Manager GUI.\n\n In the GUI navigator pane, expand the icons Local >> Profile.\n\n From the list on the right-hand pane, select General.\n\n Click on the Advanced tab.\n\n Next, enter the values for the fields or options to set.\n\n When finished, choose File >> Save Network Configuration to write the changes\n to the sqlnet.ora file. (Note: This assumes that a single sqlnet.ora file, in\n the default location, is in use. Please see the supplemental file \\\"Non-default\n sqlnet.ora configurations.pdf\\\" for how to find multiple and/or differently\n located sqlnet.ora files.)\n\n The sqlnet.ora inbound_connect_timeout parameter\n\n The sqlnet.ora inbound_connect_timeout parameter is used to limit the time, set\n in seconds, for a client to connect with the database server and provide the\n required authentication information.\n\n Also see sqlnet.inbound_connect_timeout tips.\n\n To limit consumption of Oracle resources by unauthorized users and enable an\n audit trail, should set time-limit values for the\n sqlnet.inbound_connect_timeout parameter in wall-clock seconds. (This parameter\n does not have default values.) Failure resulting from\n sqlnet.inbound_connect_timeout will throw an ORA-03136 inbound connection timed\n out error. \"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n query_idle_time = %{\n SELECT PROFILE, RESOURCE_NAME, LIMIT FROM DBA_PROFILES WHERE PROFILE =\n '%s' AND RESOURCE_NAME = 'IDLE_TIME'\n }\n\n query_sessions_per_user = %{\n SELECT PROFILE, RESOURCE_NAME, LIMIT FROM DBA_PROFILES WHERE PROFILE =\n '%s' AND RESOURCE_NAME = 'SESSIONS_PER_USER'\n }\n\n query_connect_time = %{\n SELECT PROFILE, RESOURCE_NAME, LIMIT FROM DBA_PROFILES WHERE PROFILE =\n '%s' AND RESOURCE_NAME = 'CONNECT_TIME'\n }\n\n user_profiles = sql.query('SELECT profile FROM dba_users;').column('profile').uniq\n\n user_profiles.each do |profile|\n idle_time = sql.query(format(query_idle_time, profile: profile)).column('limit')\n sessions_per_user = sql.query(format(query_sessions_per_user, profile: profile)).column('limit')\n connect_time = sql.query(format(query_connect_time, profile: profile)).column('limit')\n\n describe \"The oracle database idle time for profile: #{profile}\" do\n subject { idle_time }\n it { should cmp <= 15 }\n end\n\n describe \"The oracle database number of sessions per user for profile: #{profile}\" do\n subject { sessions_per_user }\n it { should cmp <= 3 }\n end\n\n describe \"The oracle database connect time for profile: #{profile}\" do\n subject { connect_time }\n it { should cmp <= 15 }\n end\n end\n if user_profiles.empty?\n describe 'There are no user profiles, therefore this control is NA' do\n skip 'There are no user profiles, therefore this control is NA'\n end\n end\nend\n", + "code": "control 'V-61689' do\n title \"Recovery procedures and technical system features must exist to ensure\n recovery is done in a secure and verifiable manner.\"\n desc \"Application recovery and reconstitution constitutes executing an\ninformation system contingency plan comprised of activities that restore\nessential missions and business functions.\n\n Database management systems and transaction-based processing systems are\nexamples of information systems that are transaction-based. Transaction\nrollback and transaction journaling are examples of mechanisms supporting\ntransaction recovery.\n\n A DBMS may be vulnerable to use of compromised data or other critical files\nduring recovery. Use of compromised files could introduce maliciously altered\napplication code, relaxed security settings or loss of data integrity. Where\navailable, DBMS mechanisms to ensure use of only trusted files can help protect\nthe database from this type of compromise during DBMS recovery.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000144-DB-000101'\n tag \"gid\": 'V-61689'\n tag \"rid\": 'SV-76179r1_rule'\n tag \"stig_id\": 'O121-C2-012000'\n tag \"fix_id\": 'F-67603r1_fix'\n tag \"cci\": ['CCI-000553']\n tag \"nist\": ['CP-10 (2)', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Review DBMS recovery procedures and technical system features\n to determine if mechanisms exist and are in place to specify use of trusted\n files during DBMS recovery.\n\n If recovery procedures do not exist or are not sufficient to ensure recovery is\n done in a secure and verifiable manner, this is a finding.\n\n If system features exist and are not employed or not employed sufficiently,\n this is a finding.\n\n If circumstances that can inhibit a trusted recovery are not documented and\n appropriate mitigating procedures have not been put in place, this is a finding.\n\n Review the database backup strategy with the system administrator. Consider\n using Oracle RMAN with an encrypted backup to insure the backed up files can be\n trusted not to be compromised.\"\n tag \"fix\": \"Implement DBMS recovery procedures and employ technical system\n features to specify trusted files during DBMS recovery. Test the solution and\n review the site-specific criteria to ensure that the backup and recovery\n process uses trusted files.\n\n Ensure circumstances that can inhibit a trusted recovery are documented and\n appropriate mitigating procedures have been put in place.\n\n Oracle recommends using RMAN Backup and encrypting backup files. With\n encrypted files stored on a mount point with limited access, the integrity of\n the files can be trusted.\n\n - - - - -\n Notes on Oracle Backup and Recovery Solutions\n\n When implementing a backup and recovery strategy, have the following solutions\n available:\n\n -- Recovery Manager (RMAN)\n Recovery Manager is fully integrated with the Oracle database to perform a\n range of backup and recovery activities, including maintaining an RMAN\n repository of historical data about backups. Can access RMAN through the\n command line or through Oracle Enterprise Manager.\n\n -- User-managed backup and recovery\n In this solution, perform backup and recovery with a mixture of host operating\n system commands and SQL*Plus recovery commands. Responsible for determining all\n aspects of when and how backups and recovery are done.\n\n -- Media management\n If not wanting to use RMAN with an encrypted backup, consider configuring RMAN\n to make backups to a media manager. On most platforms, to back up to and\n restore from sequential media such as tape, must integrate a media manager with\n the Oracle database. Can use Oracle Secure Backup, which supports both database\n and file system backups to tape, as the media manager. See Oracle Secure Backup\n Administrator's Guide to learn how to set up RMAN for use specifically with\n Oracle Secure Backup.\n\n These solutions are supported by Oracle and are fully documented, but RMAN is\n the preferred solution for database backup and recovery. RMAN provides a common\n interface for backup tasks across different host operating systems and offers\n several backup techniques not available through user-managed methods.\n\n -- Incremental backups:\n An incremental backup stores only blocks changed since a previous backup.\n Thus, they provide more compact backups and faster recovery, thereby reducing\n the need to apply redo during data file media recovery. If enabling block\n change tracking, then can improve performance by avoiding full scans of every\n input data file. Can use the BACKUP INCREMENTAL command to perform incremental\n backups.\n\n -- Block media recovery:\n Can repair a data file with only a small number of corrupt data blocks without\n taking it off-line or restoring it from backup. Can use the RECOVER BLOCK\n command to perform block media recovery.\n\n -- Binary compression:\n A binary compression mechanism integrated into Oracle Database reduces the size\n of backups.\n\n -- Encrypted backups:\n RMAN uses backup encryption capabilities integrated into Oracle Database to\n store backup sets in an encrypted format. To create encrypted backups on disk,\n the database must use the Advanced Security Option. To create encrypted backups\n directly on tape, RMAN must use the Oracle Secure Backup SBT interface but does\n not require the Advanced Security Option.\n\n -- Automated database duplication:\n Easily creates a copy of the database, supporting various storage\n configurations, including direct duplication between ASM databases.\n\n -- Cross-platform data conversion:\n Whether using RMAN or user-managed methods, can supplement physical backups\n with logical backups of schema objects made with Data Pump Export utility. Can\n later use Data Pump Import to re-create data after restore and recovery.\n Logical backups are mostly beyond the scope of the backup and recovery\n documentation.\"\n describe 'A manual review is required to ensure recovery procedures and technical system features exist to ensure\n recovery is done in a secure and verifiable manner' do\n skip 'A manual review is required to ensure recovery procedures and technical system features exist to ensure\n recovery is done in a secure and verifiable manner'\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61765.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61689.rb", "line": 1 }, - "id": "V-61765" + "id": "V-61689" }, { - "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 take needed steps to protect data at rest and ensure\n confidentiality and integrity of application data.", + "desc": "This control is intended to address the confidentiality and integrity\n of information at rest in non-mobile devices and covers user information and\n system information. Information at rest refers to the state of information when\n it is located on a secondary storage device (e.g., disk drive, tape drive)\n within an organizational information system. Applications and application users\n generate information throughout the course of their application use.\n\n User-generated data and application specific configuration data both need\n to be protected. Configurations and/or rule sets for firewalls, gateways,\n intrusion detection/prevention systems, and filtering routers and authenticator\n content are examples of system information likely requiring protection.\n Organizations may choose to employ different mechanisms to achieve\n confidentiality and integrity protections, as appropriate.\n\n If the confidentiality and integrity of application data is not protected,\n the data will be open to compromise and unauthorized modification.", "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": "This control is intended to address the confidentiality and integrity\n of information at rest in non-mobile devices and covers user information and\n system information. Information at rest refers to the state of information when\n it is located on a secondary storage device (e.g., disk drive, tape drive)\n within an organizational information system. Applications and application users\n generate information throughout the course of their application use.\n\n User-generated data and application specific configuration data both need\n to be protected. Configurations and/or rule sets for firewalls, gateways,\n intrusion detection/prevention systems, and filtering routers and authenticator\n content are examples of system information likely requiring protection.\n Organizations may choose to employ different mechanisms to achieve\n confidentiality and integrity protections, as appropriate.\n\n If the confidentiality and integrity of application data is not protected,\n the data will be open to compromise and unauthorized modification." }, "impact": 0.5, - "refs": [ - { - "ref": [] - } - ], + "refs": [], "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-000231-DB-000154", + "gid": "V-61771", + "rid": "SV-76261r2_rule", + "stig_id": "O121-C2-018300", + "fix_id": "F-67687r1_fix", "cci": [ - "CCI-000044" + "CCI-001199" ], "nist": [ - "AC-7 a", + "SC-28", "Rev_4" ], "false_negatives": null, @@ -3714,35 +3810,35 @@ "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 the application owner and Authorizing Official have\n determined that encryption of data at rest is NOT required, this is not a\n finding.\n\n Review DBMS settings to determine whether controls exist to protect the\n confidentiality and integrity of data at rest in the database.\n\n If controls do not exist or are not enabled, this is a finding.\n\n To ensure that the appropriate controls are in place, discuss the precautions\n taken with the site Database Administrators and System Administrators and try\n to modify data at rest.\n\n Oracle recommends using Transparent Data Encryption to protect data.\n\n In order to check to see if the data is encrypted, for example, upon an\n auditor's request, Oracle provides views that document the encryption status of\n the database. For TDE column encryption, use the view 'dba_encrypted_columns',\n which lists the owner, table name, column name, encryption algorithm, and salt\n for all encrypted columns. For TDE tablespace encryption, the following SQL\n statement lists all encrypted tablespaces with their encryption algorithm and\n corresponding, encrypted, data files. Issue the following commands to check to\n see if the data at rest is encrypted.\n\n $ sqlplus connect as sysdba\n\n SQL> SELECT t.name \"TSName\",\n e.encryptionalg \"Algorithm\",\n d.file_name \"File Name\"\n FROM v$tablespace t,\n v$encrypted_tablespaces e,\n dba_data_files d\n WHERE t.ts# = e.ts#\n and t.name = d.tablespace_name;\n\n The next SQL statement lists the table owner, tables within encrypted\n tablespaces, and the encryption algorithm:\n\n SQL> SELECT a.owner \"Owner\",\n a.table_name \"Table Name\",\n e.encryptionalg \"Algorithm\"\n FROM dba_tables a,\n v$encrypted_tablespaces e\n WHERE a.tablespace_name in (select t.name from v$tablespace t,\n v$encrypted_tablespaces e where t.ts# = e.ts#);", + "fix": "Apply appropriate controls to protect the confidentiality and\n integrity of data at rest in the database.\n\n If no site-specific precautions are in place, use Oracle Advanced Security\n Option to encrypt data at rest.\n\n If ASO is not an option, use site-specific procedures to secure data at rest." }, - "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-61771' do\n title \"The DBMS must take needed steps to protect data at rest and ensure\n confidentiality and integrity of application data.\"\n desc \"This control is intended to address the confidentiality and integrity\n of information at rest in non-mobile devices and covers user information and\n system information. Information at rest refers to the state of information when\n it is located on a secondary storage device (e.g., disk drive, tape drive)\n within an organizational information system. Applications and application users\n generate information throughout the course of their application use.\n\n User-generated data and application specific configuration data both need\n to be protected. Configurations and/or rule sets for firewalls, gateways,\n intrusion detection/prevention systems, and filtering routers and authenticator\n content are examples of system information likely requiring protection.\n Organizations may choose to employ different mechanisms to achieve\n confidentiality and integrity protections, as appropriate.\n\n If the confidentiality and integrity of application data is not protected,\n the data will be open to compromise and unauthorized modification.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000231-DB-000154'\n tag \"gid\": 'V-61771'\n tag \"rid\": 'SV-76261r2_rule'\n tag \"stig_id\": 'O121-C2-018300'\n tag \"fix_id\": 'F-67687r1_fix'\n tag \"cci\": ['CCI-001199']\n tag \"nist\": ['SC-28', '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 application owner and Authorizing Official have\n determined that encryption of data at rest is NOT required, this is not a\n finding.\n\n Review DBMS settings to determine whether controls exist to protect the\n confidentiality and integrity of data at rest in the database.\n\n If controls do not exist or are not enabled, this is a finding.\n\n To ensure that the appropriate controls are in place, discuss the precautions\n taken with the site Database Administrators and System Administrators and try\n to modify data at rest.\n\n Oracle recommends using Transparent Data Encryption to protect data.\n\n In order to check to see if the data is encrypted, for example, upon an\n auditor's request, Oracle provides views that document the encryption status of\n the database. For TDE column encryption, use the view 'dba_encrypted_columns',\n which lists the owner, table name, column name, encryption algorithm, and salt\n for all encrypted columns. For TDE tablespace encryption, the following SQL\n statement lists all encrypted tablespaces with their encryption algorithm and\n corresponding, encrypted, data files. Issue the following commands to check to\n see if the data at rest is encrypted.\n\n $ sqlplus connect as sysdba\n\n SQL> SELECT t.name \\\"TSName\\\",\n e.encryptionalg \\\"Algorithm\\\",\n d.file_name \\\"File Name\\\"\n FROM v$tablespace t,\n v$encrypted_tablespaces e,\n dba_data_files d\n WHERE t.ts# = e.ts#\n and t.name = d.tablespace_name;\n\n The next SQL statement lists the table owner, tables within encrypted\n tablespaces, and the encryption algorithm:\n\n SQL> SELECT a.owner \\\"Owner\\\",\n a.table_name \\\"Table Name\\\",\n e.encryptionalg \\\"Algorithm\\\"\n FROM dba_tables a,\n v$encrypted_tablespaces e\n WHERE a.tablespace_name in (select t.name from v$tablespace t,\n v$encrypted_tablespaces e where t.ts# = e.ts#);\"\n tag \"fix\": \"Apply appropriate controls to protect the confidentiality and\n integrity of data at rest in the database.\n\n If no site-specific precautions are in place, use Oracle Advanced Security\n Option to encrypt data at rest.\n\n If ASO is not an option, use site-specific procedures to secure data at rest.\"\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\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61605.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61771.rb", "line": 1 }, - "id": "V-61605" + "id": "V-61771" }, { - "title": "The database must not be directly accessible from public or\n unauthorized networks.", - "desc": "Databases often store critical and/or sensitive information used by\n the organization. For this reason, databases are targeted for attacks by\n malicious users. Additional protections provided by network defenses that limit\n accessibility help protect the database and its data from unnecessary exposure\n and risk.", + "title": "The DBMS must employ automated mechanisms to alert security personnel\n of inappropriate or unusual activities with security implications.", + "desc": "Applications will typically utilize logging mechanisms for maintaining\n a historical log of activity that occurs within the application. This\n information can then be used for diagnostic purposes, forensics purposes, or\n other purposes relevant to ensuring the availability and integrity of the\n application.\n\n While it is important to log events identified as being critical and\n relevant to security, it is equally important to notify the appropriate\n personnel in a timely manner, so they are able to respond to events as they\n occur.\n\n Solutions that include a manual notification procedure do not offer the\n reliability and speed of an automated notification solution. Applications must\n employ automated mechanisms to alert security personnel of inappropriate or\n unusual activities that have security implications. If this capability is not\n built directly into the application, the application must be able to integrate\n with existing security infrastructure that provides this capability.\n\n Database management systems that do not automatically alert security\n personnel of unusual activities run the risk of security incidents going\n unnoticed for long periods of time. This can allow security breaches to be\n ongoing and more serious.", "descriptions": { - "default": "Databases often store critical and/or sensitive information used by\n the organization. For this reason, databases are targeted for attacks by\n malicious users. Additional protections provided by network defenses that limit\n accessibility help protect the database and its data from unnecessary exposure\n and risk." + "default": "Applications will typically utilize logging mechanisms for maintaining\n a historical log of activity that occurs within the application. This\n information can then be used for diagnostic purposes, forensics purposes, or\n other purposes relevant to ensuring the availability and integrity of the\n application.\n\n While it is important to log events identified as being critical and\n relevant to security, it is equally important to notify the appropriate\n personnel in a timely manner, so they are able to respond to events as they\n occur.\n\n Solutions that include a manual notification procedure do not offer the\n reliability and speed of an automated notification solution. Applications must\n employ automated mechanisms to alert security personnel of inappropriate or\n unusual activities that have security implications. If this capability is not\n built directly into the application, the application must be able to integrate\n with existing security infrastructure that provides this capability.\n\n Database management systems that do not automatically alert security\n personnel of unusual activities run the risk of security incidents going\n unnoticed for long periods of time. This can allow security breaches to be\n ongoing and more serious." }, "impact": 0.5, "refs": [], "tags": { - "gtitle": "SRG-APP-000516-DB-999900", - "gid": "V-61495", - "rid": "SV-75985r1_rule", - "stig_id": "O121-BP-024500", - "fix_id": "F-67411r1_fix", + "gtitle": "SRG-APP-000237-DB-000158", + "gid": "V-61779", + "rid": "SV-76269r1_rule", + "stig_id": "O121-C2-018800", + "fix_id": "F-67695r1_fix", "cci": [ - "CCI-000366" + "CCI-001274" ], "nist": [ - "CM-6 b", + "SI-4 (12)", "Rev_4" ], "false_negatives": null, @@ -3755,30 +3851,30 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Review the System Security Plan to determine if the DBMS serves\n data to users or applications outside the local enclave.\n\n If the DBMS is not accessed outside of the local enclave, this check is not a\n finding.\n\n If the DBMS serves applications available from a public network (e.g. the\n Internet), then confirm that the application servers are located in a DMZ.\n\n If the DBMS is located inside the local enclave and is directly accessible to\n public users, this is a finding.\n\n If the DBMS serves public-facing applications and is not protected from direct\n client connections and unauthorized networks, this is a finding.\n\n If the DBMS serves public-facing applications and contains sensitive or\n classified information, this is a finding.", - "fix": "Do not allow direct connections from users originating from the\n Internet or other public network to the DBMS.\n\n Include in the System Security Plan for the system whether the DBMS serves\n public-facing applications or applications serving users from other untrusted\n networks.\n\n Do not store sensitive or classified data on a DBMS server that serves\n public-facing applications." + "check": "Check DBMS settings to determine whether security personnel are\n alerted automatically when unusual or security-related activities (threats\n identified by authoritative sources (e.g., CTOs) and IAW with CJCSM 6510.01A)\n are detected on the database.\n\n If security personnel are not automatically alerted, this is a finding.", + "fix": "Configure database to automatically alert security personnel of\n inappropriate or unusual activities with security implications.\n\n Oracle provides this capability with the Audit Vault. Install and configure\n Oracle Audit Vault if it is available.\n\n If Audit Vault is not available, implement custom code or deploy a third-party\n product to satisfy this requirement." }, - "code": "control 'V-61495' do\n title \"The database must not be directly accessible from public or\n unauthorized networks.\"\n desc \"Databases often store critical and/or sensitive information used by\n the organization. For this reason, databases are targeted for attacks by\n malicious users. Additional protections provided by network defenses that limit\n accessibility help protect the database and its data from unnecessary exposure\n and risk.\"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000516-DB-999900'\n tag \"gid\": 'V-61495'\n tag \"rid\": 'SV-75985r1_rule'\n tag \"stig_id\": 'O121-BP-024500'\n tag \"fix_id\": 'F-67411r1_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 System Security Plan to determine if the DBMS serves\n data to users or applications outside the local enclave.\n\n If the DBMS is not accessed outside of the local enclave, this check is not a\n finding.\n\n If the DBMS serves applications available from a public network (e.g. the\n Internet), then confirm that the application servers are located in a DMZ.\n\n If the DBMS is located inside the local enclave and is directly accessible to\n public users, this is a finding.\n\n If the DBMS serves public-facing applications and is not protected from direct\n client connections and unauthorized networks, this is a finding.\n\n If the DBMS serves public-facing applications and contains sensitive or\n classified information, this is a finding.\"\n tag \"fix\": \"Do not allow direct connections from users originating from the\n Internet or other public network to the DBMS.\n\n Include in the System Security Plan for the system whether the DBMS serves\n public-facing applications or applications serving users from other untrusted\n networks.\n\n Do not store sensitive or classified data on a DBMS server that serves\n public-facing applications.\"\n describe 'A manual review is required to ensure the database is not directly accessible from public or\n unauthorized networks.' do\n skip 'A manual review is required to ensure the database is not directly accessible from public or\n unauthorized networks.'\n end\nend\n", + "code": "control 'V-61779' do\n title \"The DBMS must employ automated mechanisms to alert security personnel\n of inappropriate or unusual activities with security implications.\"\n desc \"Applications will typically utilize logging mechanisms for maintaining\n a historical log of activity that occurs within the application. This\n information can then be used for diagnostic purposes, forensics purposes, or\n other purposes relevant to ensuring the availability and integrity of the\n application.\n\n While it is important to log events identified as being critical and\n relevant to security, it is equally important to notify the appropriate\n personnel in a timely manner, so they are able to respond to events as they\n occur.\n\n Solutions that include a manual notification procedure do not offer the\n reliability and speed of an automated notification solution. Applications must\n employ automated mechanisms to alert security personnel of inappropriate or\n unusual activities that have security implications. If this capability is not\n built directly into the application, the application must be able to integrate\n with existing security infrastructure that provides this capability.\n\n Database management systems that do not automatically alert security\n personnel of unusual activities run the risk of security incidents going\n unnoticed for long periods of time. This can allow security breaches to be\n ongoing and more serious.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000237-DB-000158'\n tag \"gid\": 'V-61779'\n tag \"rid\": 'SV-76269r1_rule'\n tag \"stig_id\": 'O121-C2-018800'\n tag \"fix_id\": 'F-67695r1_fix'\n tag \"cci\": ['CCI-001274']\n tag \"nist\": ['SI-4 (12)', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Check DBMS settings to determine whether security personnel are\n alerted automatically when unusual or security-related activities (threats\n identified by authoritative sources (e.g., CTOs) and IAW with CJCSM 6510.01A)\n are detected on the database.\n\n If security personnel are not automatically alerted, this is a finding.\"\n tag \"fix\": \"Configure database to automatically alert security personnel of\n inappropriate or unusual activities with security implications.\n\n Oracle provides this capability with the Audit Vault. Install and configure\n Oracle Audit Vault if it is available.\n\n If Audit Vault is not available, implement custom code or deploy a third-party\n product to satisfy this requirement.\"\n describe 'A manual review is required to ensure the DBMS employs automated mechanisms to alert security personnel\n of inappropriate or unusual activities with security implications' do\n skip 'A manual review is required to ensure the DBMS employs automated mechanisms to alert security personnel\n of inappropriate or unusual activities with security implications'\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61495.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61779.rb", "line": 1 }, - "id": "V-61495" + "id": "V-61779" }, { - "title": "The Oracle SQL92_SECURITY parameter must be set to TRUE.", - "desc": "The configuration option SQL92_SECURITY specifies whether table-level\n SELECT privileges are required to execute an update or delete that references\n table column values. If this option is disabled (set to FALSE), the UPDATE\n privilege can be used to determine values that should require SELECT privileges.\n\n The SQL92_SECURITY setting of TRUE prevents the exploitation of user\n credentials with only DELETE or UPDATE privileges on a table from being able to\n derive column values in that table by performing a series of update/delete\n statements using a where clause, and rolling back the change. In the following\n example, with SQL92_SECURITY set to FALSE, a user with only delete privilege on\n the scott.emp table is able to derive that there is one employee with a salary\n greater than 3000. With SQL92_SECURITY set to TRUE, that user is prevented from\n attempting to derive a value.\n\n SQL92_SECURITY = FALSE\n SQL> delete from scott.emp where sal > 3000;\n 1 row deleted\n SQL> rollback;\n Rollback complete\n\n SQL92_SECURITY = TRUE\n SQL> delete from scott.emp where sal > 3000;\n delete from scott.emp where sal > 3000\n *\n ERROR at line 1:\n ORA-01031: insufficient privileges", + "title": "System privileges granted using the WITH ADMIN OPTION must not be\n granted to unauthorized user accounts.", + "desc": "The WITH ADMIN OPTION allows the grantee to grant a privilege to\n another database account. Best security practice restricts the privilege of\n assigning privileges to authorized personnel. Authorized personnel include\n DBAs, object owners, and, where designed and included in the application's\n functions, application administrators. Restricting privilege-granting functions\n to authorized accounts can help decrease mismanagement of privileges and\n wrongful assignments to unauthorized accounts.", "descriptions": { - "default": "The configuration option SQL92_SECURITY specifies whether table-level\n SELECT privileges are required to execute an update or delete that references\n table column values. If this option is disabled (set to FALSE), the UPDATE\n privilege can be used to determine values that should require SELECT privileges.\n\n The SQL92_SECURITY setting of TRUE prevents the exploitation of user\n credentials with only DELETE or UPDATE privileges on a table from being able to\n derive column values in that table by performing a series of update/delete\n statements using a where clause, and rolling back the change. In the following\n example, with SQL92_SECURITY set to FALSE, a user with only delete privilege on\n the scott.emp table is able to derive that there is one employee with a salary\n greater than 3000. With SQL92_SECURITY set to TRUE, that user is prevented from\n attempting to derive a value.\n\n SQL92_SECURITY = FALSE\n SQL> delete from scott.emp where sal > 3000;\n 1 row deleted\n SQL> rollback;\n Rollback complete\n\n SQL92_SECURITY = TRUE\n SQL> delete from scott.emp where sal > 3000;\n delete from scott.emp where sal > 3000\n *\n ERROR at line 1:\n ORA-01031: insufficient privileges" + "default": "The WITH ADMIN OPTION allows the grantee to grant a privilege to\n another database account. Best security practice restricts the privilege of\n assigning privileges to authorized personnel. Authorized personnel include\n DBAs, object owners, and, where designed and included in the application's\n functions, application administrators. Restricting privilege-granting functions\n to authorized accounts can help decrease mismanagement of privileges and\n wrongful assignments to unauthorized accounts." }, - "impact": 0.5, + "impact": 0, "refs": [], "tags": { "gtitle": "SRG-APP-000516-DB-999900", - "gid": "V-61429", - "rid": "SV-75919r1_rule", - "stig_id": "O121-BP-022100", - "fix_id": "F-67345r1_fix", + "gid": "V-61433", + "rid": "SV-75923r3_rule", + "stig_id": "O121-BP-022300", + "fix_id": "F-67349r1_fix", "cci": [ "CCI-000366" ], @@ -3796,39 +3892,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "From SQL*Plus:\n\n select value from v$parameter where name = 'sql92_security';\n\n If the value returned is set to FALSE, this is a finding.\n\n If the parameter is set to TRUE or does not exist, this is not a finding.", - "fix": "Enable SQL92 security.\n\n From SQL*Plus:\n\n alter system set sql92_security = TRUE scope = spfile;\n\n The above SQL*Plus command will set the parameter to take effect at next system\n startup." + "check": "A default Oracle Database installation provides a set of\n predefined administrative accounts and non-administrative accounts. These are\n accounts that have special privileges required to administer areas of the\n database, such as the CREATE ANY TABLE or ALTER SESSION privilege, or EXECUTE\n privileges on packages owned by the SYS schema. The default tablespace for\n administrative accounts is either SYSTEM or SYSAUX. Non-administrative user\n accounts only have the minimum privileges needed to perform their jobs. Their\n default tablespace is USERS.\n\n To protect these accounts from unauthorized access, the installation process\n expires and locks most of these accounts, except where noted below. The\n database administrator is responsible for unlocking and resetting these\n accounts, as required.\n\n Non-Administrative Accounts - Expired and locked:\n APEX_PUBLIC_USER, DIP, FLOWS_040100*, FLOWS_FILES, MDDATA, ORACLE_OCM,\n SPATIAL_CSW_ADMIN_USR, SPATIAL_WFS_ADMIN_USR, XS$NULL\n\n Administrative Accounts - Expired and Locked:\n ANONYMOUS, CTXSTS, EXFSYS, LBACSYS, MDSYS, OLAPSYS, OEDDATA, OWBSYS,\n ORDPLUGINS, ORDSYS, OUTLN, SI_INFORMTN_SCHEMA, WK_TEST, WK_SYS, WKPROXY, WMSYS,\n XDB\n\n Administrative Accounts - Open:\n DBSNMP, MGMT_VIEW, SYS, SYSMAN, SYSTEM, SYSKM\n\n * Subject to change based on version installed\n\n Run the SQL query:\n\n From SQL*Plus:\n select grantee, privilege from dba_sys_privs\n where grantee not in ()\n and admin_option = 'YES'\n and grantee not in\n (select grantee from dba_role_privs where granted_role = 'DBA');\n\n (With respect to the list of special accounts that are excluded from this\n requirement, it is expected that the DBA will maintain the list to suit local\n circumstances, adding special accounts as necessary and removing any that are\n not supposed to be in use in the Oracle deployment that is under review.)\n\n If any accounts that are not authorized to have the ADMIN OPTION are listed,\n this is a finding.", + "fix": "Revoke assignment of privileges with the WITH ADMIN OPTION from\n unauthorized users and re-grant them without the option.\n\n From SQL*Plus:\n\n revoke [privilege name] from user [username];\n\n Replace [privilege name] with the named privilege and [username] with the named\n user.\n\n Restrict use of the WITH ADMIN OPTION to authorized administrators.\n\n Document authorized privilege assignments with the WITH ADMIN OPTION in the\n System Security Plan." }, - "code": "control 'V-61429' do\n title 'The Oracle SQL92_SECURITY parameter must be set to TRUE.'\n desc \"The configuration option SQL92_SECURITY specifies whether table-level\n SELECT privileges are required to execute an update or delete that references\n table column values. If this option is disabled (set to FALSE), the UPDATE\n privilege can be used to determine values that should require SELECT privileges.\n\n The SQL92_SECURITY setting of TRUE prevents the exploitation of user\n credentials with only DELETE or UPDATE privileges on a table from being able to\n derive column values in that table by performing a series of update/delete\n statements using a where clause, and rolling back the change. In the following\n example, with SQL92_SECURITY set to FALSE, a user with only delete privilege on\n the scott.emp table is able to derive that there is one employee with a salary\n greater than 3000. With SQL92_SECURITY set to TRUE, that user is prevented from\n attempting to derive a value.\n\n SQL92_SECURITY = FALSE\n SQL> delete from scott.emp where sal > 3000;\n 1 row deleted\n SQL> rollback;\n Rollback complete\n\n SQL92_SECURITY = TRUE\n SQL> delete from scott.emp where sal > 3000;\n delete from scott.emp where sal > 3000\n *\n ERROR at line 1:\n ORA-01031: insufficient privileges\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000516-DB-999900'\n tag \"gid\": 'V-61429'\n tag \"rid\": 'SV-75919r1_rule'\n tag \"stig_id\": 'O121-BP-022100'\n tag \"fix_id\": 'F-67345r1_fix'\n tag \"cci\": ['CCI-000366']\n tag \"nist\": ['CM-6 b', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"From SQL*Plus:\n\n select value from v$parameter where name = 'sql92_security';\n\n If the value returned is set to FALSE, this is a finding.\n\n If the parameter is set to TRUE or does not exist, this is not a finding.\"\n tag \"fix\": \"Enable SQL92 security.\n\n From SQL*Plus:\n\n alter system set sql92_security = TRUE scope = spfile;\n\n The above SQL*Plus command will set the parameter to take effect at next system\n startup.\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n parameter = sql.query(\"select value from v$parameter where name = 'sql92_security';\").column('value')\n\n describe 'The oracle database SQL92_SECURITY parameter' do\n subject { parameter }\n it { should cmp 'TRUE' }\n end\nend\n", + "code": "control 'V-61433' do\n title \"System privileges granted using the WITH ADMIN OPTION must not be\n granted to unauthorized user accounts.\"\n desc \"The WITH ADMIN OPTION allows the grantee to grant a privilege to\n another database account. Best security practice restricts the privilege of\n assigning privileges to authorized personnel. Authorized personnel include\n DBAs, object owners, and, where designed and included in the application's\n functions, application administrators. Restricting privilege-granting functions\n to authorized accounts can help decrease mismanagement of privileges and\n wrongful assignments to unauthorized accounts.\"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000516-DB-999900'\n tag \"gid\": 'V-61433'\n tag \"rid\": 'SV-75923r3_rule'\n tag \"stig_id\": 'O121-BP-022300'\n tag \"fix_id\": 'F-67349r1_fix'\n tag \"cci\": ['CCI-000366']\n tag \"nist\": ['CM-6 b', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"A default Oracle Database installation provides a set of\n predefined administrative accounts and non-administrative accounts. These are\n accounts that have special privileges required to administer areas of the\n database, such as the CREATE ANY TABLE or ALTER SESSION privilege, or EXECUTE\n privileges on packages owned by the SYS schema. The default tablespace for\n administrative accounts is either SYSTEM or SYSAUX. Non-administrative user\n accounts only have the minimum privileges needed to perform their jobs. Their\n default tablespace is USERS.\n\n To protect these accounts from unauthorized access, the installation process\n expires and locks most of these accounts, except where noted below. The\n database administrator is responsible for unlocking and resetting these\n accounts, as required.\n\n Non-Administrative Accounts - Expired and locked:\n APEX_PUBLIC_USER, DIP, FLOWS_040100*, FLOWS_FILES, MDDATA, ORACLE_OCM,\n SPATIAL_CSW_ADMIN_USR, SPATIAL_WFS_ADMIN_USR, XS$NULL\n\n Administrative Accounts - Expired and Locked:\n ANONYMOUS, CTXSTS, EXFSYS, LBACSYS, MDSYS, OLAPSYS, OEDDATA, OWBSYS,\n ORDPLUGINS, ORDSYS, OUTLN, SI_INFORMTN_SCHEMA, WK_TEST, WK_SYS, WKPROXY, WMSYS,\n XDB\n\n Administrative Accounts - Open:\n DBSNMP, MGMT_VIEW, SYS, SYSMAN, SYSTEM, SYSKM\n\n * Subject to change based on version installed\n\n Run the SQL query:\n\n From SQL*Plus:\n select grantee, privilege from dba_sys_privs\n where grantee not in ()\n and admin_option = 'YES'\n and grantee not in\n (select grantee from dba_role_privs where granted_role = 'DBA');\n\n (With respect to the list of special accounts that are excluded from this\n requirement, it is expected that the DBA will maintain the list to suit local\n circumstances, adding special accounts as necessary and removing any that are\n not supposed to be in use in the Oracle deployment that is under review.)\n\n If any accounts that are not authorized to have the ADMIN OPTION are listed,\n this is a finding.\"\n tag \"fix\": \"Revoke assignment of privileges with the WITH ADMIN OPTION from\n unauthorized users and re-grant them without the option.\n\n From SQL*Plus:\n\n revoke [privilege name] from user [username];\n\n Replace [privilege name] with the named privilege and [username] with the named\n user.\n\n Restrict use of the WITH ADMIN OPTION to authorized administrators.\n\n Document authorized privilege assignments with the WITH ADMIN OPTION in the\n System Security Plan.\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n dba_users = sql.query(\"select grantee from dba_sys_privs\n where admin_option = 'YES' and grantee not in (select grantee from dba_role_privs where granted_role = 'DBA');\").column('grantee').uniq\n if dba_users.empty?\n impact 0.0\n describe 'There are no oracle DBA users, control N/A' do\n skip 'There are no oracle DBA users, control N/A'\n end\n else\n dba_users.each do |user|\n describe \"oracle DBA users: #{user}\" do\n subject { user }\n it { should be_in input('allowed_dbadmin_users') }\n end\n end\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61429.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61433.rb", "line": 1 }, - "id": "V-61429" + "id": "V-61433" }, { - "title": "The DBMS must verify account lockouts persist until reset by an\n administrator.", - "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 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": "Database recovery procedures must be developed, documented,\n implemented, and periodically tested.", + "desc": "Information system backup is a critical step in maintaining data\n assurance and availability.\n\n User-level information is data generated by information system and/or\n application users. In order to assure availability of this data in the event of\n a system failure, DoD organizations are required to ensure user-generated data\n is backed up at a defined frequency. This includes data stored on file\n systems, within databases or within any other storage media.\n\n Applications performing backups must be capable of backing up user-level\n information per the DoD-defined frequency.\n\n Problems with backup procedures or backup media may not be discovered until\n after a recovery is needed. Testing and verification of procedures provides the\n opportunity to discover oversights, conflicts, or other issues in the backup\n procedures or use of media designed to be used.", "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 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": [ - { - "ref": [] - } - ], + "default": "Information system backup is a critical step in maintaining data\n assurance and availability.\n\n User-level information is data generated by information system and/or\n application users. In order to assure availability of this data in the event of\n a system failure, DoD organizations are required to ensure user-generated data\n is backed up at a defined frequency. This includes data stored on file\n systems, within databases or within any other storage media.\n\n Applications performing backups must be capable of backing up user-level\n information per the DoD-defined frequency.\n\n Problems with backup procedures or backup media may not be discovered until\n after a recovery is needed. Testing and verification of procedures provides the\n opportunity to discover oversights, conflicts, or other issues in the backup\n procedures or use of media designed to be used." + }, + "impact": 0.5, + "refs": [], "tags": { - "gtitle": "SRG-APP-000065-DB-000024", - "gid": "V-61603", - "rid": "SV-76093r2_rule", - "stig_id": "O121-C2-004900", - "fix_id": "F-67519r1_fix", + "gtitle": "SRG-APP-000145-DB-000097", + "gid": "V-61697", + "rid": "SV-76187r1_rule", + "stig_id": "O121-C2-012400", + "fix_id": "F-67613r1_fix", "cci": [ - "CCI-002236" + "CCI-000535" ], "nist": [ - "AC-7 b", + "CP-9 (a)", "Rev_4" ], "false_negatives": null, @@ -3841,39 +3933,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "The account lockout duration is defined in the profile assigned\n to a user.\n \n To see what profile is assigned to a user, enter the query:\n \n SQL>SELECT profile FROM dba_users WHERE username = ''\n \n This will return the profile name assigned to that user.\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 Now check the values assigned to the profile returned from the query above:\n \n column profile format a20\n column limit format a20\n SQL>SELECT PROFILE, RESOURCE_NAME, LIMIT FROM DBA_PROFILES WHERE PROFILE =\n 'ORA_STIG_PROFILE';\n \n Check the settings for password_lock_time - this specifies how long to lock the\n account after the number of consecutive failed logon attempts reaches the\n limit. If the value is not UNLIMITED, this is a finding.", - "fix": "Configure the DBMS settings to specify indefinite lockout\n duration:\n ALTER PROFILE ORA_STIG_PROFILE LIMIT PASSWORD_LOCK_TIME UNLIMITED;" + "check": "Review the testing and verification procedures documented in\n the system documentation. Review evidence of implementation of testing and\n verification procedures by reviewing logs from backup and recovery\n implementation. Logs may be in electronic form or hardcopy and may include\n email or other notification.\n\n If testing and verification of backup and recovery procedures is not documented\n in the system documentation, this is a finding.\n\n If evidence of testing and verification of backup and recovery procedures does\n not exist, this is a finding.", + "fix": "Develop, document, and implement testing and verification\n procedures for database backup and recovery. Include requirements for\n documenting database backup and recovery testing and verification activities in\n the procedures." }, - "code": " control 'V-61603' do\n title \"The DBMS must verify account lockouts persist until reset by an\n administrator.\"\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 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-000065-DB-000024'\n tag \"gid\": 'V-61603'\n tag \"rid\": 'SV-76093r2_rule'\n tag \"stig_id\": 'O121-C2-004900'\n tag \"fix_id\": 'F-67519r1_fix'\n tag \"cci\": ['CCI-002236']\n tag \"nist\": ['AC-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\": \"The account lockout duration is defined in the profile assigned\n to a user.\n \n To see what profile is assigned to a user, enter the query:\n \n SQL>SELECT profile FROM dba_users WHERE username = ''\n \n This will return the profile name assigned to that user.\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 Now check the values assigned to the profile returned from the query above:\n \n column profile format a20\n column limit format a20\n SQL>SELECT PROFILE, RESOURCE_NAME, LIMIT FROM DBA_PROFILES WHERE PROFILE =\n 'ORA_STIG_PROFILE';\n \n Check the settings for password_lock_time - this specifies how long to lock the\n account after the number of consecutive failed logon attempts reaches the\n limit. If the value is not UNLIMITED, this is a finding.\"\n tag \"fix\": \"Configure the DBMS settings to specify indefinite lockout\n duration:\n ALTER PROFILE ORA_STIG_PROFILE LIMIT PASSWORD_LOCK_TIME UNLIMITED;\"\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_LOCK_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_lock_time = sql.query(format(query, profile: profile)).column('limit')\n \n describe \"The oracle database account password lock time for profile: #{profile}\" do\n subject { password_lock_time }\n it { should 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\n end\n", + "code": "control 'V-61697' do\n title \"Database recovery procedures must be developed, documented,\n implemented, and periodically tested.\"\n desc \"Information system backup is a critical step in maintaining data\n assurance and availability.\n\n User-level information is data generated by information system and/or\n application users. In order to assure availability of this data in the event of\n a system failure, DoD organizations are required to ensure user-generated data\n is backed up at a defined frequency. This includes data stored on file\n systems, within databases or within any other storage media.\n\n Applications performing backups must be capable of backing up user-level\n information per the DoD-defined frequency.\n\n Problems with backup procedures or backup media may not be discovered until\n after a recovery is needed. Testing and verification of procedures provides the\n opportunity to discover oversights, conflicts, or other issues in the backup\n procedures or use of media designed to be used.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000145-DB-000097'\n tag \"gid\": 'V-61697'\n tag \"rid\": 'SV-76187r1_rule'\n tag \"stig_id\": 'O121-C2-012400'\n tag \"fix_id\": 'F-67613r1_fix'\n tag \"cci\": ['CCI-000535']\n tag \"nist\": ['CP-9 (a)', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Review the testing and verification procedures documented in\n the system documentation. Review evidence of implementation of testing and\n verification procedures by reviewing logs from backup and recovery\n implementation. Logs may be in electronic form or hardcopy and may include\n email or other notification.\n\n If testing and verification of backup and recovery procedures is not documented\n in the system documentation, this is a finding.\n\n If evidence of testing and verification of backup and recovery procedures does\n not exist, this is a finding.\"\n tag \"fix\": \"Develop, document, and implement testing and verification\n procedures for database backup and recovery. Include requirements for\n documenting database backup and recovery testing and verification activities in\n the procedures.\"\n describe 'A manual review is required to ensure database recovery procedures are developed, documented,\n implemented, and periodically tested' do\n skip 'A manual review is required to ensure database recovery procedures are developed, documented,\n implemented, and periodically tested'\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61603.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61697.rb", "line": 1 }, - "id": "V-61603" + "id": "V-61697" }, { - "title": "Access to external executables must be disabled or restricted.", - "desc": "The Oracle external procedure capability provides use of the Oracle\n process account outside the operation of the DBMS process. You can use it to\n submit and execute applications stored externally from the database under\n operating system controls. The external procedure process is the subject of\n frequent and successful attacks as it allows unauthenticated use of the Oracle\n process account on the operating system. As of Oracle version 11.1, the\n external procedure agent may be run directly from the database and not require\n use of the Oracle listener. This reduces the risk of unauthorized access to the\n procedure from outside of the database process.", + "title": "DBMS backup and restoration files must be protected from unauthorized\n access.", + "desc": "Information system backup is a critical step in maintaining data\n assurance and availability.\n\n User-level information is data generated by information system and/or\n application users. In order to assure availability of this data in the event of\n a system failure, DoD organizations are required to ensure user-generated data\n is backed up at a defined frequency. This includes data stored on file systems,\n within databases or within any other storage media.\n\n Applications performing backups must be capable of backing up user-level\n information per the DoD-defined frequency.\n\n Lost or compromised DBMS backup and restoration files may lead to not only\n the loss of data, but also the unauthorized access to sensitive data. Backup\n files need the same protections against unauthorized access when stored on\n backup media as when online and actively in use by the database system. In\n addition, the backup media needs to be protected against physical loss. Most\n DBMS's maintain online copies of critical control files to provide transparent\n or easy recovery from hard disk loss or other interruptions to database\n operation.", "descriptions": { - "default": "The Oracle external procedure capability provides use of the Oracle\n process account outside the operation of the DBMS process. You can use it to\n submit and execute applications stored externally from the database under\n operating system controls. The external procedure process is the subject of\n frequent and successful attacks as it allows unauthenticated use of the Oracle\n process account on the operating system. As of Oracle version 11.1, the\n external procedure agent may be run directly from the database and not require\n use of the Oracle listener. This reduces the risk of unauthorized access to the\n procedure from outside of the database process." + "default": "Information system backup is a critical step in maintaining data\n assurance and availability.\n\n User-level information is data generated by information system and/or\n application users. In order to assure availability of this data in the event of\n a system failure, DoD organizations are required to ensure user-generated data\n is backed up at a defined frequency. This includes data stored on file systems,\n within databases or within any other storage media.\n\n Applications performing backups must be capable of backing up user-level\n information per the DoD-defined frequency.\n\n Lost or compromised DBMS backup and restoration files may lead to not only\n the loss of data, but also the unauthorized access to sensitive data. Backup\n files need the same protections against unauthorized access when stored on\n backup media as when online and actively in use by the database system. In\n addition, the backup media needs to be protected against physical loss. Most\n DBMS's maintain online copies of critical control files to provide transparent\n or easy recovery from hard disk loss or other interruptions to database\n operation." }, - "impact": 0, - "refs": [ - { - "ref": [] - } - ], + "impact": 0.5, + "refs": [], "tags": { - "gtitle": "SRG-APP-000141-DB-000093", - "gid": "V-61685", - "rid": "SV-76175r2_rule", - "stig_id": "O121-C2-011810", - "fix_id": "F-67599r1_fix", + "gtitle": "SRG-APP-000145-DB-000098", + "gid": "V-61699", + "rid": "SV-76189r1_rule", + "stig_id": "O121-C2-012500", + "fix_id": "F-67615r1_fix", "cci": [ - "CCI-000381" + "CCI-000535" ], "nist": [ - "CM-7 a", + "CP-9 (a)", "Rev_4" ], "false_negatives": null, @@ -3886,35 +3974,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Review the System Security Plan to determine if the use of the\n external procedure agent is authorized.\n\n Review the ORACLE_HOME/bin directory or search the ORACLE_BASE path for the\n executable extproc (UNIX) or extproc.exe (Windows).\n\n If external procedure agent is not authorized for use in the System Security\n Plan and the executable file does not exist or is restricted, this is not a\n finding.\n\n If external procedure agent is not authorized for use in the System Security\n Plan and the executable file exists and is not restricted, this is a finding.\n\n If use of the external procedure agent is authorized, ensure extproc is\n restricted to execution of authorized applications.\n\n External jobs are run using the account nobody by default.\n\n Review the contents of the file ORACLE_HOME/rdbms/admin/externaljob.ora for the\n lines run_user= and run_group=.\n\n If the user assigned to these parameters is not \"nobody\", this is a finding.\n\n For versions 11.1 and later, the external procedure agent (extproc executable)\n is available directly from the database and does not require definition in the\n listener.ora file for use.\n\n Review the contents of the file ORACLE_HOME/hs/admin/extproc.ora.\n\n If the file does not exist, this is a finding.\n\n If the following entry does not appear in the file, this is a finding:\n\n EXTPROC_DLLS=ONLY:[dll full file name1]:[dll full file name2]:..\n\n [dll full file name] represents a full path and file name.\n\n This list of file names is separated by \":\".\n\n Note: If \"ONLY\" is specified, then the list is restricted to allow execution\n of only the DLLs specified in the list and is not a finding. If \"ANY\" is\n specified, then there are no restrictions for execution except what is\n controlled by operating system permissions and is a finding. If no\n specification is made, any files located in the %ORACLE_HOME%\\bin directory on\n Windows systems or $ORACLE_HOME/lib directory on UNIX systems can be executed\n (the default) and is a finding.\n\n Ensure that EXTPROC is not accessible from the listener.\n\n Review the listener.ora file. If any entries reference \"extproc\", this is a\n finding.\n\n Determine if the external procedure agent is in use per Oracle 10.x conventions.\n\n Review the listener.ora file.\n\n If any entries reference \"extproc\", then the agent is in use.\n\n If external procedure agent is not authorized for use in the System Security\n Plan and references to \"extproc\" exist, this is a finding.\n\n Sample listener.ora entries with extproc included:\n\n LISTENER =\n (DESCRIPTION =\n (ADDRESS = (PROTOCOL = TCP)(HOST = 127.0.0.1)(PORT = 1521))\n )\n EXTLSNR =\n (DESCRIPTION =\n (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC))\n )\n SID_LIST_LISTENER =\n (SID_LIST =\n (SID_DESC =\n (GLOBAL_DBNAME = ORCL)\n (ORACLE_HOME = /home/oracle/app/oracle/product/11.1.0/db_1)\n (SID_NAME = ORCL)\n )\n )\n SID_LIST_EXTLSNR =\n (SID_LIST =\n (SID_DESC =\n (PROGRAM = extproc)\n (SID_NAME = PLSExtProc)\n (ORACLE_HOME = /home/oracle/app/oracle/product/11.1.0/db_1)\n (ENVS=\"EXTPROC_DLLS=ONLY:/home/app1/app1lib.so:/home/app2/app2lib.so,\n LD_LIBRARY_PATH=/private/app2/lib:/private/app1,\n MYPATH=/usr/fso:/usr/local/packages\")\n )\n )\n\n Sample tnsnames.ora entries with extproc included:\n\n ORCL =\n (DESCRIPTION =\n (ADDRESS_LIST =\n (ADDRESS = (PROTOCOL = TCP)(HOST = 127.0.0.1)(PORT = 1521))\n )\n (CONNECT_DATA =\n (SERVICE_NAME = ORCL)\n )\n )\n EXTPROC_CONNECTION_DATA =\n (DESCRIPTION =\n (ADDRESS_LIST =\n (ADDRESS = (PROTOCOL = IPC)(KEY = extproc))\n )\n (CONNECT_DATA =\n (SERVER = DEDICATED)\n (SERVICE_NAME = PLSExtProc)\n )\n )\n\n If EXTPROC is in use, confirm that a listener is dedicated to serving the\n external procedure agent (as shown above).\n\n View the protocols configured for the listener.\n\n For the listener to be dedicated, the only entries will be to specify extproc.\n\n If there is not a dedicated listener in use for the external procedure agent,\n this is a finding.\n\n If the PROTOCOL= specified is other than IPC, this is a finding.\n\n Verify and ensure extproc is restricted executing authorized external\n applications only and extproc is restricted to execution of authorized\n applications.\n\n Review the listener.ora file.\n\n If the following entry does not exist, this is a finding:\n\n EXTPROC_DLLS=ONLY:[dll full file name1]:[dll full file name2]:...\n\n Note: [dll full file name] represents a full path and file name. This list of\n file names is separated by \":\".\n\n Note: If \"ONLY\" is specified, then the list is restricted to allow execution\n of only the DLLs specified in the list and is not a finding. If \"ANY\" is\n specified, then there are no restrictions for execution except what is\n controlled by operating system permissions and is a finding. If no\n specification is made, any files located in the %ORACLE_HOME%\\bin directory on\n Windows systems or $ORACLE_HOME/lib directory on UNIX systems can be executed\n (the default) and is a finding.\n\n View the listener.ora file (usually in ORACLE_HOME/network/admin or directory\n specified by the TNS_ADMIN environment variable).\n\n If multiple listener processes are running, then the listener.ora file for each\n must be viewed.\n\n For each process, determine the directory specified in the ORACLE_HOME or\n TNS_ADMIN environment variable defined for the process account to locate the\n listener.ora file.", - "fix": "If use of the external procedure agent is required, then\n authorize and document the requirement in the System Security Plan.\n\n If the external procedure agent must be accessible to the Oracle listener, then\n specify this and authorize it in the System Security Plan.\n\n If use of the Oracle External Procedure agent is not required:\n\n - Stop the Oracle Listener process\n - Remove all references to extproc in the listener.ora and tnsnames.ora files\n - Alter the permissions on the executable files:\n UNIX - Remove read/write/execute permissions from owner, group and\n world\n Windows - Remove Groups/Users from the executable (except groups\n SYSTEM and ADMINISTRATORS) and allow READ [only] for SYSTEM and ADMINISTRATORS\n groups\n\n If required:\n\n - Restrict extproc execution to only authorized applications.\n - Specify EXTPROC_DLLS=ONLY: [list of authorized DLLS] in the extproc.ora and\n the listener.ora files\n - Create a separate, dedicated listener for use by the external procedure agent\n\n See the Oracle Net Services Administrators Guides, External Procedures section\n for detailed configuration information." + "check": "Review file protections assigned to online backup and\n restoration files. Review access protections and procedures for off-line backup\n and restoration files.\n\n If backup or restoration files are subject to unauthorized access, this is a\n finding.\n\n It may be necessary to review backup and restoration procedures to determine\n ownership and access during all phases of backup and recovery.", + "fix": "Implement protection for backup and restoration files. Document\n personnel and the level of access authorized for each to the backup and\n restoration files in the system documentation." }, - "code": " control 'V-61685' do\n impact 0.0\n describe 'This control is not applicable on oracle within aws rds, as aws manages the operating system in which the oracle database is running on' do\n skip 'This control is not applicable on oracle within aws rds, as aws manages the operating system in which the oracle database is running on'\n end\n end\n", + "code": "control 'V-61699' do\n title \"DBMS backup and restoration files must be protected from unauthorized\n access.\"\n desc \"Information system backup is a critical step in maintaining data\n assurance and availability.\n\n User-level information is data generated by information system and/or\n application users. In order to assure availability of this data in the event of\n a system failure, DoD organizations are required to ensure user-generated data\n is backed up at a defined frequency. This includes data stored on file systems,\n within databases or within any other storage media.\n\n Applications performing backups must be capable of backing up user-level\n information per the DoD-defined frequency.\n\n Lost or compromised DBMS backup and restoration files may lead to not only\n the loss of data, but also the unauthorized access to sensitive data. Backup\n files need the same protections against unauthorized access when stored on\n backup media as when online and actively in use by the database system. In\n addition, the backup media needs to be protected against physical loss. Most\n DBMS's maintain online copies of critical control files to provide transparent\n or easy recovery from hard disk loss or other interruptions to database\n operation.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000145-DB-000098'\n tag \"gid\": 'V-61699'\n tag \"rid\": 'SV-76189r1_rule'\n tag \"stig_id\": 'O121-C2-012500'\n tag \"fix_id\": 'F-67615r1_fix'\n tag \"cci\": ['CCI-000535']\n tag \"nist\": ['CP-9 (a)', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Review file protections assigned to online backup and\n restoration files. Review access protections and procedures for off-line backup\n and restoration files.\n\n If backup or restoration files are subject to unauthorized access, this is a\n finding.\n\n It may be necessary to review backup and restoration procedures to determine\n ownership and access during all phases of backup and recovery.\"\n tag \"fix\": \"Implement protection for backup and restoration files. Document\n personnel and the level of access authorized for each to the backup and\n restoration files in the system documentation.\"\n describe 'A manual review is required to ensure DBMS backup and restoration files are protected from unauthorized\n access' do\n skip 'A manual review is required to ensure DBMS backup and restoration files are protected from unauthorized\n access'\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61685.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61699.rb", "line": 1 }, - "id": "V-61685" + "id": "V-61699" }, { - "title": "The DBMS must automatically audit account modification.", - "desc": "Once an attacker establishes initial access to a system, they often\n attempt to create a persistent method of re-establishing access. One way to\n accomplish this is for the attacker to simply modify an existing account.\n\n Auditing of account modification is one method and best practice for\n mitigating this risk. A comprehensive application account management process\n ensures an audit trail automatically documents the modification of application\n user accounts and, as required, notifies administrators, application owners,\n and/or appropriate individuals. Applications must provide this capability\n directly, leveraging complementary technology providing this capability or a\n combination thereof.\n\n Automated account auditing processes greatly reduces the risk that accounts\n will be surreptitiously modified and provides logging that can be used for\n forensic purposes.\n\n Note that user authentication and account management should be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP.\n\n However, notwithstanding how accounts are managed, Oracle auditing should\n always be configured to capture account modification.", + "title": "The DBMS must not share a host supporting an independent security\n service.", + "desc": "The Security Support Structure is a security control function or\n service provided by an external system or application. An example of this would\n be a Windows domain controller that provides identification and authentication\n that can be used by other systems to control access. The associated risk of a\n DBMS installed on a system that provides security support is significantly\n higher than when installed on separate systems. In cases where the DBMS is\n dedicated to local support of a security support function (e.g. a directory\n service), separation may not be possible.", "descriptions": { - "default": "Once an attacker establishes initial access to a system, they often\n attempt to create a persistent method of re-establishing access. One way to\n accomplish this is for the attacker to simply modify an existing account.\n\n Auditing of account modification is one method and best practice for\n mitigating this risk. A comprehensive application account management process\n ensures an audit trail automatically documents the modification of application\n user accounts and, as required, notifies administrators, application owners,\n and/or appropriate individuals. Applications must provide this capability\n directly, leveraging complementary technology providing this capability or a\n combination thereof.\n\n Automated account auditing processes greatly reduces the risk that accounts\n will be surreptitiously modified and provides logging that can be used for\n forensic purposes.\n\n Note that user authentication and account management should be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP.\n\n However, notwithstanding how accounts are managed, Oracle auditing should\n always be configured to capture account modification." + "default": "The Security Support Structure is a security control function or\n service provided by an external system or application. An example of this would\n be a Windows domain controller that provides identification and authentication\n that can be used by other systems to control access. The associated risk of a\n DBMS installed on a system that provides security support is significantly\n higher than when installed on separate systems. In cases where the DBMS is\n dedicated to local support of a security support function (e.g. a directory\n service), separation may not be possible." }, "impact": 0.5, "refs": [], "tags": { - "gtitle": "SRG-APP-000027-DB-000186", - "gid": "V-61569", - "rid": "SV-76059r2_rule", - "stig_id": "O121-C2-002300", - "fix_id": "F-67485r3_fix", + "gtitle": "SRG-APP-000516-DB-999900", + "gid": "V-61509", + "rid": "SV-75999r1_rule", + "stig_id": "O121-BP-025300", + "fix_id": "F-67425r1_fix", "cci": [ - "CCI-001403" + "CCI-000366" ], "nist": [ - "AC-2 (4)", + "CM-6 b", "Rev_4" ], "false_negatives": null, @@ -3927,35 +4015,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Check Oracle settings (and also OS settings and/or\n enterprise-level authentication/access mechanisms settings) to determine if\n account modification is being audited. If account modification is not being\n audited by Oracle, this is a finding.\n\n If Standard Auditing is used:\n To see if Oracle is configured to capture audit data, enter the following\n SQL*Plus command:\n SHOW PARAMETER AUDIT_TRAIL\n or the following SQL query:\n SELECT * FROM SYS.V$PARAMETER WHERE NAME = 'audit_trail';\n If Oracle returns the value 'NONE', this is a finding.\n\n If Unified Auditing is used:\n To see if Oracle is configured to capture audit data including account\n modification, enter the following SQL*Plus command:\n SELECT ' Account modification is not being audited. '\n FROM dual\n WHERE (SELECT Count(*)\n FROM (select policy_name , audit_option from audit_unified_policies\n WHERE audit_option = 'ALTER USER'\n and policy_name in (select policy_name from\n audit_unified_enabled_policies where user_name='ALL USERS'))) = 0\n OR (SELECT value\n FROM v$option\n WHERE parameter = 'Unified Auditing') != 'TRUE';\n\n If Oracle returns \"no rows selected\", this is not a finding.", - "fix": "Configure Oracle to audit account modifications activities.\n\n If Standard Auditing is used:\n Use this process to ensure auditable events are captured:\n ALTER SYSTEM SET AUDIT_TRAIL= SCOPE=SPFILE;\n Audit trail type can be 'OS', 'DB', 'DB,EXTENDED', 'XML' or 'XML,EXTENDED'.\n After executing this statement, it may be necessary to shut down and restart\n the Oracle database.\n\n If Unified Auditing is used:\n To ensure auditable events are captured:\n Link the oracle binary with uniaud_on, and then restart the database. Oracle\n Database Upgrade Guide describes how to enable unified auditing. Reference\n V-61625 for information on how to configure a policy to audit account\n modification.\n\n For more information on the configuration of auditing, refer to the following\n documents:\n \"Auditing Database Activity\" in the Oracle Database 2 Day + Security Guide:\n http://docs.oracle.com/database/121/TDPSG/tdpsg_auditing.htm#TDPSG50000\n \"Monitoring Database Activity with Auditing\" in the Oracle Database Security\n Guide:\n http://docs.oracle.com/database/121/DBSEG/part_6.htm#CCHEHCGI\n \"DBMS_AUDIT_MGMT\" in the Oracle Database PL/SQL Packages and Types Reference:\n http://docs.oracle.com/database/121/ARPLS/d_audit_mgmt.htm#ARPLS241\n Oracle Database Upgrade Guide:\n http://docs.oracle.com/database/121/UPGRD/afterup.htm#UPGRD52810" + "check": "Review the services and processes active on the DBMS host\n system.\n\n If the host system is a Windows domain controller, this is a finding.\n\n If the host system is supporting any other security or directory services that\n do not use the DBMS to store information, this is a finding.\n\n Note: This does not include client security applications like firewall and\n antivirus software.", + "fix": "Either move the DBMS installation to a dedicated host system or\n move the directory or security services to another host system.\n\n A dedicated host system in this case refers to an instance of the operating\n system at a minimum.\n\n The operating system may reside on a virtual host machine where supported by\n the DBMS vendor." }, - "code": "control 'V-61569' do\n title 'The DBMS must automatically audit account modification.'\n desc \"Once an attacker establishes initial access to a system, they often\n attempt to create a persistent method of re-establishing access. One way to\n accomplish this is for the attacker to simply modify an existing account.\n\n Auditing of account modification is one method and best practice for\n mitigating this risk. A comprehensive application account management process\n ensures an audit trail automatically documents the modification of application\n user accounts and, as required, notifies administrators, application owners,\n and/or appropriate individuals. Applications must provide this capability\n directly, leveraging complementary technology providing this capability or a\n combination thereof.\n\n Automated account auditing processes greatly reduces the risk that accounts\n will be surreptitiously modified and provides logging that can be used for\n forensic purposes.\n\n Note that user authentication and account management should be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP.\n\n However, notwithstanding how accounts are managed, Oracle auditing should\n always be configured to capture account modification.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000027-DB-000186'\n tag \"gid\": 'V-61569'\n tag \"rid\": 'SV-76059r2_rule'\n tag \"stig_id\": 'O121-C2-002300'\n tag \"fix_id\": 'F-67485r3_fix'\n tag \"cci\": ['CCI-001403']\n tag \"nist\": ['AC-2 (4)', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Check Oracle settings (and also OS settings and/or\n enterprise-level authentication/access mechanisms settings) to determine if\n account modification is being audited. If account modification is not being\n audited by Oracle, this is a finding.\n\n If Standard Auditing is used:\n To see if Oracle is configured to capture audit data, enter the following\n SQL*Plus command:\n SHOW PARAMETER AUDIT_TRAIL\n or the following SQL query:\n SELECT * FROM SYS.V$PARAMETER WHERE NAME = 'audit_trail';\n If Oracle returns the value 'NONE', this is a finding.\n\n If Unified Auditing is used:\n To see if Oracle is configured to capture audit data including account\n modification, enter the following SQL*Plus command:\n SELECT ' Account modification is not being audited. '\n FROM dual\n WHERE (SELECT Count(*)\n FROM (select policy_name , audit_option from audit_unified_policies\n WHERE audit_option = 'ALTER USER'\n and policy_name in (select policy_name from\n audit_unified_enabled_policies where user_name='ALL USERS'))) = 0\n OR (SELECT value\n FROM v$option\n WHERE parameter = 'Unified Auditing') != 'TRUE';\n\n If Oracle returns \\\"no rows selected\\\", this is not a finding.\"\n tag \"fix\": \"Configure Oracle to audit account modifications activities.\n\n If Standard Auditing is used:\n Use this process to ensure auditable events are captured:\n ALTER SYSTEM SET AUDIT_TRAIL= SCOPE=SPFILE;\n Audit trail type can be 'OS', 'DB', 'DB,EXTENDED', 'XML' or 'XML,EXTENDED'.\n After executing this statement, it may be necessary to shut down and restart\n the Oracle database.\n\n If Unified Auditing is used:\n To ensure auditable events are captured:\n Link the oracle binary with uniaud_on, and then restart the database. Oracle\n Database Upgrade Guide describes how to enable unified auditing. Reference\n V-61625 for information on how to configure a policy to audit account\n modification.\n\n For more information on the configuration of auditing, refer to the following\n documents:\n \\\"Auditing Database Activity\\\" in the Oracle Database 2 Day + Security Guide:\n http://docs.oracle.com/database/121/TDPSG/tdpsg_auditing.htm#TDPSG50000\n \\\"Monitoring Database Activity with Auditing\\\" in the Oracle Database Security\n Guide:\n http://docs.oracle.com/database/121/DBSEG/part_6.htm#CCHEHCGI\n \\\"DBMS_AUDIT_MGMT\\\" in the Oracle Database PL/SQL Packages and Types Reference:\n http://docs.oracle.com/database/121/ARPLS/d_audit_mgmt.htm#ARPLS241\n Oracle Database Upgrade Guide:\n http://docs.oracle.com/database/121/UPGRD/afterup.htm#UPGRD52810\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n standard_auditing_used = input('standard_auditing_used')\n unified_auditing_used = input('unified_auditing_used')\n\n describe.one do\n describe 'Standard auditing is in use for audit purposes' do\n subject { standard_auditing_used }\n it { should be true }\n end\n\n describe 'Unified auditing is in use for audit purposes' do\n subject { unified_auditing_used }\n it { should be true }\n end\n end\n\n audit_trail = sql.query(\"select value from v$parameter where name = 'audit_trail';\").column('value')\n\n if standard_auditing_used\n describe 'The oracle database audit_trail parameter' do\n subject { audit_trail }\n it { should_not cmp 'NONE' }\n end\n end\n\n unified_auditing = sql.query(\"SELECT value FROM V$OPTION WHERE PARAMETER = 'Unified Auditing';\").column('value')\n\n if unified_auditing_used\n describe 'The oracle database unified auditing parameter' do\n subject { unified_auditing }\n it { should_not cmp 'FALSE' }\n end\n\n unified_auditing_events = sql.query(\"SELECT ' Account modification is not being audited. '\n FROM dual\n WHERE (SELECT Count(*)\n FROM (select policy_name , audit_option from audit_unified_policies\n WHERE audit_option = 'ALTER USER'\n and policy_name in (select policy_name from\n audit_unified_enabled_policies where user_name='ALL USERS'))) = 0\n OR (SELECT value\n FROM v$option\n WHERE parameter = 'Unified Auditing') != 'TRUE';\").column('Account modification is not being audited.').uniq\n\n describe 'The unified auditing data capture for account modification' do\n subject { unified_auditing_events.to_s }\n it { should_not cmp '[nil]' }\n end\n end\nend\n", + "code": "control 'V-61509' do\n title \"The DBMS must not share a host supporting an independent security\n service.\"\n desc \"The Security Support Structure is a security control function or\n service provided by an external system or application. An example of this would\n be a Windows domain controller that provides identification and authentication\n that can be used by other systems to control access. The associated risk of a\n DBMS installed on a system that provides security support is significantly\n higher than when installed on separate systems. In cases where the DBMS is\n dedicated to local support of a security support function (e.g. a directory\n service), separation may not be possible.\"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000516-DB-999900'\n tag \"gid\": 'V-61509'\n tag \"rid\": 'SV-75999r1_rule'\n tag \"stig_id\": 'O121-BP-025300'\n tag \"fix_id\": 'F-67425r1_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 services and processes active on the DBMS host\n system.\n\n If the host system is a Windows domain controller, this is a finding.\n\n If the host system is supporting any other security or directory services that\n do not use the DBMS to store information, this is a finding.\n\n Note: This does not include client security applications like firewall and\n antivirus software.\"\n tag \"fix\": \"Either move the DBMS installation to a dedicated host system or\n move the directory or security services to another host system.\n\n A dedicated host system in this case refers to an instance of the operating\n system at a minimum.\n\n The operating system may reside on a virtual host machine where supported by\n the DBMS vendor.\"\n describe 'A manual review is required to ensure the DBMS does not share a host supporting an independent security\n service' do\n skip 'A manual review is required to ensure the DBMS does not share a host supporting an independent security\n service'\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61569.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61509.rb", "line": 1 }, - "id": "V-61569" + "id": "V-61509" }, { - "title": "Procedures and restrictions for import of production data to\n development databases must be documented, implemented and followed.", - "desc": "Data export from production databases may include sensitive data.\n Application developers may not be cleared for or have need-to-know to sensitive\n data. Any access they may have to production data would be considered\n unauthorized access and subject the sensitive data to unlawful or unauthorized\n disclosure.", + "title": "Database software directories, including DBMS configuration files,\n must be stored in dedicated directories, or DASD pools, separate from the host\n OS and other applications.", + "desc": "When dealing with change control issues, it should be noted, any\n changes to the hardware, software, and/or firmware components of the\n information system and/or application can potentially have significant effects\n on the overall security of the system.\n\n Multiple applications can provide a cumulative negative effect. A\n vulnerability and subsequent exploit to one application can lead to an exploit\n of other applications sharing the same security context. For example, an\n exploit to a web server process that leads to unauthorized administrative\n access to host system directories can most likely lead to a compromise of all\n applications hosted by the same system. Database software not installed using\n dedicated directories both threatens and is threatened by other hosted\n applications. Access controls defined for one application may by default\n provide access to the other application's database objects or directories. Any\n method that provides any level of separation of security context assists in the\n protection between applications.", "descriptions": { - "default": "Data export from production databases may include sensitive data.\n Application developers may not be cleared for or have need-to-know to sensitive\n data. Any access they may have to production data would be considered\n unauthorized access and subject the sensitive data to unlawful or unauthorized\n disclosure." + "default": "When dealing with change control issues, it should be noted, any\n changes to the hardware, software, and/or firmware components of the\n information system and/or application can potentially have significant effects\n on the overall security of the system.\n\n Multiple applications can provide a cumulative negative effect. A\n vulnerability and subsequent exploit to one application can lead to an exploit\n of other applications sharing the same security context. For example, an\n exploit to a web server process that leads to unauthorized administrative\n access to host system directories can most likely lead to a compromise of all\n applications hosted by the same system. Database software not installed using\n dedicated directories both threatens and is threatened by other hosted\n applications. Access controls defined for one application may by default\n provide access to the other application's database objects or directories. Any\n method that provides any level of separation of security context assists in the\n protection between applications." }, "impact": 0.5, "refs": [], "tags": { - "gtitle": "SRG-APP-000516-DB-999900", - "gid": "V-61501", - "rid": "SV-75991r1_rule", - "stig_id": "O121-BP-024800", - "fix_id": "F-67417r1_fix", + "gtitle": "SRG-APP-000133-DB-000199", + "gid": "V-61875", + "rid": "SV-76365r1_rule", + "stig_id": "O121-P2-010900", + "fix_id": "F-67791r1_fix", "cci": [ - "CCI-000366" + "CCI-001499" ], "nist": [ - "CM-6 b", + "CM-5 (6)", "Rev_4" ], "false_negatives": null, @@ -3968,39 +4056,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "If the database being reviewed is not a production database or\n does not contain sensitive data, this check is not a finding.\n\n Review documented policy, procedures and proof of implementation for\n restrictions placed on data exports from the production database.\n\n Policy and procedures should include that only authorized users have access to\n DBMS export utilities and that export data is properly sanitized prior to\n import to a development database.\n\n Policy and procedures may also include that developers be granted the necessary\n clearance and need-to-know prior to import of production data.\n\n If documented policy, procedures and proof of implementation are not present or\n complete, this is a finding.\n\n If methods to sanitize sensitive data are required and not documented or\n followed, this is a finding.", - "fix": "Develop, document and implement policy and procedures that\n provide restrictions for production data export.\n\n Require users and administrators assigned privileges that allow the export of\n production data from a production database to acknowledge understanding of\n export restrictions.\n\n Restrict permissions allowing use or access to database export procedures or\n functions to authorized users.\n\n Ensure sensitive data from production is sanitized prior to import to a\n development database (See check O121-BP-023300.)\n\n Grant access and need-to-know to developers where allowed by policy." + "check": "Review the DBMS software library directory and note other root\n directories located on the same disk directory or any subdirectories. If any\n non-DBMS software directories exist on the disk directory, examine or\n investigate their use.\n\n If any of the directories are used by other applications, including third-party\n applications that use the DBMS, this is a finding.\n\n Only applications that are required for the functioning and administration, not\n use, of the DBMS should be located on the same disk directory as the DBMS\n software libraries.\n\n For databases located on mainframes, confirm that the database and its\n configuration files are isolated in their own DASD pools.\n\n If database software and database configuration files share DASD with other\n applications, this is a finding.", + "fix": "Install all applications on directories, or pools, separate from\n the DBMS software library directory. Re-locate any directories or re-install\n other application software that currently shares the DBMS software library\n directory to separate directories.\n\n For mainframe-based databases, locate database software and configuration files\n in separate DASD pools from other mainframe applications." }, - "code": "control 'V-61501' do\n title \"Procedures and restrictions for import of production data to\n development databases must be documented, implemented and followed.\"\n desc \"Data export from production databases may include sensitive data.\n Application developers may not be cleared for or have need-to-know to sensitive\n data. Any access they may have to production data would be considered\n unauthorized access and subject the sensitive data to unlawful or unauthorized\n disclosure.\"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000516-DB-999900'\n tag \"gid\": 'V-61501'\n tag \"rid\": 'SV-75991r1_rule'\n tag \"stig_id\": 'O121-BP-024800'\n tag \"fix_id\": 'F-67417r1_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 database being reviewed is not a production database or\n does not contain sensitive data, this check is not a finding.\n\n Review documented policy, procedures and proof of implementation for\n restrictions placed on data exports from the production database.\n\n Policy and procedures should include that only authorized users have access to\n DBMS export utilities and that export data is properly sanitized prior to\n import to a development database.\n\n Policy and procedures may also include that developers be granted the necessary\n clearance and need-to-know prior to import of production data.\n\n If documented policy, procedures and proof of implementation are not present or\n complete, this is a finding.\n\n If methods to sanitize sensitive data are required and not documented or\n followed, this is a finding.\"\n tag \"fix\": \"Develop, document and implement policy and procedures that\n provide restrictions for production data export.\n\n Require users and administrators assigned privileges that allow the export of\n production data from a production database to acknowledge understanding of\n export restrictions.\n\n Restrict permissions allowing use or access to database export procedures or\n functions to authorized users.\n\n Ensure sensitive data from production is sanitized prior to import to a\n development database (See check O121-BP-023300.)\n\n Grant access and need-to-know to developers where allowed by policy.\"\n describe 'A manual review is required to ensure procedures and restrictions for import of production data to\n development databases are documented, implemented and followed' do\n skip 'A manual review is required to ensure procedures and restrictions for import of production data to\n development databases are documented, implemented and followed'\n end\nend\n", + "code": "control 'V-61875' do\n title \"Database software directories, including DBMS configuration files,\n must be stored in dedicated directories, or DASD pools, separate from the host\n OS and other applications.\"\n desc \"When dealing with change control issues, it should be noted, any\n changes to the hardware, software, and/or firmware components of the\n information system and/or application can potentially have significant effects\n on the overall security of the system.\n\n Multiple applications can provide a cumulative negative effect. A\n vulnerability and subsequent exploit to one application can lead to an exploit\n of other applications sharing the same security context. For example, an\n exploit to a web server process that leads to unauthorized administrative\n access to host system directories can most likely lead to a compromise of all\n applications hosted by the same system. Database software not installed using\n dedicated directories both threatens and is threatened by other hosted\n applications. Access controls defined for one application may by default\n provide access to the other application's database objects or directories. Any\n method that provides any level of separation of security context assists in the\n protection between applications.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000133-DB-000199'\n tag \"gid\": 'V-61875'\n tag \"rid\": 'SV-76365r1_rule'\n tag \"stig_id\": 'O121-P2-010900'\n tag \"fix_id\": 'F-67791r1_fix'\n tag \"cci\": ['CCI-001499']\n tag \"nist\": ['CM-5 (6)', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Review the DBMS software library directory and note other root\n directories located on the same disk directory or any subdirectories. If any\n non-DBMS software directories exist on the disk directory, examine or\n investigate their use.\n\n If any of the directories are used by other applications, including third-party\n applications that use the DBMS, this is a finding.\n\n Only applications that are required for the functioning and administration, not\n use, of the DBMS should be located on the same disk directory as the DBMS\n software libraries.\n\n For databases located on mainframes, confirm that the database and its\n configuration files are isolated in their own DASD pools.\n\n If database software and database configuration files share DASD with other\n applications, this is a finding.\"\n tag \"fix\": \"Install all applications on directories, or pools, separate from\n the DBMS software library directory. Re-locate any directories or re-install\n other application software that currently shares the DBMS software library\n directory to separate directories.\n\n For mainframe-based databases, locate database software and configuration files\n in separate DASD pools from other mainframe applications.\"\n describe 'A manual review is required to ensure Database software directories, including DBMS configuration files,\n are stored in dedicated directories, or DASD pools, separate from the host\n OS and other applications' do\n skip 'A manual review is required to ensure Database software directories, including DBMS configuration files,\n are stored in dedicated directories, or DASD pools, separate from the host\n OS and other applications'\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61501.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61875.rb", "line": 1 }, - "id": "V-61501" + "id": "V-61875" }, { - "title": "The DBMS must use organization-defined replay-resistant authentication\n mechanisms for network access to non-privileged accounts.", - "desc": "An authentication process resists replay attacks if it is impractical\n to achieve a successful authentication by recording and replaying a previous\n authentication message.\n\n Techniques used to address this include protocols using nonces (e.g.,\n numbers generated for a specific one-time use) or challenges (e.g., TLS,\n WS_Security), and time synchronous or challenge-response one-time\n authenticators.\n\n Replay attacks, if successfully used against a database account, could\n result in access to database data. A successful replay attack against a\n non-privileged database account could result in a compromise of data stored on\n the database.\n\n Oracle Database enables you to encrypt data that is sent over a network.\n There is no distinction between privileged and non-privileged accounts.\n\n Encryption of network data provides data privacy so that unauthorized\n parties are not able to view plaintext data as it passes over the network.\n Oracle Database also provides protection against two forms of active attacks.\n\n Data modification attack: An unauthorized party intercepting data in\n transit, altering it, and retransmitting it is a data modification attack. For\n example, intercepting a $100 bank deposit, changing the amount to $10,000, and\n retransmitting the higher amount is a data modification attack.\n\n Replay attack: Repetitively retransmitting an entire set of valid data is\n a replay attack, such as intercepting a $100 bank withdrawal and retransmitting\n it ten times, thereby receiving $1,000.\n\n AES and Triple-DES operate in outer Cipher Block Chaining (CBC) mode.\n\n The DES algorithm uses a 56-bit key length.\n\n SHA-1 is in the process of being removed from service within the DoD and\n it's use is to be limited during the transition to SHA-2. Use of SHA-1 for\n digital signature generation is prohibited. Allowable uses during the\n transition include CHECKSUM usage and verification of legacy certificate\n signatures. SHA-1 is considered a temporary solution during legacy application\n transitionary periods and should not be engineered into new applications. SHA-2\n is the path forward for DoD.", + "title": "The DBMS must notify appropriate individuals when accounts are\n modified.", + "desc": "Once an attacker establishes initial access to a system, they often\n attempt to create a persistent method of re-establishing access. One way to\n accomplish this is for the attacker to modify an existing account for later use.\n\n Notification of account creation is one method and best practice for\n mitigating this risk. A comprehensive account management process will ensure an\n audit trail which documents the creation of application user accounts and\n notifies administrators and/or application owners that they exist. Such a\n process greatly reduces the risk that accounts will be surreptitiously created\n and provides logging that can be used for forensic purposes.\n\n Note that user authentication and account management must be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP. This requirement applies to cases where accounts are\n directly managed by Oracle.\n\n Notwithstanding how accounts are normally managed, the DBMS must support\n the requirement to notify appropriate individuals upon account modification\n within Oracle. Indeed, in a configuration where accounts are managed\n externally, the manipulation of an account within Oracle may indicate hostile\n activity.", "descriptions": { - "default": "An authentication process resists replay attacks if it is impractical\n to achieve a successful authentication by recording and replaying a previous\n authentication message.\n\n Techniques used to address this include protocols using nonces (e.g.,\n numbers generated for a specific one-time use) or challenges (e.g., TLS,\n WS_Security), and time synchronous or challenge-response one-time\n authenticators.\n\n Replay attacks, if successfully used against a database account, could\n result in access to database data. A successful replay attack against a\n non-privileged database account could result in a compromise of data stored on\n the database.\n\n Oracle Database enables you to encrypt data that is sent over a network.\n There is no distinction between privileged and non-privileged accounts.\n\n Encryption of network data provides data privacy so that unauthorized\n parties are not able to view plaintext data as it passes over the network.\n Oracle Database also provides protection against two forms of active attacks.\n\n Data modification attack: An unauthorized party intercepting data in\n transit, altering it, and retransmitting it is a data modification attack. For\n example, intercepting a $100 bank deposit, changing the amount to $10,000, and\n retransmitting the higher amount is a data modification attack.\n\n Replay attack: Repetitively retransmitting an entire set of valid data is\n a replay attack, such as intercepting a $100 bank withdrawal and retransmitting\n it ten times, thereby receiving $1,000.\n\n AES and Triple-DES operate in outer Cipher Block Chaining (CBC) mode.\n\n The DES algorithm uses a 56-bit key length.\n\n SHA-1 is in the process of being removed from service within the DoD and\n it's use is to be limited during the transition to SHA-2. Use of SHA-1 for\n digital signature generation is prohibited. Allowable uses during the\n transition include CHECKSUM usage and verification of legacy certificate\n signatures. SHA-1 is considered a temporary solution during legacy application\n transitionary periods and should not be engineered into new applications. SHA-2\n is the path forward for DoD." + "default": "Once an attacker establishes initial access to a system, they often\n attempt to create a persistent method of re-establishing access. One way to\n accomplish this is for the attacker to modify an existing account for later use.\n\n Notification of account creation is one method and best practice for\n mitigating this risk. A comprehensive account management process will ensure an\n audit trail which documents the creation of application user accounts and\n notifies administrators and/or application owners that they exist. Such a\n process greatly reduces the risk that accounts will be surreptitiously created\n and provides logging that can be used for forensic purposes.\n\n Note that user authentication and account management must be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP. This requirement applies to cases where accounts are\n directly managed by Oracle.\n\n Notwithstanding how accounts are normally managed, the DBMS must support\n the requirement to notify appropriate individuals upon account modification\n within Oracle. Indeed, in a configuration where accounts are managed\n externally, the manipulation of an account within Oracle may indicate hostile\n activity." }, - "impact": 0, - "refs": [ - { - "ref": [] - } - ], + "impact": 0.5, + "refs": [], "tags": { - "gtitle": "SRG-APP-000157-DB-000112", - "gid": "V-61715", - "rid": "SV-76205r4_rule", - "stig_id": "O121-C2-013700", - "fix_id": "F-67631r1_fix", + "gtitle": "SRG-APP-000292-DB-000138", + "gid": "V-61799", + "rid": "SV-76289r2_rule", + "stig_id": "O121-C2-020500", + "fix_id": "F-67715r1_fix", "cci": [ - "CCI-001942" + "CCI-001684" ], "nist": [ - "IA-2 (9)", + "AC-2 (4)", "Rev_4" ], "false_negatives": null, @@ -4013,35 +4097,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Review DBMS settings to determine whether organization-defined\n replay-resistant authentication mechanisms for network access to non-privileged\n accounts exist.\n\n If these mechanisms do not exist, this is a finding.\n\n To check that network encryption is enabled and using site-specified encryption\n procedures, look in SQLNET.ORA, located at\n $ORACLE_HOME/network/admin/sqlnet.ora. (Note: This assumes that a single\n sqlnet.ora file, in the default location, is in use. Please see the\n supplemental file \"Non-default sqlnet.ora configurations.pdf\" for how to find\n multiple and/or differently located sqlnet.ora files.) If encryption is set,\n entries like the following will be present:\n\n SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER= (SHA384)\n SQLNET.ENCRYPTION_TYPES_SERVER=(AES256)\n SQLNET.CRYPTO_CHECKSUM_SERVER = required\n\n SQLNET.CRYPTO_CHECKSUM_TYPES_CLIENT= (SHA384)\n SQLNET.ENCRYPTION_TYPES_CLIENT= (AES256)\n SQLNET.CRYPTO_CHECKSUM_CLIENT = requested\n\n (The values assigned to the parameters may be different, the combination of\n parameters may be different, and not all of the example parameters will\n necessarily exist in the file.)", - "fix": "Configure DBMS, OS and/or enterprise-level authentication/access\n mechanism to require organization-defined replay-resistant authentication\n mechanisms for network access to non-privileged accounts.\n\n If appropriate, apply Oracle Data Network Encryption to protect against replay\n mechanisms." + "check": "Check DBMS settings to determine whether it will notify\n appropriate individuals when accounts are modified.\n\n If the DBMS does not notify appropriate individuals when accounts are modified,\n this is a finding.", + "fix": "Working with the DBA and site management, determine the\n appropriate individuals (by job role) to be notified.\n\n If Oracle Audit Vault is available, configure it to notify the appropriate\n individuals when accounts are modified.\n\n If Oracle Audit Vault is not available, configure the Oracle DBMS's auditing\n feature to record account-modification activity.\n\n If Standard Auditing is used:\n Create and deploy a mechanism, such as a frequently-run job, to monitor the\n SYS.AUD$ table for these records and notify the appropriate individuals.\n\n If unified Auditing is used:\n Create and deploy a mechanism, such as a frequently-run job, to monitor the\n SYS.UNIFIED_AUDIT_TRAIL view for these records and notify the appropriate\n individuals." }, - "code": " control 'V-61715' 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-61799' do\n title \"The DBMS must notify appropriate individuals when accounts are\n modified.\"\n desc \"Once an attacker establishes initial access to a system, they often\n attempt to create a persistent method of re-establishing access. One way to\n accomplish this is for the attacker to modify an existing account for later use.\n\n Notification of account creation is one method and best practice for\n mitigating this risk. A comprehensive account management process will ensure an\n audit trail which documents the creation of application user accounts and\n notifies administrators and/or application owners that they exist. Such a\n process greatly reduces the risk that accounts will be surreptitiously created\n and provides logging that can be used for forensic purposes.\n\n Note that user authentication and account management must be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP. This requirement applies to cases where accounts are\n directly managed by Oracle.\n\n Notwithstanding how accounts are normally managed, the DBMS must support\n the requirement to notify appropriate individuals upon account modification\n within Oracle. Indeed, in a configuration where accounts are managed\n externally, the manipulation of an account within Oracle may indicate hostile\n activity.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000292-DB-000138'\n tag \"gid\": 'V-61799'\n tag \"rid\": 'SV-76289r2_rule'\n tag \"stig_id\": 'O121-C2-020500'\n tag \"fix_id\": 'F-67715r1_fix'\n tag \"cci\": ['CCI-001684']\n tag \"nist\": ['AC-2 (4)', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Check DBMS settings to determine whether it will notify\n appropriate individuals when accounts are modified.\n\n If the DBMS does not notify appropriate individuals when accounts are modified,\n this is a finding.\"\n tag \"fix\": \"Working with the DBA and site management, determine the\n appropriate individuals (by job role) to be notified.\n\n If Oracle Audit Vault is available, configure it to notify the appropriate\n individuals when accounts are modified.\n\n If Oracle Audit Vault is not available, configure the Oracle DBMS's auditing\n feature to record account-modification activity.\n\n If Standard Auditing is used:\n Create and deploy a mechanism, such as a frequently-run job, to monitor the\n SYS.AUD$ table for these records and notify the appropriate individuals.\n\n If unified Auditing is used:\n Create and deploy a mechanism, such as a frequently-run job, to monitor the\n SYS.UNIFIED_AUDIT_TRAIL view for these records and notify the appropriate\n individuals.\"\n describe 'A manual review is required to ensure the DBMS notifies the appropriate individuals when accounts are\n modified' do\n skip 'A manual review is required to ensure the DBMS notifies the appropriate individuals when accounts are\n modified'\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61715.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61799.rb", "line": 1 }, - "id": "V-61715" + "id": "V-61799" }, { - "title": "The DBMS must not share a host supporting an independent security\n service.", - "desc": "The Security Support Structure is a security control function or\n service provided by an external system or application. An example of this would\n be a Windows domain controller that provides identification and authentication\n that can be used by other systems to control access. The associated risk of a\n DBMS installed on a system that provides security support is significantly\n higher than when installed on separate systems. In cases where the DBMS is\n dedicated to local support of a security support function (e.g. a directory\n service), separation may not be possible.", + "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": "The Security Support Structure is a security control function or\n service provided by an external system or application. An example of this would\n be a Windows domain controller that provides identification and authentication\n that can be used by other systems to control access. The associated risk of a\n DBMS installed on a system that provides security support is significantly\n higher than when installed on separate systems. In cases where the DBMS is\n dedicated to local support of a security support function (e.g. a directory\n service), separation may not be possible." + "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, + "impact": 0, "refs": [], "tags": { - "gtitle": "SRG-APP-000516-DB-999900", - "gid": "V-61509", - "rid": "SV-75999r1_rule", - "stig_id": "O121-BP-025300", - "fix_id": "F-67425r1_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-000366" + "CCI-000164" ], "nist": [ - "CM-6 b", + "AU-9", "Rev_4" ], "false_negatives": null, @@ -4054,30 +4138,30 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Review the services and processes active on the DBMS host\n system.\n\n If the host system is a Windows domain controller, this is a finding.\n\n If the host system is supporting any other security or directory services that\n do not use the DBMS to store information, this is a finding.\n\n Note: This does not include client security applications like firewall and\n antivirus software.", - "fix": "Either move the DBMS installation to a dedicated host system or\n move the directory or security services to another host system.\n\n A dedicated host system in this case refers to an instance of the operating\n system at a minimum.\n\n The operating system may reside on a virtual host machine where supported by\n the DBMS vendor." + "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-61509' do\n title \"The DBMS must not share a host supporting an independent security\n service.\"\n desc \"The Security Support Structure is a security control function or\n service provided by an external system or application. An example of this would\n be a Windows domain controller that provides identification and authentication\n that can be used by other systems to control access. The associated risk of a\n DBMS installed on a system that provides security support is significantly\n higher than when installed on separate systems. In cases where the DBMS is\n dedicated to local support of a security support function (e.g. a directory\n service), separation may not be possible.\"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000516-DB-999900'\n tag \"gid\": 'V-61509'\n tag \"rid\": 'SV-75999r1_rule'\n tag \"stig_id\": 'O121-BP-025300'\n tag \"fix_id\": 'F-67425r1_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 services and processes active on the DBMS host\n system.\n\n If the host system is a Windows domain controller, this is a finding.\n\n If the host system is supporting any other security or directory services that\n do not use the DBMS to store information, this is a finding.\n\n Note: This does not include client security applications like firewall and\n antivirus software.\"\n tag \"fix\": \"Either move the DBMS installation to a dedicated host system or\n move the directory or security services to another host system.\n\n A dedicated host system in this case refers to an instance of the operating\n system at a minimum.\n\n The operating system may reside on a virtual host machine where supported by\n the DBMS vendor.\"\n describe 'A manual review is required to ensure the DBMS does not share a host supporting an independent security\n service' do\n skip 'A manual review is required to ensure the DBMS does not share a host supporting an independent security\n service'\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-61509.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61657.rb", "line": 1 }, - "id": "V-61509" + "id": "V-61657" }, { - "title": "All use of privileged accounts must be audited.", - "desc": "This is intended to limit exposure, by making it possible to trace any\n unauthorized access, by a privileged user account or role that has permissions\n on security functions or security-relevant information, to other data or\n functionality.", + "title": "The Oracle REMOTE_OS_ROLES parameter must be set to FALSE.", + "desc": "Setting REMOTE_OS_ROLES to TRUE allows operating system groups to\n control Oracle roles. The default value of FALSE causes roles to be identified\n and managed by the database. If REMOTE_OS_ROLES is set to TRUE, a remote user\n could impersonate another operating system user over a network connection.", "descriptions": { - "default": "This is intended to limit exposure, by making it possible to trace any\n unauthorized access, by a privileged user account or role that has permissions\n on security functions or security-relevant information, to other data or\n functionality." + "default": "Setting REMOTE_OS_ROLES to TRUE allows operating system groups to\n control Oracle roles. The default value of FALSE causes roles to be identified\n and managed by the database. If REMOTE_OS_ROLES is set to TRUE, a remote user\n could impersonate another operating system user over a network connection." }, - "impact": 0.5, + "impact": 0.7, "refs": [], "tags": { - "gtitle": "SRG-APP-000063-DB-000018", - "gid": "V-61595", - "rid": "SV-76085r2_rule", - "stig_id": "O121-C2-004200", - "fix_id": "F-67511r1_fix", + "gtitle": "SRG-APP-000516-DB-999900", + "gid": "V-61427", + "rid": "SV-75917r1_rule", + "stig_id": "O121-BP-022000", + "fix_id": "F-67343r1_fix", "cci": [ "CCI-000366" ], @@ -4095,35 +4179,39 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Review auditing configuration.\n\n If it is possible for a privileged user/role to access non-security functions\n or information without having the action recorded in the audit log, this is a\n finding.\n\n To obtain a list of unified auditing policies that have been defined, run the\n query:\n SELECT unique policy_name from AUDIT_UNIFIED_POLICIES;\n\n To obtain a list of unified auditing policies that have been enabled and the\n users for which it has been enabled, run the query:\n SELECT unique policy_name, user_name from AUDIT_UNIFIED_ENABLED_POLICIES;\n\n Unless otherwise required, verify that user_name is set to 'ALL USERS' to\n insure that the activity of administrative users is being logged.", - "fix": "Configure DBMS auditing so that all use of privileged accounts is\n recorded in the audit log." + "check": "From SQL*Plus:\n\n select value from v$parameter where name = 'remote_os_roles';\n\n If the returned value is not FALSE or not documented in the System Security\n Plan as required, this is a finding.", + "fix": "Document remote OS roles in the System Security Plan.\n\n If not required, disable use of remote OS roles.\n\n From SQL*Plus:\n\n alter system set remote_os_roles = FALSE scope = spfile;\n\n The above SQL*Plus command will set the parameter to take effect at next system\n startup." }, - "code": "control 'V-61595' do\n title 'All use of privileged accounts must be audited.'\n desc \"This is intended to limit exposure, by making it possible to trace any\n unauthorized access, by a privileged user account or role that has permissions\n on security functions or security-relevant information, to other data or\n functionality.\"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000063-DB-000018'\n tag \"gid\": 'V-61595'\n tag \"rid\": 'SV-76085r2_rule'\n tag \"stig_id\": 'O121-C2-004200'\n tag \"fix_id\": 'F-67511r1_fix'\n tag \"cci\": ['CCI-000366']\n tag \"nist\": ['CM-6 b', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Review auditing configuration.\n\n If it is possible for a privileged user/role to access non-security functions\n or information without having the action recorded in the audit log, this is a\n finding.\n\n To obtain a list of unified auditing policies that have been defined, run the\n query:\n SELECT unique policy_name from AUDIT_UNIFIED_POLICIES;\n\n To obtain a list of unified auditing policies that have been enabled and the\n users for which it has been enabled, run the query:\n SELECT unique policy_name, user_name from AUDIT_UNIFIED_ENABLED_POLICIES;\n\n Unless otherwise required, verify that user_name is set to 'ALL USERS' to\n insure that the activity of administrative users is being logged.\"\n tag \"fix\": \"Configure DBMS auditing so that all use of privileged accounts is\n recorded in the audit log.\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n unified_auditing_policies_defined = sql.query('SELECT unique policy_name from AUDIT_UNIFIED_POLICIES;').column('policy_name')\n\n describe 'The list of unified auditing policies defined' do\n subject { unified_auditing_policies_defined }\n it { should_not be_empty }\n end\n\n users_being_audited = sql.query('SELECT unique user_name from AUDIT_UNIFIED_ENABLED_POLICIES;').column('user_name')\n\n describe 'The list of users being audited' do\n subject { users_being_audited }\n it { should include 'ALL USERS' }\n end\nend\n", + "code": "control 'V-61427' do\n title 'The Oracle REMOTE_OS_ROLES parameter must be set to FALSE.'\n desc \"Setting REMOTE_OS_ROLES to TRUE allows operating system groups to\n control Oracle roles. The default value of FALSE causes roles to be identified\n and managed by the database. If REMOTE_OS_ROLES is set to TRUE, a remote user\n could impersonate another operating system user over a network connection.\"\n impact 0.7\n tag \"gtitle\": 'SRG-APP-000516-DB-999900'\n tag \"gid\": 'V-61427'\n tag \"rid\": 'SV-75917r1_rule'\n tag \"stig_id\": 'O121-BP-022000'\n tag \"fix_id\": 'F-67343r1_fix'\n tag \"cci\": ['CCI-000366']\n tag \"nist\": ['CM-6 b', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"From SQL*Plus:\n\n select value from v$parameter where name = 'remote_os_roles';\n\n If the returned value is not FALSE or not documented in the System Security\n Plan as required, this is a finding.\"\n tag \"fix\": \"Document remote OS roles in the System Security Plan.\n\n If not required, disable use of remote OS roles.\n\n From SQL*Plus:\n\n alter system set remote_os_roles = FALSE scope = spfile;\n\n The above SQL*Plus command will set the parameter to take effect at next system\n startup.\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n parameter = sql.query(\"select value from v$parameter where name = 'remote_os_roles';\").column('value')\n\n describe 'The oracle database REMOTE_OS_ROLES parameter' do\n subject { parameter }\n it { should cmp 'FALSE' }\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61595.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61427.rb", "line": 1 }, - "id": "V-61595" + "id": "V-61427" }, { - "title": "The DBMS must provide a mechanism to automatically identify accounts\n designated as temporary or emergency accounts.", - "desc": "Temporary application accounts could be used in the event of a vendor\n support visit where a support representative requires a temporary unique\n account in order to perform diagnostic testing or conduct some other\n support-related activity. When these types of accounts are created, there is a\n risk that the temporary account may remain in place and active after the\n support representative has left.\n\n To address this, in the event temporary application accounts are required,\n the application must ensure accounts designated as temporary in nature shall\n automatically terminate these accounts after an organization-defined time\n period. Such a process and capability greatly reduces the risk that accounts\n will be misused, hijacked, or data compromised.\n\n Note that user authentication and account management should be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP. This requirement applies to cases where it is necessary to\n have accounts directly managed by Oracle.\n\n Temporary database accounts must be identified in order for the system to\n recognize and terminate them after a given time period. The DBMS and any\n administrators must have a means to recognize any temporary accounts for\n special handling.", + "title": "The DBMS must support organizational requirements to enforce minimum\n password length.", + "desc": "Password complexity, or strength, is a measure of the effectiveness of\n a password in resisting attempts at guessing and brute-force attacks.\n\n To meet password policy requirements, passwords need to be changed at\n specific policy-based intervals.\n\n If the information system or application allows the user to consecutively\n reuse their password when that password has exceeded its defined lifetime, the\n end result is a password that is not changed as per policy requirements.\n\n Weak passwords are a primary target for attack to gain unauthorized access\n to databases and other systems. Where username/password is used for\n identification and authentication to the database, requiring the use of strong\n passwords can help prevent simple and more sophisticated methods for guessing\n at passwords.\n\n Note that user authentication and account management must be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP. This requirement applies to cases where it is necessary to\n have accounts directly managed by Oracle.", "descriptions": { - "default": "Temporary application accounts could be used in the event of a vendor\n support visit where a support representative requires a temporary unique\n account in order to perform diagnostic testing or conduct some other\n support-related activity. When these types of accounts are created, there is a\n risk that the temporary account may remain in place and active after the\n support representative has left.\n\n To address this, in the event temporary application accounts are required,\n the application must ensure accounts designated as temporary in nature shall\n automatically terminate these accounts after an organization-defined time\n period. Such a process and capability greatly reduces the risk that accounts\n will be misused, hijacked, or data compromised.\n\n Note that user authentication and account management should be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP. This requirement applies to cases where it is necessary to\n have accounts directly managed by Oracle.\n\n Temporary database accounts must be identified in order for the system to\n recognize and terminate them after a given time period. The DBMS and any\n administrators must have a means to recognize any temporary accounts for\n special handling." + "default": "Password complexity, or strength, is a measure of the effectiveness of\n a password in resisting attempts at guessing and brute-force attacks.\n\n To meet password policy requirements, passwords need to be changed at\n specific policy-based intervals.\n\n If the information system or application allows the user to consecutively\n reuse their password when that password has exceeded its defined lifetime, the\n end result is a password that is not changed as per policy requirements.\n\n Weak passwords are a primary target for attack to gain unauthorized access\n to databases and other systems. Where username/password is used for\n identification and authentication to the database, requiring the use of strong\n passwords can help prevent simple and more sophisticated methods for guessing\n at passwords.\n\n Note that user authentication and account management must be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP. This requirement applies to cases where it is necessary to\n have accounts directly managed by Oracle." }, "impact": 0.5, - "refs": [], + "refs": [ + { + "ref": [] + } + ], "tags": { - "gtitle": "SRG-APP-000024-DB-000002", - "gid": "V-61559", - "rid": "SV-76049r2_rule", - "stig_id": "O121-C2-001900", - "fix_id": "F-67475r6_fix", + "gtitle": "SRG-APP-000164-DB-000082", + "gid": "V-61719", + "rid": "SV-76209r1_rule", + "stig_id": "O121-C2-013900", + "fix_id": "F-67635r1_fix", "cci": [ - "CCI-000016" + "CCI-000205" ], "nist": [ - "AC-2 (2)", + "IA-5 (1) (a)", "Rev_4" ], "false_negatives": null, @@ -4136,35 +4224,39 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "If the organization has a policy, consistently enforced,\n forbidding the creation of emergency or temporary accounts, this is not a\n finding.\n\n If all user accounts are authenticated by the OS or an enterprise-level\n authentication/access mechanism and not by Oracle, this is not a finding.\n\n If using database mechanisms to satisfy this requirement, look for a profile\n for use with temporary accounts. To obtain a list of profiles:\n SELECT PROFILE#, NAME FROM SYS.PROFNAME$;\n\n To obtain a list of users assigned a given profile (TEMPORARY_USERS, in this\n example):\n SELECT USERNAME, PROFILE FROM SYS.DBA_USERS\n WHERE PROFILE = 'TEMPORARY_USERS'\n ORDER BY USERNAME;\n\n If no profile for temporary accounts can be identified, this is not a finding.", - "fix": "Use a profile with a distinctive name (for example,\n TEMPORARY_USERS), so that temporary users can be easily identified. Whenever a\n temporary user account is created, assign it to this profile.\n\n To enable resource limiting via profiles, use the SQL statement:\n ALTER SYSTEM SET RESOURCE_LIMIT = TRUE;\n\n Set values in the profile as needed for temporary users - see below for further\n information. The values here are examples; set them to values appropriate to\n the situation:\n\n CREATE PROFILE TEMPORARY_USERS\n LIMIT\n SESSIONS_PER_USER \n CPU_PER_SESSION \n CPU_PER_CALL \n CONNECT_TIME \n LOGICAL_READS_PER_SESSION DEFAULT\n LOGICAL_READS_PER_CALL \n PRIVATE_SGA \n COMPOSITE_LIMIT \n FAILED_LOGIN_ATTEMPTS 3\n PASSWORD_LIFE_TIME 7\n PASSWORD_REUSE_TIME 60\n PASSWORD_REUSE_MAX 5\n PASSWORD_VERIFY_FUNCTION ORA12c_STRONG_VERIFY_FUNCTION\n PASSWORD_LOCK_TIME UNLIMITED\n PASSWORD_GRACE_TIME 3;\n CREATE USER IDENTIFIED BY PROFILE TEMPORARY_USERS;\n\n Resource Parameters:\n\n COMPOSITE_LIMIT - Specify the total resource cost for a session, expressed in\n service units. Oracle Database calculates the total service units as a weighted\n sum of CPU_PER_SESSION, CONNECT_TIME,\n LOGICAL_READS_PER_SESSION, and PRIVATE_SGA.\n\n SESSIONS_PER_USER - Specify the number of concurrent sessions to limit the user\n to.\n\n CPU_PER_SESSION - Specify the CPU time limit for a session, expressed in\n hundredths of seconds.\n\n CPU_PER_CALL - Specify the CPU time limit for a call (a parse, execute, or\n fetch), expressed in hundredths of seconds.\n\n LOGICAL_READS_PER_SESSION - Specify the permitted number of data blocks read in\n a session, including blocks read from memory and disk.\n\n LOGICAL_READS_PER_CALL - Specify the permitted number of data blocks read for a\n call to process a SQL statement (a parse, execute, or fetch).\n\n PRIVATE_SGA - Specify the amount of private space a session can allocate in the\n shared pool of the system global area (SGA). Refer to size_clause for\n information on that clause.\n\n CONNECT_TIME - Specify the total elapsed time limit for a session, expressed in\n minutes.\n\n IDLE_TIME - Specify the permitted periods of continuous inactive time during a\n session, expressed in minutes. Long-running queries and other operations are\n not subject to this limit.\n\n COMPOSITE_LIMIT - See Oracle documentation for more details.\n\n\n Password Parameters\n\n Use the following clauses to set password parameters. Parameters that set\n lengths of time are interpreted in number of days. For testing purposes,\n specify minutes (n/1440) or even seconds (n/86400).\n\n FAILED_LOGIN_ATTEMPTS - Specify the number of failed attempts to log on to the\n user account before the account is locked. If omitting this clause, then the\n default is 10 times.\n\n PASSWORD_LIFE_TIME - Specify the number of days the same password can be used\n for authentication. If setting a value for PASSWORD_GRACE_TIME, then the\n password expires if it is not changed within the grace period, and further\n connections are rejected. If omitting this clause, then the default is 180 days.\n\n PASSWORD_REUSE_TIME and PASSWORD_REUSE_MAX - These two parameters must be set\n in conjunction with each other. PASSWORD_REUSE_TIME specifies the number of\n days before which a password cannot be reused. PASSWORD_REUSE_MAX specifies the\n number of password changes required before the current password can be reused.\n For these parameters to have any effect, specify an integer for both of them.\n\n If specifying a value for both of these parameters, then the user cannot reuse\n a password until the password has been changed the number of times specified\n for PASSWORD_REUSE_MAX during the number of days specified for\n PASSWORD_REUSE_TIME.\n\n For example, if specifying PASSWORD_REUSE_TIME to 30 and PASSWORD_REUSE_MAX to\n 10, then the user can reuse the password after 30 days if the password has\n already been changed 10 times.\n\n If specifying a value for either of these parameters and specify UNLIMITED for\n the other, then the user can never reuse a password.\n\n If specifying DEFAULT for either parameter, then Oracle Database uses the value\n defined in the DEFAULT profile. By default, all parameters are set to UNLIMITED\n in the DEFAULT profile. If the default setting of UNLIMITED in the DEFAULT\n profile has not changed, then the database treats the value for that parameter\n as UNLIMITED.\n\n If setting both of these parameters to UNLIMITED, then the database ignores\n both of them. This is the default if omitting both parameters.\n\n PASSWORD_LOCK_TIME - Specify the number of days an account will be locked after\n the specified number of consecutive failed logon attempts. If omitting this\n clause, then the default is 1 day.\n\n PASSWORD_GRACE_TIME - Specify the number of days after the grace period begins\n during which a warning is issued and logon is allowed. If omitting this clause,\n then the default is 7 days.\n\n PASSWORD_VERIFY_FUNCTION - The PASSWORD_VERIFY_FUNCTION clause lets a PL/SQL\n password complexity verification script be passed as an argument to the CREATE\n PROFILE statement. Oracle Database provides a default script, but can create\n your own routine or use third-party software instead." + "check": "If all user accounts are authenticated by the OS or an\n enterprise-level authentication/access mechanism, and not by Oracle, this is\n not a finding.\n\n For each profile that can be applied to accounts where authentication is under\n Oracle's control, determine the password verification function, if any, that is\n in use:\n\n SELECT * FROM SYS.DBA_PROFILES\n WHERE RESOURCE_NAME = 'PASSWORD_VERIFY_FUNCTION'\n [AND PROFILE NOT IN ()]\n ORDER BY PROFILE;\n\n Bearing in mind that a profile can inherit from another profile, and the root\n profile is called DEFAULT, determine the name of the password verification\n function effective for each profile.\n\n If, for any profile, the function name is null, this is a finding.\n\n For each password verification function, examine its source code.\n\n If it does not enforce the DoD-defined minimum length (15 unless otherwise\n specified), this is a finding.", + "fix": "If all user accounts are authenticated by the OS or an\n enterprise-level authentication/access mechanism, and not by Oracle, no fix to\n the DBMS is required.\n\n If any user accounts are managed by Oracle: Develop, test and implement a\n password verification function that enforces DoD requirements.\n\n (Oracle supplies a sample function called ORA12C_STRONG_VERIFY_FUNCTION, in the\n script file\n /RDBMS/ADMIN/utlpwdmg.sql. This can be used as the starting point\n for a customized function.)" }, - "code": "control 'V-61559' do\n title \"The DBMS must provide a mechanism to automatically identify accounts\n designated as temporary or emergency accounts.\"\n desc \"Temporary application accounts could be used in the event of a vendor\n support visit where a support representative requires a temporary unique\n account in order to perform diagnostic testing or conduct some other\n support-related activity. When these types of accounts are created, there is a\n risk that the temporary account may remain in place and active after the\n support representative has left.\n\n To address this, in the event temporary application accounts are required,\n the application must ensure accounts designated as temporary in nature shall\n automatically terminate these accounts after an organization-defined time\n period. Such a process and capability greatly reduces the risk that accounts\n will be misused, hijacked, or data compromised.\n\n Note that user authentication and account management should be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP. This requirement applies to cases where it is necessary to\n have accounts directly managed by Oracle.\n\n Temporary database accounts must be identified in order for the system to\n recognize and terminate them after a given time period. The DBMS and any\n administrators must have a means to recognize any temporary accounts for\n special handling.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000024-DB-000002'\n tag \"gid\": 'V-61559'\n tag \"rid\": 'SV-76049r2_rule'\n tag \"stig_id\": 'O121-C2-001900'\n tag \"fix_id\": 'F-67475r6_fix'\n tag \"cci\": ['CCI-000016']\n tag \"nist\": ['AC-2 (2)', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"If the organization has a policy, consistently enforced,\n forbidding the creation of emergency or temporary accounts, this is not a\n finding.\n\n If all user accounts are authenticated by the OS or an enterprise-level\n authentication/access mechanism and not by Oracle, this is not a finding.\n\n If using database mechanisms to satisfy this requirement, look for a profile\n for use with temporary accounts. To obtain a list of profiles:\n SELECT PROFILE#, NAME FROM SYS.PROFNAME$;\n\n To obtain a list of users assigned a given profile (TEMPORARY_USERS, in this\n example):\n SELECT USERNAME, PROFILE FROM SYS.DBA_USERS\n WHERE PROFILE = 'TEMPORARY_USERS'\n ORDER BY USERNAME;\n\n If no profile for temporary accounts can be identified, this is not a finding.\"\n tag \"fix\": \"Use a profile with a distinctive name (for example,\n TEMPORARY_USERS), so that temporary users can be easily identified. Whenever a\n temporary user account is created, assign it to this profile.\n\n To enable resource limiting via profiles, use the SQL statement:\n ALTER SYSTEM SET RESOURCE_LIMIT = TRUE;\n\n Set values in the profile as needed for temporary users - see below for further\n information. The values here are examples; set them to values appropriate to\n the situation:\n\n CREATE PROFILE TEMPORARY_USERS\n LIMIT\n SESSIONS_PER_USER \n CPU_PER_SESSION \n CPU_PER_CALL \n CONNECT_TIME \n LOGICAL_READS_PER_SESSION DEFAULT\n LOGICAL_READS_PER_CALL \n PRIVATE_SGA \n COMPOSITE_LIMIT \n FAILED_LOGIN_ATTEMPTS 3\n PASSWORD_LIFE_TIME 7\n PASSWORD_REUSE_TIME 60\n PASSWORD_REUSE_MAX 5\n PASSWORD_VERIFY_FUNCTION ORA12c_STRONG_VERIFY_FUNCTION\n PASSWORD_LOCK_TIME UNLIMITED\n PASSWORD_GRACE_TIME 3;\n CREATE USER IDENTIFIED BY PROFILE TEMPORARY_USERS;\n\n Resource Parameters:\n\n COMPOSITE_LIMIT - Specify the total resource cost for a session, expressed in\n service units. Oracle Database calculates the total service units as a weighted\n sum of CPU_PER_SESSION, CONNECT_TIME,\n LOGICAL_READS_PER_SESSION, and PRIVATE_SGA.\n\n SESSIONS_PER_USER - Specify the number of concurrent sessions to limit the user\n to.\n\n CPU_PER_SESSION - Specify the CPU time limit for a session, expressed in\n hundredths of seconds.\n\n CPU_PER_CALL - Specify the CPU time limit for a call (a parse, execute, or\n fetch), expressed in hundredths of seconds.\n\n LOGICAL_READS_PER_SESSION - Specify the permitted number of data blocks read in\n a session, including blocks read from memory and disk.\n\n LOGICAL_READS_PER_CALL - Specify the permitted number of data blocks read for a\n call to process a SQL statement (a parse, execute, or fetch).\n\n PRIVATE_SGA - Specify the amount of private space a session can allocate in the\n shared pool of the system global area (SGA). Refer to size_clause for\n information on that clause.\n\n CONNECT_TIME - Specify the total elapsed time limit for a session, expressed in\n minutes.\n\n IDLE_TIME - Specify the permitted periods of continuous inactive time during a\n session, expressed in minutes. Long-running queries and other operations are\n not subject to this limit.\n\n COMPOSITE_LIMIT - See Oracle documentation for more details.\n\n\n Password Parameters\n\n Use the following clauses to set password parameters. Parameters that set\n lengths of time are interpreted in number of days. For testing purposes,\n specify minutes (n/1440) or even seconds (n/86400).\n\n FAILED_LOGIN_ATTEMPTS - Specify the number of failed attempts to log on to the\n user account before the account is locked. If omitting this clause, then the\n default is 10 times.\n\n PASSWORD_LIFE_TIME - Specify the number of days the same password can be used\n for authentication. If setting a value for PASSWORD_GRACE_TIME, then the\n password expires if it is not changed within the grace period, and further\n connections are rejected. If omitting this clause, then the default is 180 days.\n\n PASSWORD_REUSE_TIME and PASSWORD_REUSE_MAX - These two parameters must be set\n in conjunction with each other. PASSWORD_REUSE_TIME specifies the number of\n days before which a password cannot be reused. PASSWORD_REUSE_MAX specifies the\n number of password changes required before the current password can be reused.\n For these parameters to have any effect, specify an integer for both of them.\n\n If specifying a value for both of these parameters, then the user cannot reuse\n a password until the password has been changed the number of times specified\n for PASSWORD_REUSE_MAX during the number of days specified for\n PASSWORD_REUSE_TIME.\n\n For example, if specifying PASSWORD_REUSE_TIME to 30 and PASSWORD_REUSE_MAX to\n 10, then the user can reuse the password after 30 days if the password has\n already been changed 10 times.\n\n If specifying a value for either of these parameters and specify UNLIMITED for\n the other, then the user can never reuse a password.\n\n If specifying DEFAULT for either parameter, then Oracle Database uses the value\n defined in the DEFAULT profile. By default, all parameters are set to UNLIMITED\n in the DEFAULT profile. If the default setting of UNLIMITED in the DEFAULT\n profile has not changed, then the database treats the value for that parameter\n as UNLIMITED.\n\n If setting both of these parameters to UNLIMITED, then the database ignores\n both of them. This is the default if omitting both parameters.\n\n PASSWORD_LOCK_TIME - Specify the number of days an account will be locked after\n the specified number of consecutive failed logon attempts. If omitting this\n clause, then the default is 1 day.\n\n PASSWORD_GRACE_TIME - Specify the number of days after the grace period begins\n during which a warning is issued and logon is allowed. If omitting this clause,\n then the default is 7 days.\n\n PASSWORD_VERIFY_FUNCTION - The PASSWORD_VERIFY_FUNCTION clause lets a PL/SQL\n password complexity verification script be passed as an argument to the CREATE\n PROFILE statement. Oracle Database provides a default script, but can create\n your own routine or use third-party software instead.\"\n describe 'A manual review is required to ensure the DBMS provides a mechanism to automatically identify accounts\n designated as temporary or emergency accounts' do\n skip 'A manual review is required to ensure the DBMS provides a mechanism to automatically identify accounts\n designated as temporary or emergency accounts'\n end\nend\n", + "code": "control 'V-61719' do\n title \"The DBMS must support organizational requirements to enforce minimum\n password length.\"\n desc \"Password complexity, or strength, is a measure of the effectiveness of\n a password in resisting attempts at guessing and brute-force attacks.\n\n To meet password policy requirements, passwords need to be changed at\n specific policy-based intervals.\n\n If the information system or application allows the user to consecutively\n reuse their password when that password has exceeded its defined lifetime, the\n end result is a password that is not changed as per policy requirements.\n\n Weak passwords are a primary target for attack to gain unauthorized access\n to databases and other systems. Where username/password is used for\n identification and authentication to the database, requiring the use of strong\n passwords can help prevent simple and more sophisticated methods for guessing\n at passwords.\n\n Note that user authentication and account management must be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP. This requirement applies to cases where it is necessary to\n have accounts directly managed by Oracle.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000164-DB-000082'\n tag \"gid\": 'V-61719'\n tag \"rid\": 'SV-76209r1_rule'\n tag \"stig_id\": 'O121-C2-013900'\n tag \"fix_id\": 'F-67635r1_fix'\n tag \"cci\": ['CCI-000205']\n tag \"nist\": ['IA-5 (1) (a)', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"If all user accounts are authenticated by the OS or an\n enterprise-level authentication/access mechanism, and not by Oracle, this is\n not a finding.\n\n For each profile that can be applied to accounts where authentication is under\n Oracle's control, determine the password verification function, if any, that is\n in use:\n\n SELECT * FROM SYS.DBA_PROFILES\n WHERE RESOURCE_NAME = 'PASSWORD_VERIFY_FUNCTION'\n [AND PROFILE NOT IN ()]\n ORDER BY PROFILE;\n\n Bearing in mind that a profile can inherit from another profile, and the root\n profile is called DEFAULT, determine the name of the password verification\n function effective for each profile.\n\n If, for any profile, the function name is null, this is a finding.\n\n For each password verification function, examine its source code.\n\n If it does not enforce the DoD-defined minimum length (15 unless otherwise\n specified), this is a finding.\"\n tag \"fix\": \"If all user accounts are authenticated by the OS or an\n enterprise-level authentication/access mechanism, and not by Oracle, no fix to\n the DBMS is required.\n\n If any user accounts are managed by Oracle: Develop, test and implement a\n password verification function that enforces DoD requirements.\n\n (Oracle supplies a sample function called ORA12C_STRONG_VERIFY_FUNCTION, in the\n script file\n /RDBMS/ADMIN/utlpwdmg.sql. This can be used as the starting point\n for a customized function.)\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n query = %{\n SELECT PROFILE, RESOURCE_NAME, LIMIT FROM DBA_PROFILES WHERE PROFILE =\n '%s' AND RESOURCE_NAME = 'PASSWORD_VERIFY_FUNCTION'\n }\n\n user_profiles = sql.query('SELECT profile FROM dba_users;').column('profile').uniq\n\n user_profiles.each do |profile|\n next if profile == \"RDSADMIN\"\n password_verify_function = sql.query(format(query, profile: profile)).column('limit')\n\n describe \"The oracle database account password verify function for profile: #{profile}\" do\n subject { password_verify_function }\n it { should_not eq ['NULL'] }\n end\n end\n if user_profiles.empty?\n describe 'There are no user profiles, therefore this control is NA' do\n skip 'There are no user profiles, therefore this control is NA'\n end\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61559.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61719.rb", "line": 1 }, - "id": "V-61559" + "id": "V-61719" }, { - "title": "Application user privilege assignment must be reviewed monthly or more\n frequently to ensure compliance with least privilege and documented policy.", - "desc": "Users granted privileges not required to perform their assigned\n functions are able to make unauthorized modifications to the production data or\n database. Monthly or more frequent periodic review of privilege assignments\n assures that organizational and/or functional changes are reflected\n appropriately.", + "title": "The DBMS must support enforcement of logical access restrictions\n associated with changes to the DBMS configuration and to the database itself.", + "desc": "When dealing with access restrictions pertaining to change control, it\n should be noted any changes to the hardware, software, and/or firmware\n components of the information system and/or application can have significant\n effects on the overall security of the system.\n\n Accordingly, only qualified and authorized individuals must be allowed to\n obtain access to application components for the purposes of initiating changes,\n including upgrades and modifications.\n\n Modifications to the DBMS settings, the database files, database\n configuration files, or the underlying database application files themselves\n could have catastrophic consequences to the database. Modification to DBMS\n settings could include turning off access controls to the database, the halting\n of archiving, the halting of auditing, and any number of other malicious\n actions.", "descriptions": { - "default": "Users granted privileges not required to perform their assigned\n functions are able to make unauthorized modifications to the production data or\n database. Monthly or more frequent periodic review of privilege assignments\n assures that organizational and/or functional changes are reflected\n appropriately." + "default": "When dealing with access restrictions pertaining to change control, it\n should be noted any changes to the hardware, software, and/or firmware\n components of the information system and/or application can have significant\n effects on the overall security of the system.\n\n Accordingly, only qualified and authorized individuals must be allowed to\n obtain access to application components for the purposes of initiating changes,\n including upgrades and modifications.\n\n Modifications to the DBMS settings, the database files, database\n configuration files, or the underlying database application files themselves\n could have catastrophic consequences to the database. Modification to DBMS\n settings could include turning off access controls to the database, the halting\n of archiving, the halting of auditing, and any number of other malicious\n actions." }, - "impact": 0.5, - "refs": [], + "impact": 0, + "refs": [ + { + "ref": [] + } + ], "tags": { - "gtitle": "SRG-APP-000516-DB-999900", - "gid": "V-61455", - "rid": "SV-75945r1_rule", - "stig_id": "O121-BP-023400", - "fix_id": "F-67371r1_fix", + "gtitle": "SRG-APP-000128-DB-000086", + "gid": "V-61671", + "rid": "SV-76161r1_rule", + "stig_id": "O121-C2-010300", + "fix_id": "F-67585r1_fix", "cci": [ - "CCI-000366" + "CCI-000345" ], "nist": [ - "CM-6 b", + "CM-5", "Rev_4" ], "false_negatives": null, @@ -4177,35 +4269,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Review policy, procedures and implementation evidence to\n determine if periodic reviews of user privileges by the ISSO are being\n performed.\n\n Evidence may consist of email or other correspondence that acknowledges receipt\n of periodic reports and notification of review between the DBA and ISSO or\n other auditors as assigned.\n\n If policy and procedures are incomplete or no evidence of implementation\n exists, this is a finding.", - "fix": "Develop, document and implement policy and procedures for\n periodic review of database user accounts and privilege assignments.\n\n Include methods to provide evidence of review in the procedures to verify\n reviews occur in accordance with the procedures." + "check": "Review DBMS settings and vendor documentation to ensure the\n database supports and does not interfere with enforcement of logical access\n restrictions associated with changes to the DBMS configuration and to the\n database itself.\n\n If the DBMS software in any way restricts the implementation of logical access\n controls implemented to protect its integrity or availability, this is a\n finding.", + "fix": "Configure the DBMS to allow implementation of logical access\n restrictions aimed at protecting the DBMS from unauthorized changes to its\n configuration and to the database itself.\n\n - - - - -\n When the Oracle Database is installed on a Unix-like operating system, the\n required umask is 022, and the file permissions are set so that any\n modifications to the startup files can only be performed by the owner of the\n software, a member of the group DBA, or the root user. Changing the umask has\n caused problems when patching the environment. If changes are to be made, they\n should be reverted to the status they were in before the modification for\n patching and upgrades." }, - "code": "control 'V-61455' do\n title \"Application user privilege assignment must be reviewed monthly or more\n frequently to ensure compliance with least privilege and documented policy.\"\n desc \"Users granted privileges not required to perform their assigned\n functions are able to make unauthorized modifications to the production data or\n database. Monthly or more frequent periodic review of privilege assignments\n assures that organizational and/or functional changes are reflected\n appropriately.\"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000516-DB-999900'\n tag \"gid\": 'V-61455'\n tag \"rid\": 'SV-75945r1_rule'\n tag \"stig_id\": 'O121-BP-023400'\n tag \"fix_id\": 'F-67371r1_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, procedures and implementation evidence to\n determine if periodic reviews of user privileges by the ISSO are being\n performed.\n\n Evidence may consist of email or other correspondence that acknowledges receipt\n of periodic reports and notification of review between the DBA and ISSO or\n other auditors as assigned.\n\n If policy and procedures are incomplete or no evidence of implementation\n exists, this is a finding.\"\n tag \"fix\": \"Develop, document and implement policy and procedures for\n periodic review of database user accounts and privilege assignments.\n\n Include methods to provide evidence of review in the procedures to verify\n reviews occur in accordance with the procedures.\"\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 application user privilege assignment are reviewed monthly or more frequently to ensure compliance with least privilege and documented policy. The database roles to review are: #{database_roles}\" do\n skip \"A manual review is required to ensure application user privilege assignment are reviewed monthly or more frequently to ensure compliance with least privilege and documented policy. The database roles to review are: #{database_roles}\"\n end\nend\n", + "code": " control 'V-61671' 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-61455.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61671.rb", "line": 1 }, - "id": "V-61455" + "id": "V-61671" }, { - "title": "Unused database components, DBMS software, and database objects must\n be removed.", - "desc": "Information systems are capable of providing a wide variety of\n functions and services. Some of the functions and services, provided by\n default, may not be necessary to support essential organizational operations\n (e.g., key missions, functions).\n\n It is detrimental for applications to provide, or install by default,\n functionality exceeding requirements or mission objectives. Examples include,\n but are not limited to, installing advertising software, demonstrations, or\n browser plug-ins not related to requirements or providing a wide array of\n functionality not required for the mission.\n\n Applications must adhere to the principles of least functionality by\n providing only essential capabilities.\n\n Demonstration and sample database objects and applications present publicly\n known attack points for malicious users. These demonstration and sample objects\n are meant to provide simple examples of coding specific functions and are not\n developed to prevent vulnerabilities from being introduced to the DBMS and host\n system.\n\n Unused and unnecessary DBMS components increase the attack vector for the\n DBMS by introducing additional targets for attack. By minimizing the services\n and applications installed on the system, the number of potential\n vulnerabilities is reduced.", + "title": "The DBMS must provide the ability to write specified audit record\n content to a centralized audit log repository.", + "desc": "Information system auditing capability is critical for accurate\n forensic analysis. Audit record content that may be necessary to satisfy the\n requirement of this control includes but is not limited: timestamps, source\n and destination IP addresses, user/process identifiers, event descriptions,\n application specific events, success/fail indications, file names involved,\n access control or flow control rules invoked.\n\n Centralized management of audit records and logs provides for efficiency in\n maintenance and management of records, as well as, the backup and archiving of\n those records. When organizations define application components requiring\n centralized audit log management, applications need to support that requirement.\n\n Database audit records not stored in a centralized audit log management\n tool may be overlooked during investigation of a security incident or may be\n subject to intentional or accidental manipulation by privileged users of the\n database.", "descriptions": { - "default": "Information systems are capable of providing a wide variety of\n functions and services. Some of the functions and services, provided by\n default, may not be necessary to support essential organizational operations\n (e.g., key missions, functions).\n\n It is detrimental for applications to provide, or install by default,\n functionality exceeding requirements or mission objectives. Examples include,\n but are not limited to, installing advertising software, demonstrations, or\n browser plug-ins not related to requirements or providing a wide array of\n functionality not required for the mission.\n\n Applications must adhere to the principles of least functionality by\n providing only essential capabilities.\n\n Demonstration and sample database objects and applications present publicly\n known attack points for malicious users. These demonstration and sample objects\n are meant to provide simple examples of coding specific functions and are not\n developed to prevent vulnerabilities from being introduced to the DBMS and host\n system.\n\n Unused and unnecessary DBMS components increase the attack vector for the\n DBMS by introducing additional targets for attack. By minimizing the services\n and applications installed on the system, the number of potential\n vulnerabilities is reduced." + "default": "Information system auditing capability is critical for accurate\n forensic analysis. Audit record content that may be necessary to satisfy the\n requirement of this control includes but is not limited: timestamps, source\n and destination IP addresses, user/process identifiers, event descriptions,\n application specific events, success/fail indications, file names involved,\n access control or flow control rules invoked.\n\n Centralized management of audit records and logs provides for efficiency in\n maintenance and management of records, as well as, the backup and archiving of\n those records. When organizations define application components requiring\n centralized audit log management, applications need to support that requirement.\n\n Database audit records not stored in a centralized audit log management\n tool may be overlooked during investigation of a security incident or may be\n subject to intentional or accidental manipulation by privileged users of the\n database." }, - "impact": 0, + "impact": 0.5, "refs": [], "tags": { - "gtitle": "SRG-APP-000141-DB-000091", - "gid": "V-61679", - "rid": "SV-76169r2_rule", - "stig_id": "O121-C2-011600", - "fix_id": "F-67593r2_fix", + "gtitle": "SRG-APP-000102-DB-000045", + "gid": "V-61871", + "rid": "SV-76361r1_rule", + "stig_id": "O121-P2-008100", + "fix_id": "F-67787r1_fix", "cci": [ - "CCI-000381" + "CCI-001844" ], "nist": [ - "CM-7 a", + "AU-3 (2)", "Rev_4" ], "false_negatives": null, @@ -4218,35 +4310,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Run this query to produce a list of components and features\n installed with the database:\n\n SELECT comp_id, comp_name, version, status from dba_registry\n where comp_id not in ('CATALOG','CATPROC','XDB');\n\n Review the list. If unused components are installed and are not documented and\n authorized, this is a finding.\n\n Starting with releases 11.1.0.7.x and above, all products are installed by\n default and the option to customize the product/component selection is no\n longer possible with the exception of those listed here:\n\n Oracle JVM,\n Oracle Text,\n Oracle Multimedia,\n Oracle OLAP,\n Oracle Spatial,\n Oracle Label Security,\n Oracle Application Express,\n Oracle Database Vault", - "fix": "If any components are required for operation of applications that\n will be accessing the DBMS, include them in the system documentation.\n\n One cannot remove components, either via Database Configuration Assistant\n (DBCA) or manually once the database has been created, either from a container\n or a non-container database.\n\n One can, however, use DBCA to create a non-container database and remove\n components during the creation process, before the database is created.\n\n When using DBCA to create a custom non-container database, select\n creation mode = advanced\n Database Template = Custom\n Database Options..Database Component.\n\n Components that can be selected or de-selected are:\n Oracle JVM, Oracle Text, Oracle Multimedia, Oracle OLAP, Oracle Spatial, Oracle\n Label Security, Oracle Application Express, Oracle Database Vault\n\n For a container database (CDB), the CDB$ROOT must have all possible database\n components available. This is because, when a pluggable database (PDB) is\n plugged into the CDB, the CDB must have the same components installed as the\n PDB. Since we do not know what components the PDBS may have, the CDB must be\n able to support all possible PDB configurations.\n\n Components installed in the CDB$ROOT do not need to be licensed. Components\n are only considered to be used if they are installed in the PDB.\n\n To configure a PDB to only use specific components, do the following:\n\n 1) Create a non-CDB 12.1 database and configure that database with the\n components desired.\n\n 2) Plug the non-CDB database into a CDB database, creating a new PDB. If\n wanted, can then create additional clones from the new PDB." + "check": "If the organization does not require the use of a centralized\n audit log repository, this is not a finding.\n\n If the organization requires the use of a centralized audit log repository,\n continue.\n\n Check that Oracle PL/SQL code or other software is in place to copy or transfer\n the specified audit record content to a centralized audit log repository. If\n it is not, this is a finding.\n\n Check that permissions are set on the Oracle audit trail tables and on the\n target repository to enable the required transfer of audit data. If they are\n not, this is a finding.\n\n Verify that the specified audit record content is indeed copied or transferred\n to the central repository. If it is not, this is a finding.", + "fix": "If the organization requires the use of a centralized audit log\n repository, employ PL/SQL code or other software to copy or transfer the\n specified audit record content to the repository.\n\n Ensure that permissions are set to enable transfer of the data.\n\n If, after the preceding steps, the transfer is not succeeding, diagnose and\n repair the problem.\n\n For more information on the configuration of auditing, refer to the following\n documents:\n \"Auditing Database Activity\" in the Oracle Database 2 Day + Security Guide:\n http://docs.oracle.com/database/121/TDPSG/tdpsg_auditing.htm#TDPSG50000\n \"Monitoring Database Activity with Auditing\" in the Oracle Database Security\n Guide:\n http://docs.oracle.com/database/121/DBSEG/part_6.htm#CCHEHCGI\n \"DBMS_AUDIT_MGMT\" in the Oracle Database PL/SQL Packages and Types Reference:\n http://docs.oracle.com/database/121/ARPLS/d_audit_mgmt.htm#ARPLS241" }, - "code": "control 'V-61679' do\n title \"Unused database components, DBMS software, and database objects must\n be removed.\"\n desc \"Information systems are capable of providing a wide variety of\n functions and services. Some of the functions and services, provided by\n default, may not be necessary to support essential organizational operations\n (e.g., key missions, functions).\n\n It is detrimental for applications to provide, or install by default,\n functionality exceeding requirements or mission objectives. Examples include,\n but are not limited to, installing advertising software, demonstrations, or\n browser plug-ins not related to requirements or providing a wide array of\n functionality not required for the mission.\n\n Applications must adhere to the principles of least functionality by\n providing only essential capabilities.\n\n Demonstration and sample database objects and applications present publicly\n known attack points for malicious users. These demonstration and sample objects\n are meant to provide simple examples of coding specific functions and are not\n developed to prevent vulnerabilities from being introduced to the DBMS and host\n system.\n\n Unused and unnecessary DBMS components increase the attack vector for the\n DBMS by introducing additional targets for attack. By minimizing the services\n and applications installed on the system, the number of potential\n vulnerabilities is reduced.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000141-DB-000091'\n tag \"gid\": 'V-61679'\n tag \"rid\": 'SV-76169r2_rule'\n tag \"stig_id\": 'O121-C2-011600'\n tag \"fix_id\": 'F-67593r2_fix'\n tag \"cci\": ['CCI-000381']\n tag \"nist\": ['CM-7 a', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Run this query to produce a list of components and features\n installed with the database:\n\n SELECT comp_id, comp_name, version, status from dba_registry\n where comp_id not in ('CATALOG','CATPROC','XDB');\n\n Review the list. If unused components are installed and are not documented and\n authorized, this is a finding.\n\n Starting with releases 11.1.0.7.x and above, all products are installed by\n default and the option to customize the product/component selection is no\n longer possible with the exception of those listed here:\n\n Oracle JVM,\n Oracle Text,\n Oracle Multimedia,\n Oracle OLAP,\n Oracle Spatial,\n Oracle Label Security,\n Oracle Application Express,\n Oracle Database Vault\"\n tag \"fix\": \"If any components are required for operation of applications that\n will be accessing the DBMS, include them in the system documentation.\n\n One cannot remove components, either via Database Configuration Assistant\n (DBCA) or manually once the database has been created, either from a container\n or a non-container database.\n\n One can, however, use DBCA to create a non-container database and remove\n components during the creation process, before the database is created.\n\n When using DBCA to create a custom non-container database, select\n creation mode = advanced\n Database Template = Custom\n Database Options..Database Component.\n\n Components that can be selected or de-selected are:\n Oracle JVM, Oracle Text, Oracle Multimedia, Oracle OLAP, Oracle Spatial, Oracle\n Label Security, Oracle Application Express, Oracle Database Vault\n\n For a container database (CDB), the CDB$ROOT must have all possible database\n components available. This is because, when a pluggable database (PDB) is\n plugged into the CDB, the CDB must have the same components installed as the\n PDB. Since we do not know what components the PDBS may have, the CDB must be\n able to support all possible PDB configurations.\n\n Components installed in the CDB$ROOT do not need to be licensed. Components\n are only considered to be used if they are installed in the PDB.\n\n To configure a PDB to only use specific components, do the following:\n\n 1) Create a non-CDB 12.1 database and configure that database with the\n components desired.\n\n 2) Plug the non-CDB database into a CDB database, creating a new PDB. If\n wanted, can then create additional clones from the new PDB.\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n list_of_installed_components = sql.query(\"SELECT comp_id, comp_name, version, status from dba_registry where comp_id not in ('CATALOG','CATPROC','XDB');\").column('comp_name').uniq\n if list_of_installed_components.empty?\n impact 0.0\n describe 'There are no oracle database components installed, control N/A' do\n skip 'TThere are no oracle database components installed, control N/A'\n end\n else\n list_of_installed_components.each do |component|\n describe \"The installed oracle database components: #{component}\" do\n subject { component }\n it { should be_in input('allowed_oracledb_components') }\n end\n end\n end\nend\n", + "code": "control 'V-61871' do\n title \"The DBMS must provide the ability to write specified audit record\n content to a centralized audit log repository.\"\n desc \"Information system auditing capability is critical for accurate\n forensic analysis. Audit record content that may be necessary to satisfy the\n requirement of this control includes but is not limited: timestamps, source\n and destination IP addresses, user/process identifiers, event descriptions,\n application specific events, success/fail indications, file names involved,\n access control or flow control rules invoked.\n\n Centralized management of audit records and logs provides for efficiency in\n maintenance and management of records, as well as, the backup and archiving of\n those records. When organizations define application components requiring\n centralized audit log management, applications need to support that requirement.\n\n Database audit records not stored in a centralized audit log management\n tool may be overlooked during investigation of a security incident or may be\n subject to intentional or accidental manipulation by privileged users of the\n database.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000102-DB-000045'\n tag \"gid\": 'V-61871'\n tag \"rid\": 'SV-76361r1_rule'\n tag \"stig_id\": 'O121-P2-008100'\n tag \"fix_id\": 'F-67787r1_fix'\n tag \"cci\": ['CCI-001844']\n tag \"nist\": ['AU-3 (2)', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"If the organization does not require the use of a centralized\n audit log repository, this is not a finding.\n\n If the organization requires the use of a centralized audit log repository,\n continue.\n\n Check that Oracle PL/SQL code or other software is in place to copy or transfer\n the specified audit record content to a centralized audit log repository. If\n it is not, this is a finding.\n\n Check that permissions are set on the Oracle audit trail tables and on the\n target repository to enable the required transfer of audit data. If they are\n not, this is a finding.\n\n Verify that the specified audit record content is indeed copied or transferred\n to the central repository. If it is not, this is a finding.\"\n tag \"fix\": \"If the organization requires the use of a centralized audit log\n repository, employ PL/SQL code or other software to copy or transfer the\n specified audit record content to the repository.\n\n Ensure that permissions are set to enable transfer of the data.\n\n If, after the preceding steps, the transfer is not succeeding, diagnose and\n repair the problem.\n\n For more information on the configuration of auditing, refer to the following\n documents:\n \\\"Auditing Database Activity\\\" in the Oracle Database 2 Day + Security Guide:\n http://docs.oracle.com/database/121/TDPSG/tdpsg_auditing.htm#TDPSG50000\n \\\"Monitoring Database Activity with Auditing\\\" in the Oracle Database Security\n Guide:\n http://docs.oracle.com/database/121/DBSEG/part_6.htm#CCHEHCGI\n \\\"DBMS_AUDIT_MGMT\\\" in the Oracle Database PL/SQL Packages and Types Reference:\n http://docs.oracle.com/database/121/ARPLS/d_audit_mgmt.htm#ARPLS241\"\n describe 'A manual review is required to ensure the DBMS provides the ability to write specified audit record\n content to a centralized audit log repository' do\n skip 'A manual review is required to ensure the DBMS provides the ability to write specified audit record\n content to a centralized audit log repository'\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61679.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61871.rb", "line": 1 }, - "id": "V-61679" + "id": "V-61871" }, { - "title": "The DBMS must restrict error messages so only authorized personnel may\n view them.", - "desc": "If the application provides too much information in error logs and\n administrative messages to the screen, this could lead to compromise. The\n structure and content of error messages need to be carefully considered by the\n organization and development team. The extent to which the information system\n is able to identify and handle error conditions is guided by organizational\n policy and operational requirements.\n\n Some default DBMS error messages can contain information that could aid an\n attacker in, among others things, identifying the database type, host address,\n or state of the database. Custom errors may contain sensitive customer\n information. It is important that error messages are displayed only to those\n who are authorized to view them.\n\n This calls for inspection of application source code, which will require\n collaboration with the application developers. It is recognized that in many\n cases, the database administrator (DBA) is organizationally separate from the\n application developers and may have limited, if any, access to source code.\n Nevertheless, protections of this type are so important to the secure operation\n of databases that they must not be ignored. At a minimum, the DBA must attempt\n to obtain assurances from the development organization that this issue has been\n addressed and must document what has been discovered.", + "title": "Only authorized system accounts must have the SYSTEM tablespace\n specified as the default tablespace.", + "desc": "The Oracle SYSTEM tablespace is used by the database to store all DBMS\n system objects. Other use of the system tablespace may compromise system\n availability and the effectiveness of host system access controls to the\n tablespace files.", "descriptions": { - "default": "If the application provides too much information in error logs and\n administrative messages to the screen, this could lead to compromise. The\n structure and content of error messages need to be carefully considered by the\n organization and development team. The extent to which the information system\n is able to identify and handle error conditions is guided by organizational\n policy and operational requirements.\n\n Some default DBMS error messages can contain information that could aid an\n attacker in, among others things, identifying the database type, host address,\n or state of the database. Custom errors may contain sensitive customer\n information. It is important that error messages are displayed only to those\n who are authorized to view them.\n\n This calls for inspection of application source code, which will require\n collaboration with the application developers. It is recognized that in many\n cases, the database administrator (DBA) is organizationally separate from the\n application developers and may have limited, if any, access to source code.\n Nevertheless, protections of this type are so important to the secure operation\n of databases that they must not be ignored. At a minimum, the DBA must attempt\n to obtain assurances from the development organization that this issue has been\n addressed and must document what has been discovered." + "default": "The Oracle SYSTEM tablespace is used by the database to store all DBMS\n system objects. Other use of the system tablespace may compromise system\n availability and the effectiveness of host system access controls to the\n tablespace files." }, - "impact": 0.5, + "impact": 0, "refs": [], "tags": { - "gtitle": "SRG-APP-000267-DB-000163", - "gid": "V-61793", - "rid": "SV-76283r2_rule", - "stig_id": "O121-C2-020000", - "fix_id": "F-67709r2_fix", + "gtitle": "SRG-APP-000516-DB-999900", + "gid": "V-61459", + "rid": "SV-75949r2_rule", + "stig_id": "O121-BP-023600", + "fix_id": "F-67375r2_fix", "cci": [ - "CCI-001314" + "CCI-000366" ], "nist": [ - "SI-11 b", + "CM-6 b", "Rev_4" ], "false_negatives": null, @@ -4259,39 +4351,39 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Check DBMS settings and custom database code to determine if\n error messages are ever displayed to unauthorized individuals:\n\n i) Review all end-user-facing applications that use the database, to determine\n whether they display any DBMS-generated error messages to general users. If\n they do, this is a finding.\n\n ii) Review whether the database is accessible to users who are not authorized\n system administrators or database administrators, via the following types of\n software:\n iia) Oracle SQL*Plus\n iib) Reporting and analysis tools\n iic) Database management and/or development tools, such as, but not limited to,\n Toad.\n iid) Application development tools, such as, but not limited to, Oracle\n JDeveloper, Microsoft Visual Studio, PowerBuilder, or Eclipse.\n\n If the answer to the preceding question (iia through iid) is Yes, inquire\n whether, for each role or individual with respect to each tool, this access is\n required to enable the user(s) to perform authorized job duties. If No, this\n is a finding. If Yes, continue:\n\n For each tool in use, determine whether it is capable of suppressing\n DBMS-generated error messages, and if it is, whether it is configured to do so.\n\n Determine whether the role or individual, with respect to each tool, needs to\n see detailed DBMS-generated error messages.\n\n If No, and if the tool is not configured to suppress such messages, this is a\n finding.\n\n If Yes, determine whether the role/user's need to see such messages is\n documented in the System Security Plan. If so, this is not a finding. If not,\n this is a finding.", - "fix": "i) For each end-user-facing application that displays\n DBMS-generated error messages, configure or recode it to suppress these\n messages.\n\n If the application is coded in Oracle PL/SQL, the EXCEPTION block can be used\n to suppress or divert error messages. Most other programming languages provide\n comparable facilities, such as TRY ... CATCH.\n\n ii) For each unauthorized user of each tool, remove the ability to access it.\n For each tool where access to DBMS error messages is not required and can be\n configured, suppress the messages. For each role/user that needs access to the\n error messages, or needs a tool where the messages cannot be suppressed,\n document the need in the system security plan." + "check": "Run the query:\n\n select property_name, property_value\n from database_properties\n where property_name in\n ('DEFAULT_PERMANENT_TABLESPACE','DEFAULT_TEMP_TABLESPACE');\n\n If either value is set to SYSTEM, this is a finding.\n\n Run the query:\n\n select username from dba_users\n where (default_tablespace = 'SYSTEM' or temporary_tablespace = 'SYSTEM')\n and username not in\n ('LBACSYS','OUTLN','SYS','SYSTEM');\n\n If any non-default account records are returned, this is a finding.", + "fix": "Create and dedicate tablespaces to support only one application.\n\n Do not share tablespaces between applications.\n\n Do not grant quotas to application object owners on tablespaces not dedicated\n to their associated application.\n\n Run the queries:\n\n alter database default tablespace ;\n alter database default temporary tablespace ;\n\n alter user default tablespace temporary tablespace\n ;\n\n Replace with the named user account.\n Replace with the new default tablespace name.\n Replace with the new default temporary tablespace\n name (typically TEMP).\n Repeat the \"alter user\" for each affected user account." }, - "code": "control 'V-61793' do\n title \"The DBMS must restrict error messages so only authorized personnel may\n view them.\"\n desc \"If the application provides too much information in error logs and\n administrative messages to the screen, this could lead to compromise. The\n structure and content of error messages need to be carefully considered by the\n organization and development team. The extent to which the information system\n is able to identify and handle error conditions is guided by organizational\n policy and operational requirements.\n\n Some default DBMS error messages can contain information that could aid an\n attacker in, among others things, identifying the database type, host address,\n or state of the database. Custom errors may contain sensitive customer\n information. It is important that error messages are displayed only to those\n who are authorized to view them.\n\n This calls for inspection of application source code, which will require\n collaboration with the application developers. It is recognized that in many\n cases, the database administrator (DBA) is organizationally separate from the\n application developers and may have limited, if any, access to source code.\n Nevertheless, protections of this type are so important to the secure operation\n of databases that they must not be ignored. At a minimum, the DBA must attempt\n to obtain assurances from the development organization that this issue has been\n addressed and must document what has been discovered.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000267-DB-000163'\n tag \"gid\": 'V-61793'\n tag \"rid\": 'SV-76283r2_rule'\n tag \"stig_id\": 'O121-C2-020000'\n tag \"fix_id\": 'F-67709r2_fix'\n tag \"cci\": ['CCI-001314']\n tag \"nist\": ['SI-11 b', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Check DBMS settings and custom database code to determine if\n error messages are ever displayed to unauthorized individuals:\n\n i) Review all end-user-facing applications that use the database, to determine\n whether they display any DBMS-generated error messages to general users. If\n they do, this is a finding.\n\n ii) Review whether the database is accessible to users who are not authorized\n system administrators or database administrators, via the following types of\n software:\n iia) Oracle SQL*Plus\n iib) Reporting and analysis tools\n iic) Database management and/or development tools, such as, but not limited to,\n Toad.\n iid) Application development tools, such as, but not limited to, Oracle\n JDeveloper, Microsoft Visual Studio, PowerBuilder, or Eclipse.\n\n If the answer to the preceding question (iia through iid) is Yes, inquire\n whether, for each role or individual with respect to each tool, this access is\n required to enable the user(s) to perform authorized job duties. If No, this\n is a finding. If Yes, continue:\n\n For each tool in use, determine whether it is capable of suppressing\n DBMS-generated error messages, and if it is, whether it is configured to do so.\n\n Determine whether the role or individual, with respect to each tool, needs to\n see detailed DBMS-generated error messages.\n\n If No, and if the tool is not configured to suppress such messages, this is a\n finding.\n\n If Yes, determine whether the role/user's need to see such messages is\n documented in the System Security Plan. If so, this is not a finding. If not,\n this is a finding.\"\n tag \"fix\": \"i) For each end-user-facing application that displays\n DBMS-generated error messages, configure or recode it to suppress these\n messages.\n\n If the application is coded in Oracle PL/SQL, the EXCEPTION block can be used\n to suppress or divert error messages. Most other programming languages provide\n comparable facilities, such as TRY ... CATCH.\n\n ii) For each unauthorized user of each tool, remove the ability to access it.\n For each tool where access to DBMS error messages is not required and can be\n configured, suppress the messages. For each role/user that needs access to the\n error messages, or needs a tool where the messages cannot be suppressed,\n document the need in the system security plan.\"\n describe 'A manual review is required to ensure the DBMS restricts error messages so only authorized personnel may\n view them' do\n skip 'A manual review is required to ensure the DBMS restricts error messages so only authorized personnel may\n view them'\n end\nend\n", + "code": "control 'V-61459' do\n title \"Only authorized system accounts must have the SYSTEM tablespace\n specified as the default tablespace.\"\n desc \"The Oracle SYSTEM tablespace is used by the database to store all DBMS\n system objects. Other use of the system tablespace may compromise system\n availability and the effectiveness of host system access controls to the\n tablespace files.\"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000516-DB-999900'\n tag \"gid\": 'V-61459'\n tag \"rid\": 'SV-75949r2_rule'\n tag \"stig_id\": 'O121-BP-023600'\n tag \"fix_id\": 'F-67375r2_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 query:\n\n select property_name, property_value\n from database_properties\n where property_name in\n ('DEFAULT_PERMANENT_TABLESPACE','DEFAULT_TEMP_TABLESPACE');\n\n If either value is set to SYSTEM, this is a finding.\n\n Run the query:\n\n select username from dba_users\n where (default_tablespace = 'SYSTEM' or temporary_tablespace = 'SYSTEM')\n and username not in\n ('LBACSYS','OUTLN','SYS','SYSTEM');\n\n If any non-default account records are returned, this is a finding.\"\n tag \"fix\": \"Create and dedicate tablespaces to support only one application.\n\n Do not share tablespaces between applications.\n\n Do not grant quotas to application object owners on tablespaces not dedicated\n to their associated application.\n\n Run the queries:\n\n alter database default tablespace ;\n alter database default temporary tablespace ;\n\n alter user default tablespace temporary tablespace\n ;\n\n Replace with the named user account.\n Replace with the new default tablespace name.\n Replace with the new default temporary tablespace\n name (typically TEMP).\n Repeat the \\\"alter user\\\" for each affected user account.\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n property_name = sql.query(\"select property_name\n from database_properties\n where property_name in\n ('DEFAULT_PERMANENT_TABLESPACE','DEFAULT_TEMP_TABLESPACE');\").column('property_name')\n\n describe 'The oracle database property_name' do\n subject { property_name }\n it { should_not include 'SYSTEM' }\n end\n\n property_value = sql.query(\"select property_value\n from database_properties\n where property_name in\n ('DEFAULT_PERMANENT_TABLESPACE','DEFAULT_TEMP_TABLESPACE');\").column('property_value')\n\n describe 'The oracle database property_value' do\n subject { property_value }\n it { should_not include 'SYSTEM' }\n end\n\n users_with_system_tablespace = sql.query(\"select username from dba_users\n where (default_tablespace = 'SYSTEM' or temporary_tablespace = 'SYSTEM')\n and username not in\n ('LBACSYS','OUTLN','SYS','SYSTEM');\").column('username').uniq\n if users_with_system_tablespace.empty?\n impact 0.0\n describe 'There are no oracle users granted system tablespace, therefore control N/A' do\n skip 'There are no oracle users granted system tablespace, therefore control N/A'\n end\n else\n users_with_system_tablespace.each do |user|\n describe \"oracle users with system tablespace: #{user}\" do\n subject { user }\n it { should be_in input('allowed_users_system_tablespace') }\n end\n end\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61793.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61459.rb", "line": 1 }, - "id": "V-61793" + "id": "V-61459" }, { - "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": "Remote DBMS administration must be documented and authorized or\n disabled.", + "desc": "Remote administration may expose configuration and sensitive data to\n unauthorized viewing during transit across the network or allow unauthorized\n administrative access to the DBMS to remote users.\n\n For the purposes of this STIG, \"Remote\" means \"outside the DoDIN.\"\n However, use of an approved and properly configured VPN counts as inside the\n DoDIN.", "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": "Remote administration may expose configuration and sensitive data to\n unauthorized viewing during transit across the network or allow unauthorized\n administrative access to the DBMS to remote users.\n\n For the purposes of this STIG, \"Remote\" means \"outside the DoDIN.\"\n However, use of an approved and properly configured VPN counts as inside the\n DoDIN." }, - "impact": 0.5, + "impact": 0, "refs": [ { "ref": [] } ], "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-000516-DB-999900", + "gid": "V-61523", + "rid": "SV-76013r3_rule", + "stig_id": "O121-BP-026000", + "fix_id": "F-67439r4_fix", "cci": [ - "CCI-000195" + "CCI-000366" ], "nist": [ - "IA-5 (1) (b)", + "CM-6 b", "Rev_4" ], "false_negatives": null, @@ -4304,39 +4396,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 the System Security Plan for authorization, assignments\n and usage procedures for remote DBMS administration.\n\n If remote administration of the DBMS is not documented or poorly documented,\n this is a finding.\n\n If remote administration of the DBMS is not authorized and not disabled, this\n is a finding.\n\n If remote administration is to be performed from outside the DoDIN, but is not\n done via an approved and properly configured VPN, this is a finding.", + "fix": "Disable remote administration of the DBMS where not required.\n\n Where remote administration of the DBMS is required, develop, document and\n implement policy and procedures on its use.\n\n Assign remote administration privileges to ISSO-authorized personnel only.\n\n Document assignments in the System Security Plan.\n\n Where remote administration is to be performed from outside the DoDIN,\n configure an approved VPN client for this purpose." }, - "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-61523' 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-61731.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61523.rb", "line": 1 }, - "id": "V-61731" + "id": "V-61523" }, { - "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.", + "title": "Database backup procedures must be defined, documented, and\n implemented.", + "desc": "Information system backup is a critical step in maintaining data\n assurance and availability.\n\n User-level information is data generated by information system and/or\n application users. In order to assure availability of this data in the event of\n a system failure, DoD organizations are required to ensure user-generated data\n is backed up at a defined frequency. This includes data stored on file systems,\n within databases or within any other storage media.\n\n Applications performing backups must be capable of backing up user-level\n information per the DoD-defined frequency.\n\n Database backups provide the required means to restore databases after\n compromise or loss. Backups help reduce the vulnerability to unauthorized\n access or hardware loss.", "descriptions": { - "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." + "default": "Information system backup is a critical step in maintaining data\n assurance and availability.\n\n User-level information is data generated by information system and/or\n application users. In order to assure availability of this data in the event of\n a system failure, DoD organizations are required to ensure user-generated data\n is backed up at a defined frequency. This includes data stored on file systems,\n within databases or within any other storage media.\n\n Applications performing backups must be capable of backing up user-level\n information per the DoD-defined frequency.\n\n Database backups provide the required means to restore databases after\n compromise or loss. Backups help reduce the vulnerability to unauthorized\n access or hardware loss." }, - "impact": 0, - "refs": [ - { - "ref": [] - } - ], + "impact": 0.5, + "refs": [], "tags": { - "gtitle": "SRG-APP-000516-DB-999900", - "gid": "V-61511", - "rid": "SV-76001r1_rule", - "stig_id": "O121-BP-025400", - "fix_id": "F-67427r1_fix", + "gtitle": "SRG-APP-000145-DB-000096", + "gid": "V-61695", + "rid": "SV-76185r1_rule", + "stig_id": "O121-C2-012300", + "fix_id": "F-67611r1_fix", "cci": [ - "CCI-000366" + "CCI-000535" ], "nist": [ - "CM-6 b", + "CP-9 (a)", "Rev_4" ], "false_negatives": null, @@ -4349,35 +4437,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "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." + "check": "Review the database backup procedures and implementation\n evidence. Evidence of implementation includes records of backup events and\n physical review of backup media.\n\n Evidence should match the backup plan as recorded in the system documentation.\n\n If backup procedures do not exist or are not implemented in accordance with the\n procedures, this is a finding.\n\n - - - - -\n The Oracle recommended process for backup and recovery is Oracle RMAN. If\n Oracle RMAN is deployed, execute the following commands to ensure that the\n evidence of the implementation of the backup policy includes validating that\n the files are restorable:\n\n Validating Database Files with BACKUP VALIDATE\n --Use the BACKUP VALIDATE command to do the following:\n --Check datafiles for physical and logical block corruption\n --Confirm that all database files exist and are in the correct locations\n --When BACKUP VALIDATE is run, RMAN reads the files to be backed up in their\n entirety, as it would during a real backup. RMAN does not, however, actually\n produce any backup sets or image copies.\n --Cannot use the BACKUPSET, MAXCORRUPT, or PROXY parameters with BACKUP\n VALIDATE.\n --To validate files with the BACKUP VALIDATE command:\n 1. Start RMAN and connect to a target database and recovery catalog (if used).\n 2. Run the BACKUP VALIDATE command.\n\n For example, can validate that all database files and archived logs can be\n backed up by running a command as shown in the following example. This command\n checks for physical corruptions only.\n\n BACKUP VALIDATE\n DATABASE\n ARCHIVELOG ALL;\n\n To check for logical corruptions in addition to physical corruptions, run the\n following variation of the preceding command:\n\n BACKUP VALIDATE\n CHECK LOGICAL\n DATABASE\n ARCHIVELOG ALL;\n\n In the preceding examples, the RMAN client displays the same output that it\n would if it were really backing up the files. If RMAN cannot back up one or\n more of the files, then it issues an error message.\n\n Validating Backups Before Restoring Them\n\n Run RESTORE ... VALIDATE to test whether RMAN can restore a specific file or\n set of files from a backup. RMAN chooses which backups to use. The database\n must be mounted or open for this command. Do not have to take datafiles\n off-line when validating the restore of datafiles, because validation of\n backups of the datafiles only reads the backups and does not affect the\n production datafiles. When validating files on disk or tape, RMAN reads all\n blocks in the backup piece or image copy. RMAN also validates off-site backups.\n The validation is identical to a real restore operation except that RMAN does\n not write output files.\n\n To validate backups with the RESTORE command:\n 1. Run the RESTORE command with the VALIDATE option.\n\n This following example illustrates validating the restore of the database and\n all archived redo logs:\n\n RESTORE DATABASE VALIDATE;\n RESTORE ARCHIVELOG ALL VALIDATE;\n\n If an RMAN error stack is not generated, then skip the subsequent steps. The\n lack of error messages means that RMAN had confirmed that it can use these\n backups successfully during a real restore and recovery.\n\n 2. If error messages are seen in the output and one is the RMAN-06026 message,\n then investigate the cause of the problem. If possible, correct the problem\n that is preventing RMAN from validating the backups and retry the validation.\n The following error means that RMAN cannot restore one or more of the specified\n files from available backups:\n\n RMAN-06026: some targets not found - aborting restore\n The following sample output shows that RMAN encountered a problem reading the\n specified backup:\n\n RMAN-03009: failure of restore command on c1 channel at 12-DEC-14 23:22:30\n ORA-19505: failed to identify file \"oracle/dbs/1fafv9gl_1_1\"\n ORA-27037: unable to obtain file status\n SVR4 Error: 2: No such file or directory\n Additional information: 3", + "fix": "Develop, document, and implement database backup procedures." }, - "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", + "code": "control 'V-61695' do\n title \"Database backup procedures must be defined, documented, and\n implemented.\"\n desc \"Information system backup is a critical step in maintaining data\n assurance and availability.\n\n User-level information is data generated by information system and/or\n application users. In order to assure availability of this data in the event of\n a system failure, DoD organizations are required to ensure user-generated data\n is backed up at a defined frequency. This includes data stored on file systems,\n within databases or within any other storage media.\n\n Applications performing backups must be capable of backing up user-level\n information per the DoD-defined frequency.\n\n Database backups provide the required means to restore databases after\n compromise or loss. Backups help reduce the vulnerability to unauthorized\n access or hardware loss.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000145-DB-000096'\n tag \"gid\": 'V-61695'\n tag \"rid\": 'SV-76185r1_rule'\n tag \"stig_id\": 'O121-C2-012300'\n tag \"fix_id\": 'F-67611r1_fix'\n tag \"cci\": ['CCI-000535']\n tag \"nist\": ['CP-9 (a)', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Review the database backup procedures and implementation\n evidence. Evidence of implementation includes records of backup events and\n physical review of backup media.\n\n Evidence should match the backup plan as recorded in the system documentation.\n\n If backup procedures do not exist or are not implemented in accordance with the\n procedures, this is a finding.\n\n - - - - -\n The Oracle recommended process for backup and recovery is Oracle RMAN. If\n Oracle RMAN is deployed, execute the following commands to ensure that the\n evidence of the implementation of the backup policy includes validating that\n the files are restorable:\n\n Validating Database Files with BACKUP VALIDATE\n --Use the BACKUP VALIDATE command to do the following:\n --Check datafiles for physical and logical block corruption\n --Confirm that all database files exist and are in the correct locations\n --When BACKUP VALIDATE is run, RMAN reads the files to be backed up in their\n entirety, as it would during a real backup. RMAN does not, however, actually\n produce any backup sets or image copies.\n --Cannot use the BACKUPSET, MAXCORRUPT, or PROXY parameters with BACKUP\n VALIDATE.\n --To validate files with the BACKUP VALIDATE command:\n 1. Start RMAN and connect to a target database and recovery catalog (if used).\n 2. Run the BACKUP VALIDATE command.\n\n For example, can validate that all database files and archived logs can be\n backed up by running a command as shown in the following example. This command\n checks for physical corruptions only.\n\n BACKUP VALIDATE\n DATABASE\n ARCHIVELOG ALL;\n\n To check for logical corruptions in addition to physical corruptions, run the\n following variation of the preceding command:\n\n BACKUP VALIDATE\n CHECK LOGICAL\n DATABASE\n ARCHIVELOG ALL;\n\n In the preceding examples, the RMAN client displays the same output that it\n would if it were really backing up the files. If RMAN cannot back up one or\n more of the files, then it issues an error message.\n\n Validating Backups Before Restoring Them\n\n Run RESTORE ... VALIDATE to test whether RMAN can restore a specific file or\n set of files from a backup. RMAN chooses which backups to use. The database\n must be mounted or open for this command. Do not have to take datafiles\n off-line when validating the restore of datafiles, because validation of\n backups of the datafiles only reads the backups and does not affect the\n production datafiles. When validating files on disk or tape, RMAN reads all\n blocks in the backup piece or image copy. RMAN also validates off-site backups.\n The validation is identical to a real restore operation except that RMAN does\n not write output files.\n\n To validate backups with the RESTORE command:\n 1. Run the RESTORE command with the VALIDATE option.\n\n This following example illustrates validating the restore of the database and\n all archived redo logs:\n\n RESTORE DATABASE VALIDATE;\n RESTORE ARCHIVELOG ALL VALIDATE;\n\n If an RMAN error stack is not generated, then skip the subsequent steps. The\n lack of error messages means that RMAN had confirmed that it can use these\n backups successfully during a real restore and recovery.\n\n 2. If error messages are seen in the output and one is the RMAN-06026 message,\n then investigate the cause of the problem. If possible, correct the problem\n that is preventing RMAN from validating the backups and retry the validation.\n The following error means that RMAN cannot restore one or more of the specified\n files from available backups:\n\n RMAN-06026: some targets not found - aborting restore\n The following sample output shows that RMAN encountered a problem reading the\n specified backup:\n\n RMAN-03009: failure of restore command on c1 channel at 12-DEC-14 23:22:30\n ORA-19505: failed to identify file \\\"oracle/dbs/1fafv9gl_1_1\\\"\n ORA-27037: unable to obtain file status\n SVR4 Error: 2: No such file or directory\n Additional information: 3\"\n tag \"fix\": 'Develop, document, and implement database backup procedures.'\n describe 'A manual review is required to ensure database backup procedures are defined, documented, and\n implemented.' do\n skip 'A manual review is required to ensure database backup procedures are defined, documented, and\n implemented.'\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61511.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61695.rb", "line": 1 }, - "id": "V-61511" + "id": "V-61695" }, { - "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": "The DBMS must automatically audit account creation.", + "desc": "Once an attacker establishes initial access to a system, they often\n attempt to create a persistent method of re-establishing access. One way to\n accomplish this is for the attacker to simply create a new account.\n\n Auditing of account creation is one method and best practice for mitigating\n this risk. A comprehensive account management process will ensure an audit\n trail documents the creation of application user accounts and, as required,\n notifies administrators and/or application owners that they exist. Such a\n process greatly reduces the risk that accounts will be surreptitiously created\n and provides logging that can be used for forensic purposes.\n\n Note that user authentication and account management should be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP.\n\n However, notwithstanding how accounts are managed, Oracle auditing should\n always be configured to capture account creation.", "descriptions": { - "default": "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": "Once an attacker establishes initial access to a system, they often\n attempt to create a persistent method of re-establishing access. One way to\n accomplish this is for the attacker to simply create a new account.\n\n Auditing of account creation is one method and best practice for mitigating\n this risk. A comprehensive account management process will ensure an audit\n trail documents the creation of application user accounts and, as required,\n notifies administrators and/or application owners that they exist. Such a\n process greatly reduces the risk that accounts will be surreptitiously created\n and provides logging that can be used for forensic purposes.\n\n Note that user authentication and account management should be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP.\n\n However, notwithstanding how accounts are managed, Oracle auditing should\n always be configured to capture account creation." }, "impact": 0.5, "refs": [], "tags": { - "gtitle": "SRG-APP-000516-DB-999900", - "gid": "V-61497", - "rid": "SV-75987r1_rule", - "stig_id": "O121-BP-024600", - "fix_id": "F-67413r1_fix", + "gtitle": "SRG-APP-000026-DB-000005", + "gid": "V-61565", + "rid": "SV-76055r2_rule", + "stig_id": "O121-C2-002200", + "fix_id": "F-67481r2_fix", "cci": [ - "CCI-000366" + "CCI-000018" ], "nist": [ - "CM-6 b", + "AC-2 (4)", "Rev_4" ], "false_negatives": null, @@ -4390,30 +4478,30 @@ "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": "Check Oracle settings (and also OS settings and/or\n enterprise-level authentication/access mechanisms settings) to determine if\n account creation is being audited. If account creation is not being audited by\n Oracle, this is a finding.\n\n If Standard Auditing is used:\n To see if Oracle is configured to capture audit data, enter the following\n SQL*Plus command:\n SHOW PARAMETER AUDIT_TRAIL\n or the following SQL query:\n SELECT * FROM SYS.V$PARAMETER WHERE NAME = 'audit_trail';\n If Oracle returns the value 'NONE', this is a finding.\n\n If Unified Auditing is used:\n To see if Oracle is configured to capture audit data including account\n creation, enter the following SQL*Plus command:\n SELECT ' Account creation is not being audited. '\n FROM dual\n WHERE (SELECT Count(*)\n FROM (select policy_name , audit_option from audit_unified_policies\n WHERE audit_option = 'CREATE USER'\n and policy_name in (select policy_name from\n audit_unified_enabled_policies where user_name='ALL USERS'))) = 0\n OR (SELECT value\n FROM v$option\n WHERE parameter = 'Unified Auditing') != 'TRUE';\n\n If Oracle returns \"no rows selected\", this is not a finding.", + "fix": "Configure Oracle to audit account creation activities.\n\n If Standard Auditing is used:\n Use this process to ensure auditable events are captured:\n ALTER SYSTEM SET AUDIT_TRAIL= SCOPE=SPFILE;\n Audit trail type can be 'OS', 'DB', 'DB,EXTENDED', 'XML' or 'XML,EXTENDED'.\n After executing this statement, it may be necessary to shut down and restart\n the Oracle database.\n\n If Unified Auditing is used:\n To ensure auditable events are captured:\n Link the oracle binary with uniaud_on, and then restart the database. Oracle\n Database Upgrade Guide describes how to enable unified auditing. Reference\n V-61625 for information on how to configure a policy to audit account creation.\n\n For more information on the configuration of auditing, refer to the following\n documents:\n \"Auditing Database Activity\" in the Oracle Database 2 Day + Security Guide:\n http://docs.oracle.com/database/121/TDPSG/tdpsg_auditing.htm#TDPSG50000\n \"Monitoring Database Activity with Auditing\" in the Oracle Database Security\n Guide:\n http://docs.oracle.com/database/121/DBSEG/part_6.htm#CCHEHCGI\n \"DBMS_AUDIT_MGMT\" in the Oracle Database PL/SQL Packages and Types Reference:\n http://docs.oracle.com/database/121/ARPLS/d_audit_mgmt.htm#ARPLS241\n Oracle Database Upgrade Guide:\n http://docs.oracle.com/database/121/UPGRD/afterup.htm#UPGRD52810" }, - "code": "control 'V-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-61565' do\n title 'The DBMS must automatically audit account creation.'\n desc \"Once an attacker establishes initial access to a system, they often\n attempt to create a persistent method of re-establishing access. One way to\n accomplish this is for the attacker to simply create a new account.\n\n Auditing of account creation is one method and best practice for mitigating\n this risk. A comprehensive account management process will ensure an audit\n trail documents the creation of application user accounts and, as required,\n notifies administrators and/or application owners that they exist. Such a\n process greatly reduces the risk that accounts will be surreptitiously created\n and provides logging that can be used for forensic purposes.\n\n Note that user authentication and account management should be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP.\n\n However, notwithstanding how accounts are managed, Oracle auditing should\n always be configured to capture account creation.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000026-DB-000005'\n tag \"gid\": 'V-61565'\n tag \"rid\": 'SV-76055r2_rule'\n tag \"stig_id\": 'O121-C2-002200'\n tag \"fix_id\": 'F-67481r2_fix'\n tag \"cci\": ['CCI-000018']\n tag \"nist\": ['AC-2 (4)', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Check Oracle settings (and also OS settings and/or\n enterprise-level authentication/access mechanisms settings) to determine if\n account creation is being audited. If account creation is not being audited by\n Oracle, this is a finding.\n\n If Standard Auditing is used:\n To see if Oracle is configured to capture audit data, enter the following\n SQL*Plus command:\n SHOW PARAMETER AUDIT_TRAIL\n or the following SQL query:\n SELECT * FROM SYS.V$PARAMETER WHERE NAME = 'audit_trail';\n If Oracle returns the value 'NONE', this is a finding.\n\n If Unified Auditing is used:\n To see if Oracle is configured to capture audit data including account\n creation, enter the following SQL*Plus command:\n SELECT ' Account creation is not being audited. '\n FROM dual\n WHERE (SELECT Count(*)\n FROM (select policy_name , audit_option from audit_unified_policies\n WHERE audit_option = 'CREATE USER'\n and policy_name in (select policy_name from\n audit_unified_enabled_policies where user_name='ALL USERS'))) = 0\n OR (SELECT value\n FROM v$option\n WHERE parameter = 'Unified Auditing') != 'TRUE';\n\n If Oracle returns \\\"no rows selected\\\", this is not a finding.\"\n tag \"fix\": \"Configure Oracle to audit account creation activities.\n\n If Standard Auditing is used:\n Use this process to ensure auditable events are captured:\n ALTER SYSTEM SET AUDIT_TRAIL= SCOPE=SPFILE;\n Audit trail type can be 'OS', 'DB', 'DB,EXTENDED', 'XML' or 'XML,EXTENDED'.\n After executing this statement, it may be necessary to shut down and restart\n the Oracle database.\n\n If Unified Auditing is used:\n To ensure auditable events are captured:\n Link the oracle binary with uniaud_on, and then restart the database. Oracle\n Database Upgrade Guide describes how to enable unified auditing. Reference\n V-61625 for information on how to configure a policy to audit account creation.\n\n For more information on the configuration of auditing, refer to the following\n documents:\n \\\"Auditing Database Activity\\\" in the Oracle Database 2 Day + Security Guide:\n http://docs.oracle.com/database/121/TDPSG/tdpsg_auditing.htm#TDPSG50000\n \\\"Monitoring Database Activity with Auditing\\\" in the Oracle Database Security\n Guide:\n http://docs.oracle.com/database/121/DBSEG/part_6.htm#CCHEHCGI\n \\\"DBMS_AUDIT_MGMT\\\" in the Oracle Database PL/SQL Packages and Types Reference:\n http://docs.oracle.com/database/121/ARPLS/d_audit_mgmt.htm#ARPLS241\n Oracle Database Upgrade Guide:\n http://docs.oracle.com/database/121/UPGRD/afterup.htm#UPGRD52810\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n standard_auditing_used = input('standard_auditing_used')\n unified_auditing_used = input('unified_auditing_used')\n\n describe.one do\n describe 'Standard auditing is in use for audit purposes' do\n subject { standard_auditing_used }\n it { should be true }\n end\n\n describe 'Unified auditing is in use for audit purposes' do\n subject { unified_auditing_used }\n it { should be true }\n end\n end\n\n audit_trail = sql.query(\"select value from v$parameter where name = 'audit_trail';\").column('value')\n\n if standard_auditing_used\n describe 'The oracle database audit_trail parameter' do\n subject { audit_trail }\n it { should_not cmp 'NONE' }\n end\n end\n\n unified_auditing = sql.query(\"SELECT value FROM V$OPTION WHERE PARAMETER = 'Unified Auditing';\").column('value')\n\n if unified_auditing_used\n describe 'The oracle database unified auditing parameter' do\n subject { unified_auditing }\n it { should_not cmp 'FALSE' }\n end\n\n unified_auditing_events = sql.query(\"SELECT ' Account creation is not being audited. '\n FROM dual\n WHERE (SELECT Count(*)\n FROM (select policy_name , audit_option from audit_unified_policies\n WHERE audit_option = 'CREATE USER'\n and policy_name in (select policy_name from\n audit_unified_enabled_policies where user_name='ALL USERS'))) = 0\n OR (SELECT value\n FROM v$option\n WHERE parameter = 'Unified Auditing') != 'TRUE';\").column('Account creation is not being audited.').uniq\n\n describe 'The unified auditing data capture for account creation' do\n subject { unified_auditing_events.to_s }\n it { should_not cmp '[nil]' }\n end\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61497.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61565.rb", "line": 1 }, - "id": "V-61497" + "id": "V-61565" }, { - "title": "DBMS symmetric keys must be protected in accordance with NSA or\n NIST-approved key management technology or processes.", - "desc": "Symmetric keys used for encryption protect data from unauthorized\n access. However, if not protected in accordance with acceptable standards, the\n keys themselves may be compromised and used for unauthorized data access.", + "title": "Application role permissions must not be assigned to the Oracle PUBLIC\n role.", + "desc": "Permissions granted to PUBLIC are granted to all users of the\n database. Custom roles must be used to assign application permissions to\n functional groups of application users. The installation of Oracle does not\n assign role permissions to PUBLIC.", "descriptions": { - "default": "Symmetric keys used for encryption protect data from unauthorized\n access. However, if not protected in accordance with acceptable standards, the\n keys themselves may be compromised and used for unauthorized data access." + "default": "Permissions granted to PUBLIC are granted to all users of the\n database. Custom roles must be used to assign application permissions to\n functional groups of application users. The installation of Oracle does not\n assign role permissions to PUBLIC." }, "impact": 0.5, "refs": [], "tags": { "gtitle": "SRG-APP-000516-DB-999900", - "gid": "V-61525", - "rid": "SV-76015r1_rule", - "stig_id": "O121-BP-026100", - "fix_id": "F-67441r1_fix", + "gid": "V-61443", + "rid": "SV-75933r1_rule", + "stig_id": "O121-BP-022800", + "fix_id": "F-67359r1_fix", "cci": [ "CCI-000366" ], @@ -4431,35 +4519,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "If the symmetric key management procedures and configuration\n settings for the DBMS are not specified in the System Security Plan, this is a\n finding.\n\n If the procedures are not followed, with evidence for audit, this is a finding.\n\n Note: This check does not include a review of the key management procedures\n for validity. Specific key management requirements may be covered under\n separate checks.", - "fix": "Implement the following for symmetric and other encryption keys:\n - protection from unauthorized access in transit and in storage\n - utilization of accepted algorithms\n - generation in accordance with required standards for the key's use\n - expiration date\n - continuity - key backup and recovery\n - key change\n - archival key storage (as necessary)\n\n Details for key management requirements are provided by FIPS 140-2 key\n management standards available from NIST." + "check": "From SQL*Plus:\n\n select granted_role from dba_role_privs where grantee = 'PUBLIC';\n\n If any roles are listed, this is a finding.", + "fix": "Revoke role grants from PUBLIC.\n\n Do not assign role privileges to PUBLIC.\n\n From SQL*Plus:\n\n revoke [role name] from PUBLIC;" }, - "code": "control 'V-61525' do\n title \"DBMS symmetric keys must be protected in accordance with NSA or\n NIST-approved key management technology or processes.\"\n desc \"Symmetric keys used for encryption protect data from unauthorized\n access. However, if not protected in accordance with acceptable standards, the\n keys themselves may be compromised and used for unauthorized data access.\"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000516-DB-999900'\n tag \"gid\": 'V-61525'\n tag \"rid\": 'SV-76015r1_rule'\n tag \"stig_id\": 'O121-BP-026100'\n tag \"fix_id\": 'F-67441r1_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 symmetric key management procedures and configuration\n settings for the DBMS are not specified in the System Security Plan, this is a\n finding.\n\n If the procedures are not followed, with evidence for audit, this is a finding.\n\n Note: This check does not include a review of the key management procedures\n for validity. Specific key management requirements may be covered under\n separate checks.\"\n tag \"fix\": \"Implement the following for symmetric and other encryption keys:\n - protection from unauthorized access in transit and in storage\n - utilization of accepted algorithms\n - generation in accordance with required standards for the key's use\n - expiration date\n - continuity - key backup and recovery\n - key change\n - archival key storage (as necessary)\n\n Details for key management requirements are provided by FIPS 140-2 key\n management standards available from NIST.\"\n describe 'A manual review is required to ensure the DBMS symmetric keys are protected in accordance with NSA or\n NIST-approved key management technology or processes.' do\n skip 'A manual review is required to ensure the DBMS symmetric keys are protected in accordance with NSA or\n NIST-approved key management technology or processes.'\n end\nend\n", + "code": "control 'V-61443' do\n title \"Application role permissions must not be assigned to the Oracle PUBLIC\n role.\"\n desc \"Permissions granted to PUBLIC are granted to all users of the\n database. Custom roles must be used to assign application permissions to\n functional groups of application users. The installation of Oracle does not\n assign role permissions to PUBLIC.\"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000516-DB-999900'\n tag \"gid\": 'V-61443'\n tag \"rid\": 'SV-75933r1_rule'\n tag \"stig_id\": 'O121-BP-022800'\n tag \"fix_id\": 'F-67359r1_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 granted_role from dba_role_privs where grantee = 'PUBLIC';\n\n If any roles are listed, this is a finding.\"\n tag \"fix\": \"Revoke role grants from PUBLIC.\n\n Do not assign role privileges to PUBLIC.\n\n From SQL*Plus:\n\n revoke [role name] from PUBLIC;\"\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 granted_role from dba_role_privs where grantee = 'PUBLIC';\").row(0).column('granted_role') do\n its('value') { should be_empty }\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61525.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61443.rb", "line": 1 }, - "id": "V-61525" + "id": "V-61443" }, { - "title": "The Oracle REMOTE_OS_ROLES parameter must be set to FALSE.", - "desc": "Setting REMOTE_OS_ROLES to TRUE allows operating system groups to\n control Oracle roles. The default value of FALSE causes roles to be identified\n and managed by the database. If REMOTE_OS_ROLES is set to TRUE, a remote user\n could impersonate another operating system user over a network connection.", + "title": "The DBMS must support organizational requirements to encrypt\n information stored in the database and information extracted or derived from\n the database and stored on digital media.", + "desc": "When data is written to digital media, such as hard drives, mobile\n computers, external/removable hard drives, personal digital assistants,\n flash/thumb drives, etc., there is risk of data loss and/or compromise.\n\n An organizational assessment of risk guides the selection of media and\n associated information contained on that media requiring restricted access.\n Organizations need to document in policy and procedures the media requiring\n restricted access, individuals authorized to access the media, and the specific\n measures taken to restrict access.\n\n Fewer protection measures are needed for media containing information\n determined by the organization to be in the public domain, to be publicly\n releasable, or to have limited or no adverse impact if accessed by other than\n authorized personnel. In these situations, it is assumed the physical access\n controls where the media resides provide adequate protection.\n\n As part of a defense-in-depth strategy, the organization considers\n routinely encrypting information at rest on selected secondary storage devices.\n The decision whether to employ cryptography is the responsibility of the\n information owner/steward, who exercises discretion within the framework of\n applicable rules, policies, and law. The selection of the cryptographic\n mechanisms used is based upon maintaining the confidentiality and integrity of\n the information.\n\n The strength of mechanisms is commensurate with the classification and\n sensitivity of the information.\n\n Information at rest, when not encrypted, is open to compromise from\n attackers who have gained unauthorized access to the data files.", "descriptions": { - "default": "Setting REMOTE_OS_ROLES to TRUE allows operating system groups to\n control Oracle roles. The default value of FALSE causes roles to be identified\n and managed by the database. If REMOTE_OS_ROLES is set to TRUE, a remote user\n could impersonate another operating system user over a network connection." + "default": "When data is written to digital media, such as hard drives, mobile\n computers, external/removable hard drives, personal digital assistants,\n flash/thumb drives, etc., there is risk of data loss and/or compromise.\n\n An organizational assessment of risk guides the selection of media and\n associated information contained on that media requiring restricted access.\n Organizations need to document in policy and procedures the media requiring\n restricted access, individuals authorized to access the media, and the specific\n measures taken to restrict access.\n\n Fewer protection measures are needed for media containing information\n determined by the organization to be in the public domain, to be publicly\n releasable, or to have limited or no adverse impact if accessed by other than\n authorized personnel. In these situations, it is assumed the physical access\n controls where the media resides provide adequate protection.\n\n As part of a defense-in-depth strategy, the organization considers\n routinely encrypting information at rest on selected secondary storage devices.\n The decision whether to employ cryptography is the responsibility of the\n information owner/steward, who exercises discretion within the framework of\n applicable rules, policies, and law. The selection of the cryptographic\n mechanisms used is based upon maintaining the confidentiality and integrity of\n the information.\n\n The strength of mechanisms is commensurate with the classification and\n sensitivity of the information.\n\n Information at rest, when not encrypted, is open to compromise from\n attackers who have gained unauthorized access to the data files." }, - "impact": 0.7, + "impact": 0.5, "refs": [], "tags": { - "gtitle": "SRG-APP-000516-DB-999900", - "gid": "V-61427", - "rid": "SV-75917r1_rule", - "stig_id": "O121-BP-022000", - "fix_id": "F-67343r1_fix", + "gtitle": "SRG-APP-000188-DB-000121", + "gid": "V-61755", + "rid": "SV-76245r2_rule", + "stig_id": "O121-C2-016400", + "fix_id": "F-67671r1_fix", "cci": [ - "CCI-000366" + "CCI-002262" ], "nist": [ - "CM-6 b", + "AC-16 a", "Rev_4" ], "false_negatives": null, @@ -4472,35 +4560,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "From SQL*Plus:\n\n select value from v$parameter where name = 'remote_os_roles';\n\n If the returned value is not FALSE or not documented in the System Security\n Plan as required, this is a finding.", - "fix": "Document remote OS roles in the System Security Plan.\n\n If not required, disable use of remote OS roles.\n\n From SQL*Plus:\n\n alter system set remote_os_roles = FALSE scope = spfile;\n\n The above SQL*Plus command will set the parameter to take effect at next system\n startup." + "check": "If encryption is not required for the database and data derived\n from it, this is not a finding.\n\n Review DBMS settings to determine whether data stored on the database is\n encrypted according to organizational requirements.\n\n If not, this is a finding.\n\n Check the following settings to see if FIPS 140-2 encryption is configured. If\n encryption is not configured, check with the DBA and SYSTEM Administrator to\n see if other mechanisms or third-party products are deployed to encrypt data\n stored in the database.\n\n To see if Oracle is configured for FIPS 140-2 Transparent Data Encryption\n and/or DBMS_CRYPTO, enter the following SQL*Plus command:\n SHOW PARAMETER DBFIPS_140\n or the following SQL query:\n SELECT * FROM SYS.V$PARAMETER WHERE NAME = 'DBFIPS_140';\n 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 SELECT * FROM V$ENCRYPTED_TABLESPACES;\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 SELECT * FROM DBA_ENCRYPTED_COLUMNS;\n If no rows are returned, then there are no encrypted columns within existing\n tables.\n\n Note: For the Solaris platform, when DBFIPS_140 is FALSE, TDE (but not\n DBMS_CRYPTO) can still operate\n in a FIPS 140-compliant manner if FIPS 140 operation is enabled for the Solaris\n Cryptographic Framework.", + "fix": "Configure cryptographic functions to use FIPS 140-2-compliant\n algorithms and hashing functions.\n\n Configure the DBMS and/or the OS to encrypt data at rest according to the\n requirements of the organization.\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-61427' do\n title 'The Oracle REMOTE_OS_ROLES parameter must be set to FALSE.'\n desc \"Setting REMOTE_OS_ROLES to TRUE allows operating system groups to\n control Oracle roles. The default value of FALSE causes roles to be identified\n and managed by the database. If REMOTE_OS_ROLES is set to TRUE, a remote user\n could impersonate another operating system user over a network connection.\"\n impact 0.7\n tag \"gtitle\": 'SRG-APP-000516-DB-999900'\n tag \"gid\": 'V-61427'\n tag \"rid\": 'SV-75917r1_rule'\n tag \"stig_id\": 'O121-BP-022000'\n tag \"fix_id\": 'F-67343r1_fix'\n tag \"cci\": ['CCI-000366']\n tag \"nist\": ['CM-6 b', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"From SQL*Plus:\n\n select value from v$parameter where name = 'remote_os_roles';\n\n If the returned value is not FALSE or not documented in the System Security\n Plan as required, this is a finding.\"\n tag \"fix\": \"Document remote OS roles in the System Security Plan.\n\n If not required, disable use of remote OS roles.\n\n From SQL*Plus:\n\n alter system set remote_os_roles = FALSE scope = spfile;\n\n The above SQL*Plus command will set the parameter to take effect at next system\n startup.\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n parameter = sql.query(\"select value from v$parameter where name = 'remote_os_roles';\").column('value')\n\n describe 'The oracle database REMOTE_OS_ROLES parameter' do\n subject { parameter }\n it { should cmp 'FALSE' }\n end\nend\n", + "code": "control 'V-61755' do\n title \"The DBMS must support organizational requirements to encrypt\n information stored in the database and information extracted or derived from\n the database and stored on digital media.\"\n desc \"When data is written to digital media, such as hard drives, mobile\n computers, external/removable hard drives, personal digital assistants,\n flash/thumb drives, etc., there is risk of data loss and/or compromise.\n\n An organizational assessment of risk guides the selection of media and\n associated information contained on that media requiring restricted access.\n Organizations need to document in policy and procedures the media requiring\n restricted access, individuals authorized to access the media, and the specific\n measures taken to restrict access.\n\n Fewer protection measures are needed for media containing information\n determined by the organization to be in the public domain, to be publicly\n releasable, or to have limited or no adverse impact if accessed by other than\n authorized personnel. In these situations, it is assumed the physical access\n controls where the media resides provide adequate protection.\n\n As part of a defense-in-depth strategy, the organization considers\n routinely encrypting information at rest on selected secondary storage devices.\n The decision whether to employ cryptography is the responsibility of the\n information owner/steward, who exercises discretion within the framework of\n applicable rules, policies, and law. The selection of the cryptographic\n mechanisms used is based upon maintaining the confidentiality and integrity of\n the information.\n\n The strength of mechanisms is commensurate with the classification and\n sensitivity of the information.\n\n Information at rest, when not encrypted, is open to compromise from\n attackers who have gained unauthorized access to the data files.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000188-DB-000121'\n tag \"gid\": 'V-61755'\n tag \"rid\": 'SV-76245r2_rule'\n tag \"stig_id\": 'O121-C2-016400'\n tag \"fix_id\": 'F-67671r1_fix'\n tag \"cci\": ['CCI-002262']\n tag \"nist\": ['AC-16 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 encryption is not required for the database and data derived\n from it, this is not a finding.\n\n Review DBMS settings to determine whether data stored on the database is\n encrypted according to organizational requirements.\n\n If not, this is a finding.\n\n Check the following settings to see if FIPS 140-2 encryption is configured. If\n encryption is not configured, check with the DBA and SYSTEM Administrator to\n see if other mechanisms or third-party products are deployed to encrypt data\n stored in the database.\n\n To see if Oracle is configured for FIPS 140-2 Transparent Data Encryption\n and/or DBMS_CRYPTO, enter the following SQL*Plus command:\n SHOW PARAMETER DBFIPS_140\n or the following SQL query:\n SELECT * FROM SYS.V$PARAMETER WHERE NAME = 'DBFIPS_140';\n 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 SELECT * FROM V$ENCRYPTED_TABLESPACES;\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 SELECT * FROM DBA_ENCRYPTED_COLUMNS;\n If no rows are returned, then there are no encrypted columns within existing\n tables.\n\n Note: For the Solaris platform, when DBFIPS_140 is FALSE, TDE (but not\n DBMS_CRYPTO) can still operate\n in a FIPS 140-compliant manner if FIPS 140 operation is enabled for the Solaris\n Cryptographic Framework.\"\n tag \"fix\": \"Configure cryptographic functions to use FIPS 140-2-compliant\n algorithms and hashing functions.\n\n Configure the DBMS and/or the OS to encrypt data at rest according to the\n requirements of the organization.\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\"\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", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61427.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61755.rb", "line": 1 }, - "id": "V-61427" + "id": "V-61755" }, { - "title": "Application object owner accounts must be disabled when not performing\n installation or maintenance actions.", - "desc": "Object ownership provides all database object permissions to the owned\n object. Access to the application object owner accounts requires special\n protection to prevent unauthorized access and use of the object ownership\n privileges. In addition to the high privileges to application objects assigned\n to this account, it is also an account that, by definition, is not accessed\n interactively except for application installation and maintenance. This reduced\n access to the account means that unauthorized access to the account could go\n undetected. To help protect the account, it must be enabled only when access is\n required.", + "title": "The DBMS must ensure users are authenticated with an individual\n authenticator prior to using a shared authenticator.", + "desc": "To assure individual accountability and prevent unauthorized access,\n application users (and any processes acting on behalf of users) must be\n individually identified and authenticated.\n\n A shared authenticator is a generic account used by multiple individuals.\n Use of a shared authenticator alone does not uniquely identify individual\n users. An example of a shared authenticator is the UNIX OS 'root' user account,\n a Windows 'administrator' account, an 'SA' account, or a 'helpdesk' account.\n\n For example, the UNIX and Windows operating systems offer a 'switch user'\n capability allowing users to authenticate with their individual credentials\n and, when needed, 'switch' to the administrator role. This method provides for\n unique individual authentication prior to using a shared authenticator.\n\n Some applications may not have the need to provide a group authenticator;\n this is considered a matter of application design. In those instances where the\n application design includes the use of a shared authenticator, this requirement\n will apply.\n\n There may also be instances when specific user actions need to be performed\n on the information system without unique user identification or authentication.\n An example of this type of access is a web server which contains publicly\n releasable information. These types of accesses are allowed but must be\n explicitly identified and documented by the organization.\n\n When shared accounts are utilized without another means of identifying\n individual users, users may deny having performed a particular action.", "descriptions": { - "default": "Object ownership provides all database object permissions to the owned\n object. Access to the application object owner accounts requires special\n protection to prevent unauthorized access and use of the object ownership\n privileges. In addition to the high privileges to application objects assigned\n to this account, it is also an account that, by definition, is not accessed\n interactively except for application installation and maintenance. This reduced\n access to the account means that unauthorized access to the account could go\n undetected. To help protect the account, it must be enabled only when access is\n required." + "default": "To assure individual accountability and prevent unauthorized access,\n application users (and any processes acting on behalf of users) must be\n individually identified and authenticated.\n\n A shared authenticator is a generic account used by multiple individuals.\n Use of a shared authenticator alone does not uniquely identify individual\n users. An example of a shared authenticator is the UNIX OS 'root' user account,\n a Windows 'administrator' account, an 'SA' account, or a 'helpdesk' account.\n\n For example, the UNIX and Windows operating systems offer a 'switch user'\n capability allowing users to authenticate with their individual credentials\n and, when needed, 'switch' to the administrator role. This method provides for\n unique individual authentication prior to using a shared authenticator.\n\n Some applications may not have the need to provide a group authenticator;\n this is considered a matter of application design. In those instances where the\n application design includes the use of a shared authenticator, this requirement\n will apply.\n\n There may also be instances when specific user actions need to be performed\n on the information system without unique user identification or authentication.\n An example of this type of access is a web server which contains publicly\n releasable information. These types of accesses are allowed but must be\n explicitly identified and documented by the organization.\n\n When shared accounts are utilized without another means of identifying\n individual users, users may deny having performed a particular action." }, - "impact": 0, + "impact": 0.5, "refs": [], "tags": { - "gtitle": "SRG-APP-000516-DB-999900", - "gid": "V-61467", - "rid": "SV-75957r4_rule", - "stig_id": "O121-BP-024000", - "fix_id": "F-67383r1_fix", + "gtitle": "SRG-APP-000153-DB-000108", + "gid": "V-61711", + "rid": "SV-76201r1_rule", + "stig_id": "O121-C2-013300", + "fix_id": "F-67627r1_fix", "cci": [ - "CCI-000366" + "CCI-000770" ], "nist": [ - "CM-6 b", + "IA-2 (5)", "Rev_4" ], "false_negatives": null, @@ -4513,35 +4601,39 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Run the SQL query:\n\n select distinct o.owner from dba_objects o, dba_users u\n where o.owner not in\n (\n \n )\n and o.object_type <> 'SYNONYM'\n and o.owner = username\n and upper(account_status) not like '%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 To obtain a list of users assigned DBA privileges, run the query:\n\n select grantee from dba_role_privs where granted_role = 'DBA';\n\n If any records are returned, then verify the account is an authorized\n application object owner account or a default account installed to support an\n Oracle product.\n\n Verify that any objects owned by custom DBA accounts are for the personal use\n of that DBA.\n\n If any objects are used to support applications or any functions other than DBA\n functions, this is a finding.\n\n Any unauthorized object owner accounts are not a finding under this check as\n they are noted as findings under check O121-C2-011000.\n\n Any other accounts listed are a finding.", - "fix": "Disable any application object owner accounts.\n\n From SQL*Plus:\n alter user [username] account lock;\n\n Enable application object owner accounts only for installation and maintenance.\n\n DBAs are special purpose accounts and do not require disabling although they\n may own objects.\n\n For application objects that require routine maintenance, e.g. index objects,\n to maintain performance, consider allowing a special purpose account to own the\n index or enable the application owner account for the duration of the routine\n maintenance function only." + "check": "Review DBMS settings, OS settings, and/or enterprise-level\n authentication/access mechanism settings to determine whether shared accounts\n exist. If group accounts do not exist, this is NA.\n\n Review DBMS settings to determine if individual authentication is required\n before shared authentication.\n\n If shared authentication does not require prior individual authentication, this\n is a finding.\n\n (Oracle Access Manager may be helpful in meeting this requirement. Notes on\n Oracle Access Manager follow.)\n\n Oracle Access Manager is used when there is a need for multifactor\n authentication of applications front-ending Oracle Datasets that may use group\n accounts. Oracle Access Manager supports using PKI-based smart cards (CAC, PIV)\n for multifactor authentication. When a user authenticates to a smart card\n application, the smart card engine produces a certificate-based authentication\n token. Can configure a certificate-based authentication scheme in Oracle Access\n Manager that uses information from the smart card certificate.\n Certificate-based authentication works with any smart card or similar device\n that presents an X.509 certificate.\n\n Check:\n First, check that the Authentication Module is set up properly:\n 1) Go to Oracle Access Manager Home Screen and click the Policy Configuration\n tab. Select the X509Scheme.\n 2) Make sure the Authentication Module option is set to X509Plugin.\n\n Second, check that the Authentication policy is using the x509Scheme:\n 1) Go to Oracle Access Manager Home Screen and click the Policy Configuration\n tab.\n 2) Select Application Domains. Select Search.\n 3) Select the application domain protecting the Oracle Database.\n 4) Select the Authentication Polices tab and Click Protected Resource Policy.\n 5) Make sure the Authentication Scheme is set to x509Scheme.", + "fix": "Configure DBMS, OS and/or enterprise-level authentication/access\n mechanism to require individual authentication prior to authentication for\n shared account access.\n\n If appropriate, install Oracle Access Manager to provide multifactor\n authentication of applications front-ending Oracle Databases and using shared\n accounts. After installation, use x509 Authentication modules provided out of\n the box." }, - "code": "control 'V-61467' do\n title \"Application object owner accounts must be disabled when not performing\n installation or maintenance actions.\"\n desc \"Object ownership provides all database object permissions to the owned\n object. Access to the application object owner accounts requires special\n protection to prevent unauthorized access and use of the object ownership\n privileges. In addition to the high privileges to application objects assigned\n to this account, it is also an account that, by definition, is not accessed\n interactively except for application installation and maintenance. This reduced\n access to the account means that unauthorized access to the account could go\n undetected. To help protect the account, it must be enabled only when access is\n required.\"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000516-DB-999900'\n tag \"gid\": 'V-61467'\n tag \"rid\": 'SV-75957r4_rule'\n tag \"stig_id\": 'O121-BP-024000'\n tag \"fix_id\": 'F-67383r1_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 distinct o.owner from dba_objects o, dba_users u\n where o.owner not in\n (\n \n )\n and o.object_type <> 'SYNONYM'\n and o.owner = username\n and upper(account_status) not like '%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 To obtain a list of users assigned DBA privileges, run the query:\n\n select grantee from dba_role_privs where granted_role = 'DBA';\n\n If any records are returned, then verify the account is an authorized\n application object owner account or a default account installed to support an\n Oracle product.\n\n Verify that any objects owned by custom DBA accounts are for the personal use\n of that DBA.\n\n If any objects are used to support applications or any functions other than DBA\n functions, this is a finding.\n\n Any unauthorized object owner accounts are not a finding under this check as\n they are noted as findings under check O121-C2-011000.\n\n Any other accounts listed are a finding.\"\n tag \"fix\": \"Disable any application object owner accounts.\n\n From SQL*Plus:\n alter user [username] account lock;\n\n Enable application object owner accounts only for installation and maintenance.\n\n DBAs are special purpose accounts and do not require disabling although they\n may own objects.\n\n For application objects that require routine maintenance, e.g. index objects,\n to maintain performance, consider allowing a special purpose account to own the\n index or enable the application owner account for the duration of the routine\n maintenance function only.\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n dba_users = sql.query(\"select grantee from dba_sys_privs\n where admin_option = 'YES' and grantee not in (select grantee from dba_role_privs where granted_role = 'DBA');\").column('grantee').uniq\n if dba_users.empty?\n impact 0.0\n describe 'There are no oracle DBA users, control N/A' do\n skip 'There are no oracle DBA users, control N/A'\n end\n else\n dba_users.each do |user|\n describe \"oracle DBA users: #{user}\" do\n subject { user }\n it { should be_in input('allowed_dbadmin_users') }\n end\n end\n end\n\n unlocked_accounts = sql.query(\"select distinct o.owner from dba_objects o, dba_users u\n where\n o.object_type <> 'SYNONYM'\n and o.owner = username\n and upper(account_status) not like '%LOCKED%';\").column('owner').uniq\n if unlocked_accounts.empty?\n impact 0.0\n describe 'There are no unlocked oracle accounts, control N/A' do\n skip 'There are no unlocked oracle accounts, control N/A'\n end\n else\n unlocked_accounts.each do |user|\n describe \"oracle user: #{user}\" do\n subject { user }\n it { should be_in input('allowed_unlocked_oracledb_accounts') }\n end\n end\n end\nend\n", + "code": "control 'V-61711' do\n title \"The DBMS must ensure users are authenticated with an individual\n authenticator prior to using a shared authenticator.\"\n desc \"To assure individual accountability and prevent unauthorized access,\n application users (and any processes acting on behalf of users) must be\n individually identified and authenticated.\n\n A shared authenticator is a generic account used by multiple individuals.\n Use of a shared authenticator alone does not uniquely identify individual\n users. An example of a shared authenticator is the UNIX OS 'root' user account,\n a Windows 'administrator' account, an 'SA' account, or a 'helpdesk' account.\n\n For example, the UNIX and Windows operating systems offer a 'switch user'\n capability allowing users to authenticate with their individual credentials\n and, when needed, 'switch' to the administrator role. This method provides for\n unique individual authentication prior to using a shared authenticator.\n\n Some applications may not have the need to provide a group authenticator;\n this is considered a matter of application design. In those instances where the\n application design includes the use of a shared authenticator, this requirement\n will apply.\n\n There may also be instances when specific user actions need to be performed\n on the information system without unique user identification or authentication.\n An example of this type of access is a web server which contains publicly\n releasable information. These types of accesses are allowed but must be\n explicitly identified and documented by the organization.\n\n When shared accounts are utilized without another means of identifying\n individual users, users may deny having performed a particular action.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000153-DB-000108'\n tag \"gid\": 'V-61711'\n tag \"rid\": 'SV-76201r1_rule'\n tag \"stig_id\": 'O121-C2-013300'\n tag \"fix_id\": 'F-67627r1_fix'\n tag \"cci\": ['CCI-000770']\n tag \"nist\": ['IA-2 (5)', '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 to determine whether shared accounts\n exist. If group accounts do not exist, this is NA.\n\n Review DBMS settings to determine if individual authentication is required\n before shared authentication.\n\n If shared authentication does not require prior individual authentication, this\n is a finding.\n\n (Oracle Access Manager may be helpful in meeting this requirement. Notes on\n Oracle Access Manager follow.)\n\n Oracle Access Manager is used when there is a need for multifactor\n authentication of applications front-ending Oracle Datasets that may use group\n accounts. Oracle Access Manager supports using PKI-based smart cards (CAC, PIV)\n for multifactor authentication. When a user authenticates to a smart card\n application, the smart card engine produces a certificate-based authentication\n token. Can configure a certificate-based authentication scheme in Oracle Access\n Manager that uses information from the smart card certificate.\n Certificate-based authentication works with any smart card or similar device\n that presents an X.509 certificate.\n\n Check:\n First, check that the Authentication Module is set up properly:\n 1) Go to Oracle Access Manager Home Screen and click the Policy Configuration\n tab. Select the X509Scheme.\n 2) Make sure the Authentication Module option is set to X509Plugin.\n\n Second, check that the Authentication policy is using the x509Scheme:\n 1) Go to Oracle Access Manager Home Screen and click the Policy Configuration\n tab.\n 2) Select Application Domains. Select Search.\n 3) Select the application domain protecting the Oracle Database.\n 4) Select the Authentication Polices tab and Click Protected Resource Policy.\n 5) Make sure the Authentication Scheme is set to x509Scheme.\"\n tag \"fix\": \"Configure DBMS, OS and/or enterprise-level authentication/access\n mechanism to require individual authentication prior to authentication for\n shared account access.\n\n If appropriate, install Oracle Access Manager to provide multifactor\n authentication of applications front-ending Oracle Databases and using shared\n accounts. After installation, use x509 Authentication modules provided out of\n the box.\"\n describe 'A manual review is required to ensure the DBMS ensures users are authenticated with an individual\n authenticator prior to using a shared authenticator' do\n skip 'A manual review is required to ensure the DBMS ensures users are authenticated with an individual\n authenticator prior to using a shared authenticator'\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61467.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61711.rb", "line": 1 }, - "id": "V-61467" + "id": "V-61711" }, { - "title": "The DBMS must protect against an individual who uses a shared account\n falsely denying having performed a particular action.", - "desc": "Non-repudiation of actions taken is required in order to maintain\n application integrity. Examples of particular actions taken by individuals\n include creating information, sending a message, approving information (e.g.,\n indicating concurrence or signing a contract), and receiving a message.\n\n Non-repudiation protects individuals against later claims by an author of\n not having authored a particular document, a sender of not having transmitted a\n message, a receiver of not having received a message, or a signatory of not\n having signed a document.\n\n Authentication via shared accounts does not provide individual\n accountability for actions taken on the DBMS or data. Whenever a single\n database account is used to connect to the database, a secondary authentication\n method that provides individual accountability is required. This scenario most\n frequently occurs when an externally hosted application authenticates\n individual users to the application and the application uses a single account\n to retrieve or update database information on behalf of the individual users.\n\n When shared accounts are utilized without another means of identifying\n individual users, users may deny having performed a particular action.\n\n This calls for inspection of application source code, which will require\n collaboration with the application developers. It is recognized that in many\n cases, the database administrator (DBA) is organizationally separate from the\n application developers and may have limited, if any, access to source code.\n Nevertheless, protections of this type are so important to the secure operation\n of databases that they must not be ignored. At a minimum, the DBA must attempt\n to obtain assurances from the development organization that this issue has been\n addressed and must document what has been discovered.", + "title": "The DBMS must use 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": "Non-repudiation of actions taken is required in order to maintain\n application integrity. Examples of particular actions taken by individuals\n include creating information, sending a message, approving information (e.g.,\n indicating concurrence or signing a contract), and receiving a message.\n\n Non-repudiation protects individuals against later claims by an author of\n not having authored a particular document, a sender of not having transmitted a\n message, a receiver of not having received a message, or a signatory of not\n having signed a document.\n\n Authentication via shared accounts does not provide individual\n accountability for actions taken on the DBMS or data. Whenever a single\n database account is used to connect to the database, a secondary authentication\n method that provides individual accountability is required. This scenario most\n frequently occurs when an externally hosted application authenticates\n individual users to the application and the application uses a single account\n to retrieve or update database information on behalf of the individual users.\n\n When shared accounts are utilized without another means of identifying\n individual users, users may deny having performed a particular action.\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": "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.3, - "refs": [], + "impact": 0, + "refs": [ + { + "ref": [] + } + ], "tags": { - "gtitle": "SRG-APP-000080-DB-000063", - "gid": "V-61887", - "rid": "SV-76377r2_rule", - "stig_id": "O121-P3-006200", - "fix_id": "F-67803r2_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-000166" + "CCI-000803" ], "nist": [ - "AU-10", + "IA-7", "Rev_4" ], "false_negatives": null, @@ -4554,40 +4646,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "If there are no shared accounts available to more than one\n user, this is not a finding.\n\n If a shared account is used by an application to interact with the database,\n review the System Security Plan, the tables in the database, and the\n application source code/documentation to determine whether the application\n captures the individual user's identity and stores that identity along with all\n data inserted and updated (also with all records of reads and/or deletions, if\n these are required to be logged).\n\n If there are gaps in the application's ability to do this, and the gaps and the\n risk are not defined in the system documentation and accepted by the AO, this\n is a finding.\n\n If users are sharing a group account to log on to Oracle tools or third-party\n products that access the database, this is a finding.\n\n If Standard Auditing is used:\n To ensure that user activities other than SELECT, INSERT, UPDATE, and DELETE\n are also monitored and attributed to individuals, verify that Oracle auditing\n is enabled. To see if Oracle is configured to capture audit data, enter the\n following SQL*Plus command:\n SHOW PARAMETER AUDIT_TRAIL\n or the following SQL query:\n SELECT * FROM SYS.V$PARAMETER WHERE NAME = 'audit_trail';\n If Oracle returns the value 'NONE', this is a finding.\n\n If Unified Auditing is used:\n To ensure that user activities other than SELECT, INSERT, UPDATE, and DELETE\n are also monitored and attributed to individuals, verify that Oracle auditing\n is enabled. To see if Oracle is configured to capture audit data, enter the\n following SQL*Plus command:\n SELECT * FROM V$OPTION WHERE PARAMETER = 'Unified Auditing';\n If Oracle returns the value \"TRUE\", this is not a finding.", - "fix": "Use accounts assigned to individual users where feasible.\n Configure DBMS to provide individual accountability at the DBMS level, and in\n audit logs, for actions performed under a shared database account.\n\n Modify applications and data tables that are not capturing individual user\n identity to do so.\n\n Create and enforce the use of individual user IDs for logging on to Oracle\n tools and third-party products.\n\n If Oracle auditing is not already enabled, enable it.\n\n If Standard Auditing is used:\n If Oracle (or third-party) auditing is not already enabled, enable it. For\n Oracle auditing, use this query:\n ALTER SYSTEM SET AUDIT_TRAIL= SCOPE=SPFILE;\n Audit trail type can be 'OS', 'DB', 'DB,EXTENDED', 'XML' or 'XML,EXTENDED'.\n After executing this statement, it may be necessary to shut down and restart\n the Oracle database.\n\n If Unified Auditing is used:\n Link the oracle binary with uniaud_on, and then restart the database. Oracle\n Database Upgrade Guide describes how to enable unified auditing.\n\n For more information on the configuration of auditing, refer to the following\n documents:\n \"Auditing Database Activity\" in the Oracle Database 2 Day + Security Guide:\n http://docs.oracle.com/database/121/TDPSG/tdpsg_auditing.htm#TDPSG50000\n \"Monitoring Database Activity with Auditing\" in the Oracle Database Security\n Guide:\n http://docs.oracle.com/database/121/DBSEG/part_6.htm#CCHEHCGI\n \"DBMS_AUDIT_MGMT\" in the Oracle Database PL/SQL Packages and Types Reference:\n http://docs.oracle.com/database/121/ARPLS/d_audit_mgmt.htm#ARPLS241\n Oracle Database Upgrade Guide:\n http://docs.oracle.com/database/121/UPGRD/afterup.htm#UPGRD52810\n\n If the site-specific audit requirements are not covered by the default audit\n options, deploy and configure Fine-Grained Auditing. For details, refer to\n Oracle documentation at the locations above.\n\n If this level of auditing does not meet site-specific requirements, consider\n deploying the Oracle Audit Vault. The Audit Vault is a highly configurable\n option from Oracle made specifically for performing the audit functions. It\n has reporting capabilities as well as user-defined rules that provide\n additional flexibility for complex auditing requirements." + "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-61887' do\n title \"The DBMS must protect against an individual who uses a shared account\n falsely denying having performed a particular action.\"\n desc \"Non-repudiation of actions taken is required in order to maintain\n application integrity. Examples of particular actions taken by individuals\n include creating information, sending a message, approving information (e.g.,\n indicating concurrence or signing a contract), and receiving a message.\n\n Non-repudiation protects individuals against later claims by an author of\n not having authored a particular document, a sender of not having transmitted a\n message, a receiver of not having received a message, or a signatory of not\n having signed a document.\n\n Authentication via shared accounts does not provide individual\n accountability for actions taken on the DBMS or data. Whenever a single\n database account is used to connect to the database, a secondary authentication\n method that provides individual accountability is required. This scenario most\n frequently occurs when an externally hosted application authenticates\n individual users to the application and the application uses a single account\n to retrieve or update database information on behalf of the individual users.\n\n When shared accounts are utilized without another means of identifying\n individual users, users may deny having performed a particular action.\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.3\n tag \"gtitle\": 'SRG-APP-000080-DB-000063'\n tag \"gid\": 'V-61887'\n tag \"rid\": 'SV-76377r2_rule'\n tag \"stig_id\": 'O121-P3-006200'\n tag \"fix_id\": 'F-67803r2_fix'\n tag \"cci\": ['CCI-000166']\n tag \"nist\": ['AU-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\": \"If there are no shared accounts available to more than one\n user, this is not a finding.\n\n If a shared account is used by an application to interact with the database,\n review the System Security Plan, the tables in the database, and the\n application source code/documentation to determine whether the application\n captures the individual user's identity and stores that identity along with all\n data inserted and updated (also with all records of reads and/or deletions, if\n these are required to be logged).\n\n If there are gaps in the application's ability to do this, and the gaps and the\n risk are not defined in the system documentation and accepted by the AO, this\n is a finding.\n\n If users are sharing a group account to log on to Oracle tools or third-party\n products that access the database, this is a finding.\n\n If Standard Auditing is used:\n To ensure that user activities other than SELECT, INSERT, UPDATE, and DELETE\n are also monitored and attributed to individuals, verify that Oracle auditing\n is enabled. To see if Oracle is configured to capture audit data, enter the\n following SQL*Plus command:\n SHOW PARAMETER AUDIT_TRAIL\n or the following SQL query:\n SELECT * FROM SYS.V$PARAMETER WHERE NAME = 'audit_trail';\n If Oracle returns the value 'NONE', this is a finding.\n\n If Unified Auditing is used:\n To ensure that user activities other than SELECT, INSERT, UPDATE, and DELETE\n are also monitored and attributed to individuals, verify that Oracle auditing\n is enabled. To see if Oracle is configured to capture audit data, enter the\n following SQL*Plus command:\n SELECT * FROM V$OPTION WHERE PARAMETER = 'Unified Auditing';\n If Oracle returns the value \\\"TRUE\\\", this is not a finding.\"\n tag \"fix\": \"Use accounts assigned to individual users where feasible.\n Configure DBMS to provide individual accountability at the DBMS level, and in\n audit logs, for actions performed under a shared database account.\n\n Modify applications and data tables that are not capturing individual user\n identity to do so.\n\n Create and enforce the use of individual user IDs for logging on to Oracle\n tools and third-party products.\n\n If Oracle auditing is not already enabled, enable it.\n\n If Standard Auditing is used:\n If Oracle (or third-party) auditing is not already enabled, enable it. For\n Oracle auditing, use this query:\n ALTER SYSTEM SET AUDIT_TRAIL= SCOPE=SPFILE;\n Audit trail type can be 'OS', 'DB', 'DB,EXTENDED', 'XML' or 'XML,EXTENDED'.\n After executing this statement, it may be necessary to shut down and restart\n the Oracle database.\n\n If Unified Auditing is used:\n Link the oracle binary with uniaud_on, and then restart the database. Oracle\n Database Upgrade Guide describes how to enable unified auditing.\n\n For more information on the configuration of auditing, refer to the following\n documents:\n \\\"Auditing Database Activity\\\" in the Oracle Database 2 Day + Security Guide:\n http://docs.oracle.com/database/121/TDPSG/tdpsg_auditing.htm#TDPSG50000\n \\\"Monitoring Database Activity with Auditing\\\" in the Oracle Database Security\n Guide:\n http://docs.oracle.com/database/121/DBSEG/part_6.htm#CCHEHCGI\n \\\"DBMS_AUDIT_MGMT\\\" in the Oracle Database PL/SQL Packages and Types Reference:\n http://docs.oracle.com/database/121/ARPLS/d_audit_mgmt.htm#ARPLS241\n Oracle Database Upgrade Guide:\n http://docs.oracle.com/database/121/UPGRD/afterup.htm#UPGRD52810\n\n If the site-specific audit requirements are not covered by the default audit\n options, deploy and configure Fine-Grained Auditing. For details, refer to\n Oracle documentation at the locations above.\n\n If this level of auditing does not meet site-specific requirements, consider\n deploying the Oracle Audit Vault. The Audit Vault is a highly configurable\n option from Oracle made specifically for performing the audit functions. It\n has reporting capabilities as well as user-defined rules that provide\n additional flexibility for complex auditing requirements.\"\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 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-61887.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61747.rb", "line": 1 }, - "id": "V-61887" + "id": "V-61747" }, { - "title": "The system must verify there have not been unauthorized changes to the\n DBMS software and information.", - "desc": "Organizations are required to employ integrity verification\n applications on information systems to look for evidence of information\n tampering, errors, and omissions. The organization is also required to employ\n good software engineering practices with regard to commercial off-the-shelf\n integrity mechanisms (e.g., parity checks, cyclical redundancy checks, and\n cryptographic hashes), and to use tools to automatically monitor the integrity\n of the information system and the applications it hosts.\n\n The DBMS opens data files and reads configuration files at system startup,\n system shutdown, and during abort recovery efforts. If the DBMS does not verify\n the trustworthiness of these files, it is vulnerable to malicious alterations\n of its configuration or unauthorized replacement of data.", + "title": "The DBMS itself, or the logging or alerting mechanism the application\n utilizes, must provide a warning when allocated audit record storage volume\n reaches an organization-defined percentage of maximum audit record storage\n capacity.", + "desc": "It is critical for the appropriate personnel to be aware if a system\n is at risk of failing to process audit logs as required. Audit processing\n failures include: software/hardware errors, failures in the audit capturing\n mechanisms, and audit storage capacity being reached or exceeded.\n\n If audit log capacity were to be exceeded, then events subsequently\n occurring would not be recorded. Organizations shall define a maximum allowable\n percentage of storage capacity serving as an alarming threshold (e.g.,\n application has exceeded 80% of log storage capacity allocated) at which time\n the application or the logging mechanism the application utilizes will provide\n a warning to the appropriate personnel.\n\n A failure of database auditing will result in either the database\n continuing to function without auditing or in a complete halt to database\n operations. When audit processing fails, appropriate personnel must be alerted\n immediately to avoid further downtime or unaudited transactions. This can be\n an alert provided by the database, a log repository, or the OS when a\n designated log directory is nearing capacity.", "descriptions": { - "default": "Organizations are required to employ integrity verification\n applications on information systems to look for evidence of information\n tampering, errors, and omissions. The organization is also required to employ\n good software engineering practices with regard to commercial off-the-shelf\n integrity mechanisms (e.g., parity checks, cyclical redundancy checks, and\n cryptographic hashes), and to use tools to automatically monitor the integrity\n of the information system and the applications it hosts.\n\n The DBMS opens data files and reads configuration files at system startup,\n system shutdown, and during abort recovery efforts. If the DBMS does not verify\n the trustworthiness of these files, it is vulnerable to malicious alterations\n of its configuration or unauthorized replacement of data." + "default": "It is critical for the appropriate personnel to be aware if a system\n is at risk of failing to process audit logs as required. Audit processing\n failures include: software/hardware errors, failures in the audit capturing\n mechanisms, and audit storage capacity being reached or exceeded.\n\n If audit log capacity were to be exceeded, then events subsequently\n occurring would not be recorded. Organizations shall define a maximum allowable\n percentage of storage capacity serving as an alarming threshold (e.g.,\n application has exceeded 80% of log storage capacity allocated) at which time\n the application or the logging mechanism the application utilizes will provide\n a warning to the appropriate personnel.\n\n A failure of database auditing will result in either the database\n continuing to function without auditing or in a complete halt to database\n operations. When audit processing fails, appropriate personnel must be alerted\n immediately to avoid further downtime or unaudited transactions. This can be\n an alert provided by the database, a log repository, or the OS when a\n designated log directory is nearing capacity." }, - "impact": 0, - "refs": [ - { - "ref": [] - } - ], + "impact": 0.5, + "refs": [], "tags": { - "gtitle": "SRG-APP-000262-DB-000159", - "gid": "V-61787", - "rid": "SV-76277r1_rule", - "stig_id": "O121-C2-019600", - "fix_id": "F-67703r1_fix", + "gtitle": "SRG-APP-000103-DB-000050", + "gid": "V-61643", + "rid": "SV-76133r2_rule", + "stig_id": "O121-C2-008200", + "fix_id": "F-67555r1_fix", "cci": [ - "CCI-002716", - "CCI-002718" + "CCI-001855" ], "nist": [ - "SI-7 (6)", + "AU-5 (1)", "Rev_4" ], "false_negatives": null, @@ -4600,35 +4687,39 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Verify the DBMS system initialization/parameter files and\n software is included in the configuration of any third-party software or\n custom scripting at the OS level to perform integrity verification.\n\n If neither a third-party application nor the OS is performing integrity\n verification of DBMS system files, this is a finding.", - "fix": "Utilize the OS or a third-party product to perform file\n verification of DBMS system file integrity.\n\n (Using Oracle Configuration Manager with Enterprise Manager, configured to\n perform this verification, is one possible way of satisfying this requirement.)" + "check": "Review DBMS, OS, or third-party logging application settings to\n determine whether a warning will be provided when a specific percentage of log\n storage capacity is reached.\n\n If no warning will be provided, this is a finding.", + "fix": "Modify DBMS, OS, or third-party logging application settings to\n alert appropriate personnel when a specific percentage of log storage capacity\n is reached.\n\n For ease of management, it is recommended that the audit tables be kept in a\n dedicated tablespace.\n\n If Oracle Enterprise Manager is in use, the capability to issue such an alert\n is built in and configurable via the console so an email can be sent to a\n designated administrator.\n\n If Enterprise Manager is unavailable, the following script can be used to\n monitor storage space; this can be combined with additional code to email the\n appropriate administrator so they can take action.\n\n sqlplus connect as sysdba\n\n set pagesize 300\n set linesize 120\n column sumb format 9,999,999,999,999\n column extents format 999999\n column bytes format 9,999,999,999,999\n column largest format 9,999,999,999,999\n column Tot_Size format 9,999,999,999,999\n column Tot_Free format 9,999,999,999,999\n column Pct_Free format 9,999,999,999,999\n column Chunks_Free format 9,999,999,999,999\n column Max_Free format 9,999,999,999,999\n set echo off\n spool TSINFO.txt\n PROMPT SPACE AVAILABLE IN TABLESPACES\n select a.tablespace_name,sum(a.tots) Tot_Size,\n sum(a.sumb) Tot_Free,\n sum(a.sumb)*100/sum(a.tots) Pct_Free,\n sum(a.largest) Max_Free,sum(a.chunks) Chunks_Free\n from\n (\n select tablespace_name,0 tots,sum(bytes) sumb,\n max(bytes) largest,count(*) chunks\n from dba_free_space a\n group by tablespace_name\n union\n select tablespace_name,sum(bytes) tots,0,0,0 from\n dba_data_files\n group by tablespace_name) a\n group by a.tablespace_name;\n\n Sample Output\n\n SPACE AVAILABLE IN TABLESPACES\n\n TABLESPACE_NAME TOT_SIZE TOT_FREE PCT_FREE MAX_FREE\n CHUNKS_FREE\n ------------------------ ------------ ------------ ------------\n ------------ ------------\n DES2 41,943,040 30,935,040 74\n 30,935,040 1\n DES2_I 31,457,280 23,396,352 74\n 23,396,352 1\n RBS 60,817,408 57,085,952 94\n 52,426,752 16\n SYSTEM 94,371,840 5,386,240 6\n 5,013,504 3\n TEMP 563,200 561,152 100\n 133,120 5\n TOOLS 120,586,240 89,407,488 74\n 78,190,592 12\n USERS 1,048,576 26,624 3\n 26,624 1" }, - "code": " control 'V-61787' 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-61643' do\n title \"The DBMS itself, or the logging or alerting mechanism the application\n utilizes, must provide a warning when allocated audit record storage volume\n reaches an organization-defined percentage of maximum audit record storage\n capacity.\"\n desc \"It is critical for the appropriate personnel to be aware if a system\n is at risk of failing to process audit logs as required. Audit processing\n failures include: software/hardware errors, failures in the audit capturing\n mechanisms, and audit storage capacity being reached or exceeded.\n\n If audit log capacity were to be exceeded, then events subsequently\n occurring would not be recorded. Organizations shall define a maximum allowable\n percentage of storage capacity serving as an alarming threshold (e.g.,\n application has exceeded 80% of log storage capacity allocated) at which time\n the application or the logging mechanism the application utilizes will provide\n a warning to the appropriate personnel.\n\n A failure of database auditing will result in either the database\n continuing to function without auditing or in a complete halt to database\n operations. When audit processing fails, appropriate personnel must be alerted\n immediately to avoid further downtime or unaudited transactions. This can be\n an alert provided by the database, a log repository, or the OS when a\n designated log directory is nearing capacity.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000103-DB-000050'\n tag \"gid\": 'V-61643'\n tag \"rid\": 'SV-76133r2_rule'\n tag \"stig_id\": 'O121-C2-008200'\n tag \"fix_id\": 'F-67555r1_fix'\n tag \"cci\": ['CCI-001855']\n tag \"nist\": ['AU-5 (1)', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Review DBMS, OS, or third-party logging application settings to\n determine whether a warning will be provided when a specific percentage of log\n storage capacity is reached.\n\n If no warning will be provided, this is a finding.\"\n tag \"fix\": \"Modify DBMS, OS, or third-party logging application settings to\n alert appropriate personnel when a specific percentage of log storage capacity\n is reached.\n\n For ease of management, it is recommended that the audit tables be kept in a\n dedicated tablespace.\n\n If Oracle Enterprise Manager is in use, the capability to issue such an alert\n is built in and configurable via the console so an email can be sent to a\n designated administrator.\n\n If Enterprise Manager is unavailable, the following script can be used to\n monitor storage space; this can be combined with additional code to email the\n appropriate administrator so they can take action.\n\n sqlplus connect as sysdba\n\n set pagesize 300\n set linesize 120\n column sumb format 9,999,999,999,999\n column extents format 999999\n column bytes format 9,999,999,999,999\n column largest format 9,999,999,999,999\n column Tot_Size format 9,999,999,999,999\n column Tot_Free format 9,999,999,999,999\n column Pct_Free format 9,999,999,999,999\n column Chunks_Free format 9,999,999,999,999\n column Max_Free format 9,999,999,999,999\n set echo off\n spool TSINFO.txt\n PROMPT SPACE AVAILABLE IN TABLESPACES\n select a.tablespace_name,sum(a.tots) Tot_Size,\n sum(a.sumb) Tot_Free,\n sum(a.sumb)*100/sum(a.tots) Pct_Free,\n sum(a.largest) Max_Free,sum(a.chunks) Chunks_Free\n from\n (\n select tablespace_name,0 tots,sum(bytes) sumb,\n max(bytes) largest,count(*) chunks\n from dba_free_space a\n group by tablespace_name\n union\n select tablespace_name,sum(bytes) tots,0,0,0 from\n dba_data_files\n group by tablespace_name) a\n group by a.tablespace_name;\n\n Sample Output\n\n SPACE AVAILABLE IN TABLESPACES\n\n TABLESPACE_NAME TOT_SIZE TOT_FREE PCT_FREE MAX_FREE\n CHUNKS_FREE\n ------------------------ ------------ ------------ ------------\n ------------ ------------\n DES2 41,943,040 30,935,040 74\n 30,935,040 1\n DES2_I 31,457,280 23,396,352 74\n 23,396,352 1\n RBS 60,817,408 57,085,952 94\n 52,426,752 16\n SYSTEM 94,371,840 5,386,240 6\n 5,013,504 3\n TEMP 563,200 561,152 100\n 133,120 5\n TOOLS 120,586,240 89,407,488 74\n 78,190,592 12\n USERS 1,048,576 26,624 3\n 26,624 1\"\n\n describe 'A manual review is required to ensure the DBMS itself, or the logging or alerting mechanism the application\n utilizes, provides a warning when allocated audit record storage volume\n reaches an organization-defined percentage of maximum audit record storage\n capacity.' do\n skip 'A manual review is required to ensure the DBMS itself, or the logging or alerting mechanism the application\n utilizes, provides a warning when allocated audit record storage volume\n reaches an organization-defined percentage of maximum audit record storage\n capacity.'\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61787.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61643.rb", "line": 1 }, - "id": "V-61787" + "id": "V-61643" }, { - "title": "Changes to configuration options must be audited.", - "desc": "The AUDIT_SYS_OPERATIONS parameter is used to enable auditing of\n actions taken by the user SYS. The SYS user account is a shared account by\n definition and holds all privileges in the Oracle database. It is the account\n accessed by users connecting to the database with SYSDBA or SYSOPER privileges.", + "title": "The DBMS must verify account lockouts persist until reset by an\n administrator.", + "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 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": "The AUDIT_SYS_OPERATIONS parameter is used to enable auditing of\n actions taken by the user SYS. The SYS user account is a shared account by\n definition and holds all privileges in the Oracle database. It is the account\n accessed by users connecting to the database with SYSDBA or SYSOPER privileges." + "default": "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 Note that user authentication and account management must be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP. This requirement applies to cases where it is necessary to\n have accounts directly managed by Oracle." }, "impact": 0.5, - "refs": [], + "refs": [ + { + "ref": [] + } + ], "tags": { - "gtitle": "SRG-APP-000516-DB-999900", - "gid": "V-61519", - "rid": "SV-76009r1_rule", - "stig_id": "O121-BP-025800", - "fix_id": "F-67435r1_fix", + "gtitle": "SRG-APP-000065-DB-000024", + "gid": "V-61603", + "rid": "SV-76093r2_rule", + "stig_id": "O121-C2-004900", + "fix_id": "F-67519r1_fix", "cci": [ - "CCI-000366" + "CCI-002236" ], "nist": [ - "CM-6 b", + "AC-7 b", "Rev_4" ], "false_negatives": null, @@ -4641,30 +4732,30 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "From SQL*Plus:\n\n select value from v$parameter where name = 'audit_sys_operations';\n\n If the value returned is FALSE, this is a finding.", - "fix": "From SQL*Plus:\n\n alter system set audit_sys_operations = TRUE scope = spfile;\n\n The above SQL*Plus command will set the parameter to take effect at next system\n startup." + "check": "The account lockout duration is defined in the profile assigned\n to a user.\n \n To see what profile is assigned to a user, enter the query:\n \n SQL>SELECT profile FROM dba_users WHERE username = ''\n \n This will return the profile name assigned to that user.\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 Now check the values assigned to the profile returned from the query above:\n \n column profile format a20\n column limit format a20\n SQL>SELECT PROFILE, RESOURCE_NAME, LIMIT FROM DBA_PROFILES WHERE PROFILE =\n 'ORA_STIG_PROFILE';\n \n Check the settings for password_lock_time - this specifies how long to lock the\n account after the number of consecutive failed logon attempts reaches the\n limit. If the value is not UNLIMITED, this is a finding.", + "fix": "Configure the DBMS settings to specify indefinite lockout\n duration:\n ALTER PROFILE ORA_STIG_PROFILE LIMIT PASSWORD_LOCK_TIME UNLIMITED;" }, - "code": "control 'V-61519' do\n title 'Changes to configuration options must be audited.'\n desc \"The AUDIT_SYS_OPERATIONS parameter is used to enable auditing of\n actions taken by the user SYS. The SYS user account is a shared account by\n definition and holds all privileges in the Oracle database. It is the account\n accessed by users connecting to the database with SYSDBA or SYSOPER privileges.\"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000516-DB-999900'\n tag \"gid\": 'V-61519'\n tag \"rid\": 'SV-76009r1_rule'\n tag \"stig_id\": 'O121-BP-025800'\n tag \"fix_id\": 'F-67435r1_fix'\n tag \"cci\": ['CCI-000366']\n tag \"nist\": ['CM-6 b', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"From SQL*Plus:\n\n select value from v$parameter where name = 'audit_sys_operations';\n\n If the value returned is FALSE, this is a finding.\"\n tag \"fix\": \"From SQL*Plus:\n\n alter system set audit_sys_operations = TRUE scope = spfile;\n\n The above SQL*Plus command will set the parameter to take effect at next system\n startup.\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n parameter = sql.query(\"select value from v$parameter where name = 'audit_sys_operations';\").column('value')\n\n describe 'The oracle database AUDIT_SYS_OPERATIONS parameter' do\n subject { parameter }\n it { should_not cmp 'FALSE' }\n end\nend\n", + "code": " control 'V-61603' do\n title \"The DBMS must verify account lockouts persist until reset by an\n administrator.\"\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 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-000065-DB-000024'\n tag \"gid\": 'V-61603'\n tag \"rid\": 'SV-76093r2_rule'\n tag \"stig_id\": 'O121-C2-004900'\n tag \"fix_id\": 'F-67519r1_fix'\n tag \"cci\": ['CCI-002236']\n tag \"nist\": ['AC-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\": \"The account lockout duration is defined in the profile assigned\n to a user.\n \n To see what profile is assigned to a user, enter the query:\n \n SQL>SELECT profile FROM dba_users WHERE username = ''\n \n This will return the profile name assigned to that user.\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 Now check the values assigned to the profile returned from the query above:\n \n column profile format a20\n column limit format a20\n SQL>SELECT PROFILE, RESOURCE_NAME, LIMIT FROM DBA_PROFILES WHERE PROFILE =\n 'ORA_STIG_PROFILE';\n \n Check the settings for password_lock_time - this specifies how long to lock the\n account after the number of consecutive failed logon attempts reaches the\n limit. If the value is not UNLIMITED, this is a finding.\"\n tag \"fix\": \"Configure the DBMS settings to specify indefinite lockout\n duration:\n ALTER PROFILE ORA_STIG_PROFILE LIMIT PASSWORD_LOCK_TIME UNLIMITED;\"\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_LOCK_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_lock_time = sql.query(format(query, profile: profile)).column('limit')\n \n describe \"The oracle database account password lock time for profile: #{profile}\" do\n subject { password_lock_time }\n it { should 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\n end\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61519.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61603.rb", "line": 1 }, - "id": "V-61519" + "id": "V-61603" }, { - "title": "System privileges granted using the WITH ADMIN OPTION must not be\n granted to unauthorized user accounts.", - "desc": "The WITH ADMIN OPTION allows the grantee to grant a privilege to\n another database account. Best security practice restricts the privilege of\n assigning privileges to authorized personnel. Authorized personnel include\n DBAs, object owners, and, where designed and included in the application's\n functions, application administrators. Restricting privilege-granting functions\n to authorized accounts can help decrease mismanagement of privileges and\n wrongful assignments to unauthorized accounts.", + "title": "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.", "descriptions": { - "default": "The WITH ADMIN OPTION allows the grantee to grant a privilege to\n another database account. Best security practice restricts the privilege of\n assigning privileges to authorized personnel. Authorized personnel include\n DBAs, object owners, and, where designed and included in the application's\n functions, application administrators. Restricting privilege-granting functions\n to authorized accounts can help decrease mismanagement of privileges and\n wrongful assignments to unauthorized accounts." + "default": "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." }, "impact": 0, "refs": [], "tags": { "gtitle": "SRG-APP-000516-DB-999900", - "gid": "V-61433", - "rid": "SV-75923r3_rule", - "stig_id": "O121-BP-022300", - "fix_id": "F-67349r1_fix", + "gid": "V-61445", + "rid": "SV-75935r2_rule", + "stig_id": "O121-BP-022900", + "fix_id": "F-67361r1_fix", "cci": [ "CCI-000366" ], @@ -4682,35 +4773,39 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "A default Oracle Database installation provides a set of\n predefined administrative accounts and non-administrative accounts. These are\n accounts that have special privileges required to administer areas of the\n database, such as the CREATE ANY TABLE or ALTER SESSION privilege, or EXECUTE\n privileges on packages owned by the SYS schema. The default tablespace for\n administrative accounts is either SYSTEM or SYSAUX. Non-administrative user\n accounts only have the minimum privileges needed to perform their jobs. Their\n default tablespace is USERS.\n\n To protect these accounts from unauthorized access, the installation process\n expires and locks most of these accounts, except where noted below. The\n database administrator is responsible for unlocking and resetting these\n accounts, as required.\n\n Non-Administrative Accounts - Expired and locked:\n APEX_PUBLIC_USER, DIP, FLOWS_040100*, FLOWS_FILES, MDDATA, ORACLE_OCM,\n SPATIAL_CSW_ADMIN_USR, SPATIAL_WFS_ADMIN_USR, XS$NULL\n\n Administrative Accounts - Expired and Locked:\n ANONYMOUS, CTXSTS, EXFSYS, LBACSYS, MDSYS, OLAPSYS, OEDDATA, OWBSYS,\n ORDPLUGINS, ORDSYS, OUTLN, SI_INFORMTN_SCHEMA, WK_TEST, WK_SYS, WKPROXY, WMSYS,\n XDB\n\n Administrative Accounts - Open:\n DBSNMP, MGMT_VIEW, SYS, SYSMAN, SYSTEM, SYSKM\n\n * Subject to change based on version installed\n\n Run the SQL query:\n\n From SQL*Plus:\n select grantee, privilege from dba_sys_privs\n where grantee not in ()\n and admin_option = 'YES'\n and grantee not in\n (select grantee from dba_role_privs where granted_role = 'DBA');\n\n (With respect to the list of special accounts that are excluded from this\n requirement, it is expected that the DBA will maintain the list to suit local\n circumstances, adding special accounts as necessary and removing any that are\n not supposed to be in use in the Oracle deployment that is under review.)\n\n If any accounts that are not authorized to have the ADMIN OPTION are listed,\n this is a finding.", - "fix": "Revoke assignment of privileges with the WITH ADMIN OPTION from\n unauthorized users and re-grant them without the option.\n\n From SQL*Plus:\n\n revoke [privilege name] from user [username];\n\n Replace [privilege name] with the named privilege and [username] with the named\n user.\n\n Restrict use of the WITH ADMIN OPTION to authorized administrators.\n\n Document authorized privilege assignments with the WITH ADMIN OPTION in the\n System Security Plan." + "check": "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." }, - "code": "control 'V-61433' do\n title \"System privileges granted using the WITH ADMIN OPTION must not be\n granted to unauthorized user accounts.\"\n desc \"The WITH ADMIN OPTION allows the grantee to grant a privilege to\n another database account. Best security practice restricts the privilege of\n assigning privileges to authorized personnel. Authorized personnel include\n DBAs, object owners, and, where designed and included in the application's\n functions, application administrators. Restricting privilege-granting functions\n to authorized accounts can help decrease mismanagement of privileges and\n wrongful assignments to unauthorized accounts.\"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000516-DB-999900'\n tag \"gid\": 'V-61433'\n tag \"rid\": 'SV-75923r3_rule'\n tag \"stig_id\": 'O121-BP-022300'\n tag \"fix_id\": 'F-67349r1_fix'\n tag \"cci\": ['CCI-000366']\n tag \"nist\": ['CM-6 b', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"A default Oracle Database installation provides a set of\n predefined administrative accounts and non-administrative accounts. These are\n accounts that have special privileges required to administer areas of the\n database, such as the CREATE ANY TABLE or ALTER SESSION privilege, or EXECUTE\n privileges on packages owned by the SYS schema. The default tablespace for\n administrative accounts is either SYSTEM or SYSAUX. Non-administrative user\n accounts only have the minimum privileges needed to perform their jobs. Their\n default tablespace is USERS.\n\n To protect these accounts from unauthorized access, the installation process\n expires and locks most of these accounts, except where noted below. The\n database administrator is responsible for unlocking and resetting these\n accounts, as required.\n\n Non-Administrative Accounts - Expired and locked:\n APEX_PUBLIC_USER, DIP, FLOWS_040100*, FLOWS_FILES, MDDATA, ORACLE_OCM,\n SPATIAL_CSW_ADMIN_USR, SPATIAL_WFS_ADMIN_USR, XS$NULL\n\n Administrative Accounts - Expired and Locked:\n ANONYMOUS, CTXSTS, EXFSYS, LBACSYS, MDSYS, OLAPSYS, OEDDATA, OWBSYS,\n ORDPLUGINS, ORDSYS, OUTLN, SI_INFORMTN_SCHEMA, WK_TEST, WK_SYS, WKPROXY, WMSYS,\n XDB\n\n Administrative Accounts - Open:\n DBSNMP, MGMT_VIEW, SYS, SYSMAN, SYSTEM, SYSKM\n\n * Subject to change based on version installed\n\n Run the SQL query:\n\n From SQL*Plus:\n select grantee, privilege from dba_sys_privs\n where grantee not in ()\n and admin_option = 'YES'\n and grantee not in\n (select grantee from dba_role_privs where granted_role = 'DBA');\n\n (With respect to the list of special accounts that are excluded from this\n requirement, it is expected that the DBA will maintain the list to suit local\n circumstances, adding special accounts as necessary and removing any that are\n not supposed to be in use in the Oracle deployment that is under review.)\n\n If any accounts that are not authorized to have the ADMIN OPTION are listed,\n this is a finding.\"\n tag \"fix\": \"Revoke assignment of privileges with the WITH ADMIN OPTION from\n unauthorized users and re-grant them without the option.\n\n From SQL*Plus:\n\n revoke [privilege name] from user [username];\n\n Replace [privilege name] with the named privilege and [username] with the named\n user.\n\n Restrict use of the WITH ADMIN OPTION to authorized administrators.\n\n Document authorized privilege assignments with the WITH ADMIN OPTION in the\n System Security Plan.\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n dba_users = sql.query(\"select grantee from dba_sys_privs\n where admin_option = 'YES' and grantee not in (select grantee from dba_role_privs where granted_role = 'DBA');\").column('grantee').uniq\n if dba_users.empty?\n impact 0.0\n describe 'There are no oracle DBA users, control N/A' do\n skip 'There are no oracle DBA users, control N/A'\n end\n else\n dba_users.each do |user|\n describe \"oracle DBA users: #{user}\" do\n subject { user }\n it { should be_in input('allowed_dbadmin_users') }\n end\n end\n end\nend\n", + "code": "control 'V-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", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61433.rb", - "line": 1 + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61445.rb", + "line": 3 }, - "id": "V-61433" + "id": "V-61445" }, { - "title": "Attempts to bypass access controls must be audited.", - "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 Detection of suspicious activity, including access attempts and successful\n access from unexpected places, during unexpected times, or other unusual\n indicators can support decisions to apply countermeasures to deter an attack.\n Without detection, malicious activity may proceed without hindrance.", + "title": "The DBMS must terminate the network connection associated with a\n communications session at the end of the session or 15 minutes of inactivity.", + "desc": "Non-local maintenance and diagnostic activities are those activities\n conducted by individuals communicating through a network, either an external\n network (e.g., the Internet) or an internal network.\n\n The act of managing systems and applications includes the ability to access\n sensitive application information, such as system configuration details,\n diagnostic information, user information, and potentially sensitive application\n data.\n\n When applications provide a remote management capability inherent to the\n application, the application needs to ensure all sessions and network\n connections are terminated when non-local maintenance is completed.\n\n When network connections are left open after the database session has\n closed, the network session is open to session hijacking.\n\n The Oracle Listener inherently meets most of this SRG requirement. When a\n user logs off, or times out, or encounters an unrecoverable network fault, the\n Oracle Listener terminates all sessions and network connections. The remaining\n aspect of the requirement, the timeout because of inactivity, is configurable.", "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 Detection of suspicious activity, including access attempts and successful\n access from unexpected places, during unexpected times, or other unusual\n indicators can support decisions to apply countermeasures to deter an attack.\n Without detection, malicious activity may proceed without hindrance." + "default": "Non-local maintenance and diagnostic activities are those activities\n conducted by individuals communicating through a network, either an external\n network (e.g., the Internet) or an internal network.\n\n The act of managing systems and applications includes the ability to access\n sensitive application information, such as system configuration details,\n diagnostic information, user information, and potentially sensitive application\n data.\n\n When applications provide a remote management capability inherent to the\n application, the application needs to ensure all sessions and network\n connections are terminated when non-local maintenance is completed.\n\n When network connections are left open after the database session has\n closed, the network session is open to session hijacking.\n\n The Oracle Listener inherently meets most of this SRG requirement. When a\n user logs off, or times out, or encounters an unrecoverable network fault, the\n Oracle Listener terminates all sessions and network connections. The remaining\n aspect of the requirement, the timeout because of inactivity, is configurable." }, "impact": 0.5, - "refs": [], + "refs": [ + { + "ref": [] + } + ], "tags": { - "gtitle": "SRG-APP-000115-DB-000056", - "gid": "V-61651", - "rid": "SV-76141r1_rule", - "stig_id": "O121-C2-009000", - "fix_id": "F-67565r1_fix", + "gtitle": "SRG-APP-000190-DB-000137", + "gid": "V-61757", + "rid": "SV-76247r2_rule", + "stig_id": "O121-C2-016500", + "fix_id": "F-67673r2_fix", "cci": [ - "CCI-000158" + "CCI-001133" ], "nist": [ - "AU-7 (1)", + "SC-10", "Rev_4" ], "false_negatives": null, @@ -4723,35 +4818,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Review any audit settings for:\n - Unsuccessful logon attempts;\n - Account locking events;\n - Account disabling from a specific source location;\n - Failed database object attempts or attempts to access objects that do not\n exist; and\n - Other activities that may produce unexpected failures or trigger DBMS\n lockdown actions.\n\n If any of the above events as applicable to the DBMS are not audited, this is a\n finding.\n\n - - - - - -\n Check the current users in the database to see what profile they are assigned.\n The logon attempts past a site-defined allowable number, along with account\n locking, is best performed using a profile that defines the limits on these\n activities as designed by the DBA at a specific site. Failed database object\n access or attempt to access objects is monitored by auditing. Checking other\n activities that may produce unexpected failures or trigger database lockdown\n procedures is possible, but the check for the existence of those procedures is\n not possible unless they are defined.\n\n Check to see what profiles exist for the different users of the database.\n\n SQL>col name format a20\n col username format a21\n col profile format a10\n col \"tmp tba\" format a10\n select u.username,\n u.default_tablespace,\n u.temporary_tablespace \"TMP TBS\",\n u.profile,\n r.granted_role,\n r.admin_option,\n r.default_role\n from sys.dba_users u,\n sys.dba_role_privs r\n where u.username = r.grantee (+)\n group by u.username,\n u.default_tablespace,\n u.temporary_tablespace,\n u.profile,\n r.granted_role,\n r.admin_option,\n r.default_role;\n\n View existing profiles and see what their settings are.\n\n SQL> select profile, resource_name, limit\n from dba_profiles\n order by profile, resource_name;\n\n This is the audit table. Specific actions are logged in this table.\n\n If Standard Auditing is used:\n SQL> desc aud$;\n Name Null? Type\n ----------------- ------- ------\n SESSIONID NOT NULL NUMBER\n ENTRYID NOT NULL NUMBER\n STATEMENT NOT NULL NUMBER\n TIMESTAMP# DATE\n USERID VARCHAR2(30)\n USERHOST VARCHAR2(128)\n TERMINAL VARCHAR2(255)\n ACTION# NOT NULL NUMBER\n RETURNCODE NOT NULL NUMBER\n OBJ$CREATOR VARCHAR2(30)\n OBJ$NAME VARCHAR2(128)\n AUTH$PRIVILEGES VARCHAR2(16)\n AUTH$GRANTEE VARCHAR2(30)\n NEW$OWNER VARCHAR2(30)\n NEW$NAME VARCHAR2(128)\n SES$ACTIONS VARCHAR2(19)\n SES$TID NUMBER\n LOGOFF$LREAD NUMBER\n LOGOFF$PREAD NUMBER\n LOGOFF$LWRITE NUMBER\n LOGOFF$DEAD NUMBER\n LOGOFF$TIME DATE\n COMMENT$TEXT VARCHAR2(4000)\n CLIENTID VARCHAR2(64)\n SPARE1 VARCHAR2(255)\n SPARE2 NUMBER\n OBJ$LABEL RAW(255)\n SES$LABEL RAW(255)\n PRIV$USED NUMBER\n SESSIONCPU NUMBER\n NTIMESTAMP# TIMESTAMP(6)\n PROXY$SID NUMBER\n USER$GUID VARCHAR2(32)\n INSTANCE# NUMBER\n PROCESS# VARCHAR2(16)\n XID RAW(8)\n AUDITID VARCHAR2(64)\n SCN NUMBER\n DBID NUMBER\n SQLBIND CLOB\n SQLTEXT CLOB\n OBJ$EDITION VARCHAR2(30)\n\n If Unified Auditing is used:\n SQL> desc unified_audit_trail;\n Name Null Type\n -------------- ------ ------\n AUDIT_TYPE VARCHAR2(64)\n SESSIONID NUMBER\n PROXY_SESSIONID NUMBER\n OS_USERNAME VARCHAR2(30)\n USERHOST VARCHAR2(128)\n TERMINAL VARCHAR2(30)\n INSTANCE_ID NUMBER\n DBID NUMBER\n AUTHENTICATION_TYPE VARCHAR2(1024)\n DBUSERNAME VARCHAR2(30)\n DBPROXY_USERNAME VARCHAR2(30)\n EXTERNAL_USERID VARCHAR2(1024)\n GLOBAL_USERID VARCHAR2(32)\n CLIENT_PROGRAM_NAME VARCHAR2(48)\n DBLINK_INFO VARCHAR2(4000)\n XS_USER_NAME VARCHAR2(128)\n XS_SESSIONID RAW(33 BYTE)\n ENTRY_ID NUMBER\n STATEMENT_ID NUMBER\n EVENT_TIMESTAMP TIMESTAMP(6) WITH LOCAL TIME ZONE\n ACTION_NAME VARCHAR2(64)\n RETURN_CODE NUMBER\n OS_PROCESS VARCHAR2(16)\n TRANSACTION_ID RAW(8 BYTE)\n SCN NUMBER\n EXECUTION_ID VARCHAR2(64)\n OBJECT_SCHEMA VARCHAR2(30)\n OBJECT_NAME VARCHAR2(128)\n SQL_TEXT CLOB\n SQL_BINDS CLOB\n APPLICATION_CONTEXTS VARCHAR2(4000)\n CLIENT_IDENTIFIER VARCHAR2(64)\n NEW_SCHEMA VARCHAR2(30)\n NEW_NAME VARCHAR2(128)\n OBJECT_EDITION VARCHAR2(30)\n SYSTEM_PRIVILEGE_USED VARCHAR2(1024)\n SYSTEM_PRIVILEGE VARCHAR2(40)\n AUDIT_OPTION VARCHAR2(40)\n OBJECT_PRIVILEGES VARCHAR2(19)\n ROLE VARCHAR2(30)\n TARGET_USER VARCHAR2(30)\n EXCLUDED_USER VARCHAR2(30)\n EXCLUDED_SCHEMA VARCHAR2(30)\n EXCLUDED_OBJECT VARCHAR2(128)\n ADDITIONAL_INFO VARCHAR2(4000)\n UNIFIED_AUDIT_POLICIES VARCHAR2(4000)\n FGA_POLICY_NAME VARCHAR2(30)\n XS_INACTIVITY_TIMEOUT NUMBER\n XS_ENTITY_TYPE VARCHAR2(32)\n XS_TARGET_PRINCIPAL_NAME VARCHAR2(30)\n XS_PROXY_USER_NAME VARCHAR2(30)\n XS_DATASEC_POLICY_NAME VARCHAR2(30)\n XS_SCHEMA_NAME VARCHAR2(30)\n XS_CALLBACK_EVENT_TYPE VARCHAR2(32)\n XS_PACKAGE_NAME VARCHAR2(30)\n XS_PROCEDURE_NAME VARCHAR2(30)\n XS_ENABLED_ROLE VARCHAR2(30)\n XS_COOKIE VARCHAR2(1024)\n XS_NS_NAME VARCHAR2(30)\n XS_NS_ATTRIBUTE VARCHAR2(4000)\n XS_NS_ATTRIBUTE_OLD_VAL VARCHAR2(4000)\n XS_NS_ATTRIBUTE_NEW_VAL VARCHAR2(4000)\n DV_ACTION_CODE NUMBER\n DV_ACTION_NAME VARCHAR2(30)\n DV_EXTENDED_ACTION_CODE NUMBER\n DV_GRANTEE VARCHAR2(30)\n DV_RETURN_CODE NUMBER\n DV_ACTION_OBJECT_NAME VARCHAR2(128)\n DV_RULE_SET_NAME VARCHAR2(90)\n DV_COMMENT VARCHAR2(4000)\n DV_FACTOR_CONTEXT VARCHAR2(4000)\n DV_OBJECT_STATUS VARCHAR2(1)\n OLS_POLICY_NAME VARCHAR2(30)\n OLS_GRANTEE VARCHAR2(30)\n OLS_MAX_READ_LABEL VARCHAR2(4000)\n OLS_MAX_WRITE_LABEL VARCHAR2(4000)\n OLS_MIN_WRITE_LABEL VARCHAR2(4000)\n OLS_PRIVILEGES_GRANTED VARCHAR2(30)\n OLS_PROGRAM_UNIT_NAME VARCHAR2(30)\n OLS_PRIVILEGES_USED VARCHAR2(128)\n OLS_STRING_LABEL VARCHAR2(4000)\n OLS_LABEL_COMPONENT_TYPE VARCHAR2(12)\n OLS_LABEL_COMPONENT_NAME VARCHAR2(30)\n OLS_PARENT_GROUP_NAME VARCHAR2(30)\n OLS_OLD_VALUE VARCHAR2(4000)\n OLS_NEW_VALUE VARCHAR2(4000)\n RMAN_SESSION_RECID NUMBER\n RMAN_SESSION_STAMP NUMBER\n RMAN_OPERATION VARCHAR2(20)\n RMAN_OBJECT_TYPE VARCHAR2(20)\n RMAN_DEVICE_TYPE VARCHAR2(5)\n DP_TEXT_PARAMETERS1 VARCHAR2(512)\n DP_BOOLEAN_PARAMETERS1 VARCHAR2(512)\n DIRECT_PATH_NUM_COLUMNS_LOADED NUMBER", - "fix": "Configure auditing to capture the events listed below where\n available in the DBMS:\n - Unsuccessful logon attempts\n - Account locking events\n - Account disabling from a specific source location\n - Failed database object attempts or attempts to access objects that do not\n exist\n - Other activities that may produce unexpected failures or trigger DBMS\n lockdown actions" + "check": "Review DBMS settings, OS settings, and vendor documentation to\n verify network connections are terminated when a database communications\n session is ended or after 15 minutes of inactivity.\n\n If the network connection is not terminated, this is a finding.\n\n The defined duration for these timeouts 15 minutes, except to fulfill\n documented and validated mission requirements.", + "fix": "Configure DBMS and/or OS settings to disconnect network sessions\n when database communication sessions have ended or after the DoD-defined period\n of inactivity.\n\n To configure this in Oracle, modify each relevant profile. The resource name\n is IDLE_TIME, which is expressed in minutes. Using PPPPPP as an example of a\n profile, set the timeout to 15 minutes with:\n ALTER PROFILE PPPPPP LIMIT IDLE_TIME 15;" }, - "code": "control 'V-61651' do\n title 'Attempts to bypass access controls must be audited.'\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 Detection of suspicious activity, including access attempts and successful\n access from unexpected places, during unexpected times, or other unusual\n indicators can support decisions to apply countermeasures to deter an attack.\n Without detection, malicious activity may proceed without hindrance.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000115-DB-000056'\n tag \"gid\": 'V-61651'\n tag \"rid\": 'SV-76141r1_rule'\n tag \"stig_id\": 'O121-C2-009000'\n tag \"fix_id\": 'F-67565r1_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 any audit settings for:\n - Unsuccessful logon attempts;\n - Account locking events;\n - Account disabling from a specific source location;\n - Failed database object attempts or attempts to access objects that do not\n exist; and\n - Other activities that may produce unexpected failures or trigger DBMS\n lockdown actions.\n\n If any of the above events as applicable to the DBMS are not audited, this is a\n finding.\n\n - - - - - -\n Check the current users in the database to see what profile they are assigned.\n The logon attempts past a site-defined allowable number, along with account\n locking, is best performed using a profile that defines the limits on these\n activities as designed by the DBA at a specific site. Failed database object\n access or attempt to access objects is monitored by auditing. Checking other\n activities that may produce unexpected failures or trigger database lockdown\n procedures is possible, but the check for the existence of those procedures is\n not possible unless they are defined.\n\n Check to see what profiles exist for the different users of the database.\n\n SQL>col name format a20\n col username format a21\n col profile format a10\n col \\\"tmp tba\\\" format a10\n select u.username,\n u.default_tablespace,\n u.temporary_tablespace \\\"TMP TBS\\\",\n u.profile,\n r.granted_role,\n r.admin_option,\n r.default_role\n from sys.dba_users u,\n sys.dba_role_privs r\n where u.username = r.grantee (+)\n group by u.username,\n u.default_tablespace,\n u.temporary_tablespace,\n u.profile,\n r.granted_role,\n r.admin_option,\n r.default_role;\n\n View existing profiles and see what their settings are.\n\n SQL> select profile, resource_name, limit\n from dba_profiles\n order by profile, resource_name;\n\n This is the audit table. Specific actions are logged in this table.\n\n If Standard Auditing is used:\n SQL> desc aud$;\n Name Null? Type\n ----------------- ------- ------\n SESSIONID NOT NULL NUMBER\n ENTRYID NOT NULL NUMBER\n STATEMENT NOT NULL NUMBER\n TIMESTAMP# DATE\n USERID VARCHAR2(30)\n USERHOST VARCHAR2(128)\n TERMINAL VARCHAR2(255)\n ACTION# NOT NULL NUMBER\n RETURNCODE NOT NULL NUMBER\n OBJ$CREATOR VARCHAR2(30)\n OBJ$NAME VARCHAR2(128)\n AUTH$PRIVILEGES VARCHAR2(16)\n AUTH$GRANTEE VARCHAR2(30)\n NEW$OWNER VARCHAR2(30)\n NEW$NAME VARCHAR2(128)\n SES$ACTIONS VARCHAR2(19)\n SES$TID NUMBER\n LOGOFF$LREAD NUMBER\n LOGOFF$PREAD NUMBER\n LOGOFF$LWRITE NUMBER\n LOGOFF$DEAD NUMBER\n LOGOFF$TIME DATE\n COMMENT$TEXT VARCHAR2(4000)\n CLIENTID VARCHAR2(64)\n SPARE1 VARCHAR2(255)\n SPARE2 NUMBER\n OBJ$LABEL RAW(255)\n SES$LABEL RAW(255)\n PRIV$USED NUMBER\n SESSIONCPU NUMBER\n NTIMESTAMP# TIMESTAMP(6)\n PROXY$SID NUMBER\n USER$GUID VARCHAR2(32)\n INSTANCE# NUMBER\n PROCESS# VARCHAR2(16)\n XID RAW(8)\n AUDITID VARCHAR2(64)\n SCN NUMBER\n DBID NUMBER\n SQLBIND CLOB\n SQLTEXT CLOB\n OBJ$EDITION VARCHAR2(30)\n\n If Unified Auditing is used:\n SQL> desc unified_audit_trail;\n Name Null Type\n -------------- ------ ------\n AUDIT_TYPE VARCHAR2(64)\n SESSIONID NUMBER\n PROXY_SESSIONID NUMBER\n OS_USERNAME VARCHAR2(30)\n USERHOST VARCHAR2(128)\n TERMINAL VARCHAR2(30)\n INSTANCE_ID NUMBER\n DBID NUMBER\n AUTHENTICATION_TYPE VARCHAR2(1024)\n DBUSERNAME VARCHAR2(30)\n DBPROXY_USERNAME VARCHAR2(30)\n EXTERNAL_USERID VARCHAR2(1024)\n GLOBAL_USERID VARCHAR2(32)\n CLIENT_PROGRAM_NAME VARCHAR2(48)\n DBLINK_INFO VARCHAR2(4000)\n XS_USER_NAME VARCHAR2(128)\n XS_SESSIONID RAW(33 BYTE)\n ENTRY_ID NUMBER\n STATEMENT_ID NUMBER\n EVENT_TIMESTAMP TIMESTAMP(6) WITH LOCAL TIME ZONE\n ACTION_NAME VARCHAR2(64)\n RETURN_CODE NUMBER\n OS_PROCESS VARCHAR2(16)\n TRANSACTION_ID RAW(8 BYTE)\n SCN NUMBER\n EXECUTION_ID VARCHAR2(64)\n OBJECT_SCHEMA VARCHAR2(30)\n OBJECT_NAME VARCHAR2(128)\n SQL_TEXT CLOB\n SQL_BINDS CLOB\n APPLICATION_CONTEXTS VARCHAR2(4000)\n CLIENT_IDENTIFIER VARCHAR2(64)\n NEW_SCHEMA VARCHAR2(30)\n NEW_NAME VARCHAR2(128)\n OBJECT_EDITION VARCHAR2(30)\n SYSTEM_PRIVILEGE_USED VARCHAR2(1024)\n SYSTEM_PRIVILEGE VARCHAR2(40)\n AUDIT_OPTION VARCHAR2(40)\n OBJECT_PRIVILEGES VARCHAR2(19)\n ROLE VARCHAR2(30)\n TARGET_USER VARCHAR2(30)\n EXCLUDED_USER VARCHAR2(30)\n EXCLUDED_SCHEMA VARCHAR2(30)\n EXCLUDED_OBJECT VARCHAR2(128)\n ADDITIONAL_INFO VARCHAR2(4000)\n UNIFIED_AUDIT_POLICIES VARCHAR2(4000)\n FGA_POLICY_NAME VARCHAR2(30)\n XS_INACTIVITY_TIMEOUT NUMBER\n XS_ENTITY_TYPE VARCHAR2(32)\n XS_TARGET_PRINCIPAL_NAME VARCHAR2(30)\n XS_PROXY_USER_NAME VARCHAR2(30)\n XS_DATASEC_POLICY_NAME VARCHAR2(30)\n XS_SCHEMA_NAME VARCHAR2(30)\n XS_CALLBACK_EVENT_TYPE VARCHAR2(32)\n XS_PACKAGE_NAME VARCHAR2(30)\n XS_PROCEDURE_NAME VARCHAR2(30)\n XS_ENABLED_ROLE VARCHAR2(30)\n XS_COOKIE VARCHAR2(1024)\n XS_NS_NAME VARCHAR2(30)\n XS_NS_ATTRIBUTE VARCHAR2(4000)\n XS_NS_ATTRIBUTE_OLD_VAL VARCHAR2(4000)\n XS_NS_ATTRIBUTE_NEW_VAL VARCHAR2(4000)\n DV_ACTION_CODE NUMBER\n DV_ACTION_NAME VARCHAR2(30)\n DV_EXTENDED_ACTION_CODE NUMBER\n DV_GRANTEE VARCHAR2(30)\n DV_RETURN_CODE NUMBER\n DV_ACTION_OBJECT_NAME VARCHAR2(128)\n DV_RULE_SET_NAME VARCHAR2(90)\n DV_COMMENT VARCHAR2(4000)\n DV_FACTOR_CONTEXT VARCHAR2(4000)\n DV_OBJECT_STATUS VARCHAR2(1)\n OLS_POLICY_NAME VARCHAR2(30)\n OLS_GRANTEE VARCHAR2(30)\n OLS_MAX_READ_LABEL VARCHAR2(4000)\n OLS_MAX_WRITE_LABEL VARCHAR2(4000)\n OLS_MIN_WRITE_LABEL VARCHAR2(4000)\n OLS_PRIVILEGES_GRANTED VARCHAR2(30)\n OLS_PROGRAM_UNIT_NAME VARCHAR2(30)\n OLS_PRIVILEGES_USED VARCHAR2(128)\n OLS_STRING_LABEL VARCHAR2(4000)\n OLS_LABEL_COMPONENT_TYPE VARCHAR2(12)\n OLS_LABEL_COMPONENT_NAME VARCHAR2(30)\n OLS_PARENT_GROUP_NAME VARCHAR2(30)\n OLS_OLD_VALUE VARCHAR2(4000)\n OLS_NEW_VALUE VARCHAR2(4000)\n RMAN_SESSION_RECID NUMBER\n RMAN_SESSION_STAMP NUMBER\n RMAN_OPERATION VARCHAR2(20)\n RMAN_OBJECT_TYPE VARCHAR2(20)\n RMAN_DEVICE_TYPE VARCHAR2(5)\n DP_TEXT_PARAMETERS1 VARCHAR2(512)\n DP_BOOLEAN_PARAMETERS1 VARCHAR2(512)\n DIRECT_PATH_NUM_COLUMNS_LOADED NUMBER\"\n tag \"fix\": \"Configure auditing to capture the events listed below where\n available in the DBMS:\n - Unsuccessful logon attempts\n - Account locking events\n - Account disabling from a specific source location\n - Failed database object attempts or attempts to access objects that do not\n exist\n - Other activities that may produce unexpected failures or trigger DBMS\n lockdown actions\"\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-61757' do\n title \"The DBMS must terminate the network connection associated with a\n communications session at the end of the session or 15 minutes of inactivity.\"\n desc \"Non-local maintenance and diagnostic activities are those activities\n conducted by individuals communicating through a network, either an external\n network (e.g., the Internet) or an internal network.\n\n The act of managing systems and applications includes the ability to access\n sensitive application information, such as system configuration details,\n diagnostic information, user information, and potentially sensitive application\n data.\n\n When applications provide a remote management capability inherent to the\n application, the application needs to ensure all sessions and network\n connections are terminated when non-local maintenance is completed.\n\n When network connections are left open after the database session has\n closed, the network session is open to session hijacking.\n\n The Oracle Listener inherently meets most of this SRG requirement. When a\n user logs off, or times out, or encounters an unrecoverable network fault, the\n Oracle Listener terminates all sessions and network connections. The remaining\n aspect of the requirement, the timeout because of inactivity, is configurable.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000190-DB-000137'\n tag \"gid\": 'V-61757'\n tag \"rid\": 'SV-76247r2_rule'\n tag \"stig_id\": 'O121-C2-016500'\n tag \"fix_id\": 'F-67673r2_fix'\n tag \"cci\": ['CCI-001133']\n tag \"nist\": ['SC-10', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Review DBMS settings, OS settings, and vendor documentation to\n verify network connections are terminated when a database communications\n session is ended or after 15 minutes of inactivity.\n\n If the network connection is not terminated, this is a finding.\n\n The defined duration for these timeouts 15 minutes, except to fulfill\n documented and validated mission requirements.\"\n tag \"fix\": \"Configure DBMS and/or OS settings to disconnect network sessions\n when database communication sessions have ended or after the DoD-defined period\n of inactivity.\n\n To configure this in Oracle, modify each relevant profile. The resource name\n is IDLE_TIME, which is expressed in minutes. Using PPPPPP as an example of a\n profile, set the timeout to 15 minutes with:\n ALTER PROFILE PPPPPP LIMIT IDLE_TIME 15;\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n query = %{\n SELECT PROFILE, RESOURCE_NAME, LIMIT FROM DBA_PROFILES WHERE PROFILE =\n '%s' AND RESOURCE_NAME = 'IDLE_TIME'\n }\n\n user_profiles = sql.query('SELECT profile FROM dba_users;').column('profile').uniq\n\n user_profiles.each do |profile|\n next if profile == \"RDSADMIN\"\n idle_time = sql.query(format(query, profile: profile)).column('limit')\n\n describe \"The oracle database idele time for profile: #{profile}\" do\n subject { idle_time }\n it { should cmp <= 15 }\n end\n end\n if user_profiles.empty?\n describe 'There are no user profiles, therefore this control is NA' do\n skip 'There are no user profiles, therefore this control is NA'\n end\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61651.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61757.rb", "line": 1 }, - "id": "V-61651" + "id": "V-61757" }, { - "title": "The DBMS must isolate security functions from nonsecurity functions by\n means of separate security domains.", - "desc": "Security functions are defined as \"the hardware, software, and/or\n firmware of the information system responsible for enforcing the system\n security policy and supporting the isolation of code and data on which the\n protection is based\".\n\n Developers and implementers can increase the assurance in security\n functions by employing well-defined security policy models, structured,\n disciplined, and rigorous hardware and software development techniques, and\n sound system/security engineering principles.\n\n Database Management Systems typically separate security functionality from\n non-security functionality via separate databases or schemas. Database objects\n or code implementing security functionality must not be commingled with objects\n or code implementing application logic. When security and non-security\n functionality is commingled, users who have access to non-security\n functionality may be able to access security functionality.", + "title": "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": "Security functions are defined as \"the hardware, software, and/or\n firmware of the information system responsible for enforcing the system\n security policy and supporting the isolation of code and data on which the\n protection is based\".\n\n Developers and implementers can increase the assurance in security\n functions by employing well-defined security policy models, structured,\n disciplined, and rigorous hardware and software development techniques, and\n sound system/security engineering principles.\n\n Database Management Systems typically separate security functionality from\n non-security functionality via separate databases or schemas. Database objects\n or code implementing security functionality must not be commingled with objects\n or code implementing application logic. When security and non-security\n functionality is commingled, users who have access to non-security\n functionality may be able to access security functionality." + "default": "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-000233-DB-000124", - "gid": "V-61775", - "rid": "SV-76265r1_rule", - "stig_id": "O121-C2-018500", - "fix_id": "F-67691r1_fix", + "gtitle": "SRG-APP-000516-DB-999900", + "gid": "V-61413", + "rid": "SV-75903r1_rule", + "stig_id": "O121-BP-021300", + "fix_id": "F-67329r1_fix", "cci": [ - "CCI-001084" + "CCI-000366" ], "nist": [ - "SC-3", + "CM-6 b", "Rev_4" ], "false_negatives": null, @@ -4764,35 +4859,36 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Check DBMS settings to determine whether objects or code\n implementing security functionality are located in a separate security domain,\n such as a separate database or schema created specifically for security\n functionality.\n\n If security-related database objects or code are not kept separate, this is a\n finding.\n\n The Oracle elements of security functionality, such as the roles, permissions,\n and profiles, along with password complexity requirements, are stored in\n separate schemas in the database. Review any site-specific applications\n security modules built into the database and determine what schema they are\n located in and take appropriate action. The Oracle objects will be in the\n Oracle Data Dictionary.", - "fix": "Locate security-related database objects and code in a separate\n database, schema, or other separate security domain from database objects and\n code implementing application logic. (This is the default behavior for\n Oracle.) Review any site-specific applications security modules built into the\n database: determine what schema they are located in and take appropriate\n action." + "check": "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-61775' do\n title \"The DBMS must isolate security functions from nonsecurity functions by\n means of separate security domains.\"\n desc \"Security functions are defined as \\\"the hardware, software, and/or\n firmware of the information system responsible for enforcing the system\n security policy and supporting the isolation of code and data on which the\n protection is based\\\".\n\n Developers and implementers can increase the assurance in security\n functions by employing well-defined security policy models, structured,\n disciplined, and rigorous hardware and software development techniques, and\n sound system/security engineering principles.\n\n Database Management Systems typically separate security functionality from\n non-security functionality via separate databases or schemas. Database objects\n or code implementing security functionality must not be commingled with objects\n or code implementing application logic. When security and non-security\n functionality is commingled, users who have access to non-security\n functionality may be able to access security functionality.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000233-DB-000124'\n tag \"gid\": 'V-61775'\n tag \"rid\": 'SV-76265r1_rule'\n tag \"stig_id\": 'O121-C2-018500'\n tag \"fix_id\": 'F-67691r1_fix'\n tag \"cci\": ['CCI-001084']\n tag \"nist\": ['SC-3', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Check DBMS settings to determine whether objects or code\n implementing security functionality are located in a separate security domain,\n such as a separate database or schema created specifically for security\n functionality.\n\n If security-related database objects or code are not kept separate, this is a\n finding.\n\n The Oracle elements of security functionality, such as the roles, permissions,\n and profiles, along with password complexity requirements, are stored in\n separate schemas in the database. Review any site-specific applications\n security modules built into the database and determine what schema they are\n located in and take appropriate action. The Oracle objects will be in the\n Oracle Data Dictionary.\"\n tag \"fix\": \"Locate security-related database objects and code in a separate\n database, schema, or other separate security domain from database objects and\n code implementing application logic. (This is the default behavior for\n Oracle.) Review any site-specific applications security modules built into the\n database: determine what schema they are located in and take appropriate\n action.\"\n describe 'A manual review is required to ensure the DBMS isolates security functions from nonsecurity functions by\n means of separate security domains' do\n skip 'A manual review is required to ensure the DBMS isolates security functions from nonsecurity functions by\n means of separate security domains'\n end\nend\n", + "code": "control 'V-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-61775.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61413.rb", "line": 1 }, - "id": "V-61775" + "id": "V-61413" }, { - "title": "The DBMS must employ strong identification and authentication\n techniques when establishing nonlocal maintenance and diagnostic sessions.", - "desc": "Non-local maintenance and diagnostic activities are those activities\n conducted by individuals communicating through a network, either an external\n network (e.g., the Internet) or an internal network.\n\n The act of managing systems and applications includes the ability to access\n sensitive application information, such as system configuration details,\n diagnostic information, user information, and potentially sensitive application\n data.\n\n When applications provide a remote management capability inherent to the\n application, the application needs to ensure the identification and\n authentication techniques used to remotely access the system are strong enough\n to protect the system. If the communication channel is not adequately\n protected, authentication information, application data, and configuration\n information could be compromised.", + "title": "The DBMS must implement separation of duties through assigned\n information access authorizations.", + "desc": "Separation of duties is a prevalent Information Technology control\n that is implemented at different layers of the information system, including\n the operating system and in applications. It serves to eliminate or reduce the\n possibility that a single user may carry out a prohibited action. Separation of\n duties requires that the person accountable for approving an action is not the\n same person who is tasked with implementing or carrying out that action.\n\n Additionally, the person or entity accountable for monitoring the activity\n must be separate as well. To meet this requirement, applications, when\n applicable, shall be divided where functionality is based on roles and duties.\n Examples of separation of duties include: (i) mission functions and distinct\n information system support functions are divided among different\n individuals/roles; (ii) different individuals perform information system\n support functions (e.g., system management, systems programming, configuration\n management, quality assurance and testing, network security); (iii) security\n personnel who administer access control functions do not administer audit\n functions; and (iv) different administrator accounts for different roles.\n\n Privileges granted outside the context of the application user job function\n are more likely to go unmanaged or without oversight for authorization.\n Maintenance of privileges using roles defined for discrete job functions offers\n improved oversight of application user privilege assignments and helps to\n protect against unauthorized privilege assignment.", "descriptions": { - "default": "Non-local maintenance and diagnostic activities are those activities\n conducted by individuals communicating through a network, either an external\n network (e.g., the Internet) or an internal network.\n\n The act of managing systems and applications includes the ability to access\n sensitive application information, such as system configuration details,\n diagnostic information, user information, and potentially sensitive application\n data.\n\n When applications provide a remote management capability inherent to the\n application, the application needs to ensure the identification and\n authentication techniques used to remotely access the system are strong enough\n to protect the system. If the communication channel is not adequately\n protected, authentication information, application data, and configuration\n information could be compromised." + "default": "Separation of duties is a prevalent Information Technology control\n that is implemented at different layers of the information system, including\n the operating system and in applications. It serves to eliminate or reduce the\n possibility that a single user may carry out a prohibited action. Separation of\n duties requires that the person accountable for approving an action is not the\n same person who is tasked with implementing or carrying out that action.\n\n Additionally, the person or entity accountable for monitoring the activity\n must be separate as well. To meet this requirement, applications, when\n applicable, shall be divided where functionality is based on roles and duties.\n Examples of separation of duties include: (i) mission functions and distinct\n information system support functions are divided among different\n individuals/roles; (ii) different individuals perform information system\n support functions (e.g., system management, systems programming, configuration\n management, quality assurance and testing, network security); (iii) security\n personnel who administer access control functions do not administer audit\n functions; and (iv) different administrator accounts for different roles.\n\n Privileges granted outside the context of the application user job function\n are more likely to go unmanaged or without oversight for authorization.\n Maintenance of privileges using roles defined for discrete job functions offers\n improved oversight of application user privilege assignments and helps to\n protect against unauthorized privilege assignment." }, - "impact": 0.5, + "impact": 0.3, "refs": [], "tags": { - "gtitle": "SRG-APP-000185-DB-000116", - "gid": "V-61751", - "rid": "SV-76241r1_rule", - "stig_id": "O121-C2-016100", - "fix_id": "F-67667r1_fix", + "gtitle": "SRG-APP-000062-DB-000009", + "gid": "V-61809", + "rid": "SV-76299r3_rule", + "stig_id": "O121-C3-003300", + "fix_id": "F-67725r1_fix", "cci": [ - "CCI-000877" + "CCI-000366", + "CCI-002220" ], "nist": [ - "MA-4 c)", + "AC-5 c", "Rev_4" ], "false_negatives": null, @@ -4805,35 +4901,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Review DBMS settings to determine whether strong identification\n and authentication techniques are required for nonlocal maintenance and\n diagnostic sessions.\n\n If strong identification and authentication techniques are not required, this\n is a finding.", - "fix": "Configure DBMS settings to use strong identification and\n authentication techniques for nonlocal maintenance and diagnostic sessions." + "check": "Obtain a list of privileges assigned to the DBMS user accounts.\n If any direct privilege assignments exist that can be assigned to a role, this\n is a finding.\n\n SELECT\n 'User '\n || grantee\n || ' is directly granted '\n || privilege\n || ' privilege on '\n || table_name value\n FROM dba_tab_privs\n WHERE grantee NOT IN (SELECT role FROM dba_roles)\n AND grantee NOT IN\n (\n 'XDB', 'SYSTEM', 'SYS', 'LBACSYS',\n 'DVSYS', 'DVF', 'SYSMAN_RO', 'SYSMAN_BIPLATFORM',\n 'SYSMAN_MDS', 'SYSMAN_OPSS', 'SYSMAN_STB', 'PUBLIC',\n 'DBSNMP', 'SYSMAN', 'APEX_040200', 'WMSYS',\n 'SYSDG', 'SYSBACKUP', 'SPATIAL_WFS_ADMIN_USR',\n 'SPATIAL_CSW_ADMIN_US',\n 'SI_INFORMTN_SCHEMA', 'OUTLN', 'ORDSYS', 'ORDDATA',\n 'OJVMSYS', 'ORACLE_OCM', 'MDSYS', 'ORDPLUGINS',\n 'GSMADMIN_INTERNAL', 'FLOWS_FILES', 'DIP', 'CTXSYS',\n 'AUDSYS', 'APPQOSSYS', 'APEX_PUBLIC_USER', 'ANONYMOUS',\n 'SPATIAL_CSW_ADMIN_USR', 'SYSKM', 'SYSMAN_TYPES',\n 'MGMT_VIEW', 'EUS_ENGINE_USER', 'GSMCATUSER', 'OLAPSYS',\n 'CLOUD_SWLIB_USER', 'GSMUSER', 'MDDATA', 'XS$NULL',\n 'CLOUD_ENGINE_USER'\n )\n UNION\n SELECT\n 'User '\n || grantee\n || ' is directly granted '\n || privilege\n || ' privilege ' value\n FROM dba_sys_privs\n WHERE grantee NOT IN (SELECT role FROM dba_roles)\n AND privilege NOT IN\n (\n 'CREATE SEQUENCE',\n 'CREATE TRIGGER',\n 'CREATE CLUSTER',\n 'CREATE INDEXTYPE',\n 'CREATE PROCEDURE',\n 'CREATE TYPE',\n 'CREATE SESSION',\n 'CREATE OPERATOR',\n 'CREATE TABLE',\n 'UNLIMITED TABLESPACE' )\n AND grantee NOT IN\n (\n 'XDB', 'SYSTEM', 'SYS', 'LBACSYS',\n 'DVSYS', 'DVF', 'SYSMAN_RO', 'SYSMAN_BIPLATFORM',\n 'SYSMAN_MDS', 'SYSMAN_OPSS', 'SYSMAN_STB', 'PUBLIC',\n 'DBSNMP', 'SYSMAN', 'APEX_040200', 'WMSYS',\n 'SYSDG', 'SYSBACKUP', 'SPATIAL_WFS_ADMIN_USR',\n 'SPATIAL_CSW_ADMIN_US',\n 'SI_INFORMTN_SCHEMA', 'OUTLN', 'ORDSYS', 'ORDDATA',\n 'OJVMSYS', 'ORACLE_OCM', 'MDSYS', 'ORDPLUGINS',\n 'GSMADMIN_INTERNAL', 'FLOWS_FILES', 'DIP', 'CTXSYS',\n 'AUDSYS', 'APPQOSSYS', 'APEX_PUBLIC_USER', 'ANONYMOUS',\n 'SPATIAL_CSW_ADMIN_USR', 'SYSKM', 'SYSMAN_TYPES',\n 'MGMT_VIEW', 'EUS_ENGINE_USER', 'GSMCATUSER', 'OLAPSYS',\n 'CLOUD_SWLIB_USER',\n 'GSMUSER', 'MDDATA', 'XS$NULL', 'CLOUD_ENGINE_USER'\n )\n UNION\n SELECT\n 'User '\n || username\n || ' is granted '\n || privilege\n || ' privilege via role '\n || rp.granted_role value\n FROM dba_users u,\n dba_role_privs rp,\n dba_sys_privs sp\n WHERE username = rp.grantee\n AND rp.granted_role = sp.grantee\n AND privilege NOT IN\n (\n 'CREATE SEQUENCE',\n 'CREATE TRIGGER',\n 'SET CONTAINER',\n 'CREATE CLUSTER',\n 'CREATE PROCEDURE',\n 'CREATE TYPE',\n 'CREATE SESSION',\n 'CREATE OPERATOR',\n 'CREATE TABLE',\n 'CREATE INDEXTYPE'\n )\n AND username NOT IN\n (\n 'XDB', 'SYSTEM', 'SYS', 'LBACSYS',\n 'DVSYS', 'DVF', 'SYSMAN_RO', 'SYSMAN_BIPLATFORM',\n 'SYSMAN_MDS', 'SYSMAN_OPSS', 'SYSMAN_STB', 'DBSNMP',\n 'SYSMAN', 'APEX_040200', 'WMSYS', 'SYSDG',\n 'SYSBACKUP', 'SPATIAL_WFS_ADMIN_USR',\n 'SPATIAL_CSW_ADMIN_US','GSMCATUSER',\n 'OLAPSYS', 'SI_INFORMTN_SCHEMA', 'OUTLN', 'ORDSYS',\n 'ORDDATA', 'OJVMSYS', 'ORACLE_OCM', 'MDSYS',\n 'ORDPLUGINS', 'GSMADMIN_INTERNAL', 'MDDATA',\n 'FLOWS_FILES', 'DIP', 'CTXSYS', 'AUDSYS', 'APPQOSSYS',\n 'APEX_PUBLIC_USER', 'ANONYMOUS',\n 'SPATIAL_CSW_ADMIN_USR','SYSKM',\n 'SYSMAN_TYPES', 'MGMT_VIEW', 'EUS_ENGINE_USER',\n 'EXFSYS','SYSMAN_APM' )\n AND rp.granted_role NOT IN\n (\n 'EXP_FULL_DATABASE','AQ_ADMINISTRATOR_ROLE','DV_REALM_RESOURCE',\n 'DBA','CDB_DBA','OEM_ADVISOR','RECOVERY_CATALOG_OWNER',\n 'EM_EXPRESS_ALL','SCHEDULER_ADMIN','OLAP_USER',\n 'RESOURCE','EM_EXPRESS_BASIC','IMP_FULL_DATABASE','CONNECT',\n 'AUDIT_ADMIN','DATAPUMP_EXP_FULL_DATABASE','GSMADMIN_ROLE',\n 'DV_REALM_OWNER','OLAP_DBA','JAVADEBUGPRIV',\n 'DATAPUMP_IMP_FULL_DATABASE','OEM_MONITOR',\n 'APEX_GRANTS_FOR_NEW_USERS_ROLE'\n )\n UNION\n\n SELECT\n 'User '\n ||grantee\n ||' is granted '\n ||privilege\n ||' on '\n ||owner\n ||'.'\n ||table_name\n ||'.'\n ||column_name\n ||' by '\n ||grantor\n FROM dba_col_privs\n WHERE grantee NOT IN\n (\n 'XDB', 'SYSTEM', 'SYS', 'LBACSYS',\n 'DVSYS', 'DVF', 'SYSMAN_RO', 'SYSMAN_BIPLATFORM',\n 'SYSMAN_MDS', 'SYSMAN_OPSS', 'SYSMAN_STB', 'DBSNMP',\n 'SYSMAN', 'APEX_040200', 'WMSYS', 'SYSDG',\n 'SYSBACKUP', 'SPATIAL_WFS_ADMIN_USR',\n 'SPATIAL_CSW_ADMIN_US','GSMCATUSER',\n 'OLAPSYS', 'SI_INFORMTN_SCHEMA', 'OUTLN', 'ORDSYS',\n 'ORDDATA', 'OJVMSYS', 'ORACLE_OCM', 'MDSYS',\n 'ORDPLUGINS', 'GSMADMIN_INTERNAL', 'MDDATA',\n 'FLOWS_FILES', 'IMP_FULL_DATABASE',\n 'DIP', 'CTXSYS', 'AUDSYS', 'APPQOSSYS',\n 'APEX_PUBLIC_USER', 'ANONYMOUS',\n 'SPATIAL_CSW_ADMIN_USR','SYSKM',\n 'SYSMAN_TYPES', 'MGMT_VIEW', 'EUS_ENGINE_USER',\n 'EXFSYS','SYSMAN_APM'\n )\n ;\n\n (The lists of special accounts that are excluded from this requirement may not\n be complete. It is expected that the DBA will edit the lists to suit local\n circumstances, adding other special accounts as necessary, and removing any\n that are not supposed to be in use in the Oracle deployment that is under\n review. Similarly, the lists of privileges and roles excluded from the\n subqueries may be modified according to circumstances.)", + "fix": "Define DBMS user roles based on privilege and job function\n requirements.\n\n Assign the required privileges to the role, and assign the role to authorized\n DBMS user accounts.\n\n Revoke any privileges directly assigned to DBMS user accounts, and assign them\n to a role the DBMS user already has assigned." }, - "code": "control 'V-61751' do\n title \"The DBMS must employ strong identification and authentication\n techniques when establishing nonlocal maintenance and diagnostic sessions.\"\n desc \"Non-local maintenance and diagnostic activities are those activities\n conducted by individuals communicating through a network, either an external\n network (e.g., the Internet) or an internal network.\n\n The act of managing systems and applications includes the ability to access\n sensitive application information, such as system configuration details,\n diagnostic information, user information, and potentially sensitive application\n data.\n\n When applications provide a remote management capability inherent to the\n application, the application needs to ensure the identification and\n authentication techniques used to remotely access the system are strong enough\n to protect the system. If the communication channel is not adequately\n protected, authentication information, application data, and configuration\n information could be compromised.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000185-DB-000116'\n tag \"gid\": 'V-61751'\n tag \"rid\": 'SV-76241r1_rule'\n tag \"stig_id\": 'O121-C2-016100'\n tag \"fix_id\": 'F-67667r1_fix'\n tag \"cci\": ['CCI-000877']\n tag \"nist\": ['MA-4 c)', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Review DBMS settings to determine whether strong identification\n and authentication techniques are required for nonlocal maintenance and\n diagnostic sessions.\n\n If strong identification and authentication techniques are not required, this\n is a finding.\"\n tag \"fix\": \"Configure DBMS settings to use strong identification and\n authentication techniques for nonlocal maintenance and diagnostic sessions.\"\n describe 'A manual review is required to ensure the DBMS employs strong identification and authentication\n techniques when establishing nonlocal maintenance and diagnostic sessions' do\n skip 'A manual review is required to ensure the DBMS employs strong identification and authentication\n techniques when establishing nonlocal maintenance and diagnostic sessions'\n end\nend\n", + "code": "control 'V-61809' do\n title \"The DBMS must implement separation of duties through assigned\n information access authorizations.\"\n desc \"Separation of duties is a prevalent Information Technology control\n that is implemented at different layers of the information system, including\n the operating system and in applications. It serves to eliminate or reduce the\n possibility that a single user may carry out a prohibited action. Separation of\n duties requires that the person accountable for approving an action is not the\n same person who is tasked with implementing or carrying out that action.\n\n Additionally, the person or entity accountable for monitoring the activity\n must be separate as well. To meet this requirement, applications, when\n applicable, shall be divided where functionality is based on roles and duties.\n Examples of separation of duties include: (i) mission functions and distinct\n information system support functions are divided among different\n individuals/roles; (ii) different individuals perform information system\n support functions (e.g., system management, systems programming, configuration\n management, quality assurance and testing, network security); (iii) security\n personnel who administer access control functions do not administer audit\n functions; and (iv) different administrator accounts for different roles.\n\n Privileges granted outside the context of the application user job function\n are more likely to go unmanaged or without oversight for authorization.\n Maintenance of privileges using roles defined for discrete job functions offers\n improved oversight of application user privilege assignments and helps to\n protect against unauthorized privilege assignment.\n \"\n impact 0.3\n tag \"gtitle\": 'SRG-APP-000062-DB-000009'\n tag \"gid\": 'V-61809'\n tag \"rid\": 'SV-76299r3_rule'\n tag \"stig_id\": 'O121-C3-003300'\n tag \"fix_id\": 'F-67725r1_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\": \"Obtain a list of privileges assigned to the DBMS user accounts.\n If any direct privilege assignments exist that can be assigned to a role, this\n is a finding.\n\n SELECT\n 'User '\n || grantee\n || ' is directly granted '\n || privilege\n || ' privilege on '\n || table_name value\n FROM dba_tab_privs\n WHERE grantee NOT IN (SELECT role FROM dba_roles)\n AND grantee NOT IN\n (\n 'XDB', 'SYSTEM', 'SYS', 'LBACSYS',\n 'DVSYS', 'DVF', 'SYSMAN_RO', 'SYSMAN_BIPLATFORM',\n 'SYSMAN_MDS', 'SYSMAN_OPSS', 'SYSMAN_STB', 'PUBLIC',\n 'DBSNMP', 'SYSMAN', 'APEX_040200', 'WMSYS',\n 'SYSDG', 'SYSBACKUP', 'SPATIAL_WFS_ADMIN_USR',\n 'SPATIAL_CSW_ADMIN_US',\n 'SI_INFORMTN_SCHEMA', 'OUTLN', 'ORDSYS', 'ORDDATA',\n 'OJVMSYS', 'ORACLE_OCM', 'MDSYS', 'ORDPLUGINS',\n 'GSMADMIN_INTERNAL', 'FLOWS_FILES', 'DIP', 'CTXSYS',\n 'AUDSYS', 'APPQOSSYS', 'APEX_PUBLIC_USER', 'ANONYMOUS',\n 'SPATIAL_CSW_ADMIN_USR', 'SYSKM', 'SYSMAN_TYPES',\n 'MGMT_VIEW', 'EUS_ENGINE_USER', 'GSMCATUSER', 'OLAPSYS',\n 'CLOUD_SWLIB_USER', 'GSMUSER', 'MDDATA', 'XS$NULL',\n 'CLOUD_ENGINE_USER'\n )\n UNION\n SELECT\n 'User '\n || grantee\n || ' is directly granted '\n || privilege\n || ' privilege ' value\n FROM dba_sys_privs\n WHERE grantee NOT IN (SELECT role FROM dba_roles)\n AND privilege NOT IN\n (\n 'CREATE SEQUENCE',\n 'CREATE TRIGGER',\n 'CREATE CLUSTER',\n 'CREATE INDEXTYPE',\n 'CREATE PROCEDURE',\n 'CREATE TYPE',\n 'CREATE SESSION',\n 'CREATE OPERATOR',\n 'CREATE TABLE',\n 'UNLIMITED TABLESPACE' )\n AND grantee NOT IN\n (\n 'XDB', 'SYSTEM', 'SYS', 'LBACSYS',\n 'DVSYS', 'DVF', 'SYSMAN_RO', 'SYSMAN_BIPLATFORM',\n 'SYSMAN_MDS', 'SYSMAN_OPSS', 'SYSMAN_STB', 'PUBLIC',\n 'DBSNMP', 'SYSMAN', 'APEX_040200', 'WMSYS',\n 'SYSDG', 'SYSBACKUP', 'SPATIAL_WFS_ADMIN_USR',\n 'SPATIAL_CSW_ADMIN_US',\n 'SI_INFORMTN_SCHEMA', 'OUTLN', 'ORDSYS', 'ORDDATA',\n 'OJVMSYS', 'ORACLE_OCM', 'MDSYS', 'ORDPLUGINS',\n 'GSMADMIN_INTERNAL', 'FLOWS_FILES', 'DIP', 'CTXSYS',\n 'AUDSYS', 'APPQOSSYS', 'APEX_PUBLIC_USER', 'ANONYMOUS',\n 'SPATIAL_CSW_ADMIN_USR', 'SYSKM', 'SYSMAN_TYPES',\n 'MGMT_VIEW', 'EUS_ENGINE_USER', 'GSMCATUSER', 'OLAPSYS',\n 'CLOUD_SWLIB_USER',\n 'GSMUSER', 'MDDATA', 'XS$NULL', 'CLOUD_ENGINE_USER'\n )\n UNION\n SELECT\n 'User '\n || username\n || ' is granted '\n || privilege\n || ' privilege via role '\n || rp.granted_role value\n FROM dba_users u,\n dba_role_privs rp,\n dba_sys_privs sp\n WHERE username = rp.grantee\n AND rp.granted_role = sp.grantee\n AND privilege NOT IN\n (\n 'CREATE SEQUENCE',\n 'CREATE TRIGGER',\n 'SET CONTAINER',\n 'CREATE CLUSTER',\n 'CREATE PROCEDURE',\n 'CREATE TYPE',\n 'CREATE SESSION',\n 'CREATE OPERATOR',\n 'CREATE TABLE',\n 'CREATE INDEXTYPE'\n )\n AND username NOT IN\n (\n 'XDB', 'SYSTEM', 'SYS', 'LBACSYS',\n 'DVSYS', 'DVF', 'SYSMAN_RO', 'SYSMAN_BIPLATFORM',\n 'SYSMAN_MDS', 'SYSMAN_OPSS', 'SYSMAN_STB', 'DBSNMP',\n 'SYSMAN', 'APEX_040200', 'WMSYS', 'SYSDG',\n 'SYSBACKUP', 'SPATIAL_WFS_ADMIN_USR',\n 'SPATIAL_CSW_ADMIN_US','GSMCATUSER',\n 'OLAPSYS', 'SI_INFORMTN_SCHEMA', 'OUTLN', 'ORDSYS',\n 'ORDDATA', 'OJVMSYS', 'ORACLE_OCM', 'MDSYS',\n 'ORDPLUGINS', 'GSMADMIN_INTERNAL', 'MDDATA',\n 'FLOWS_FILES', 'DIP', 'CTXSYS', 'AUDSYS', 'APPQOSSYS',\n 'APEX_PUBLIC_USER', 'ANONYMOUS',\n 'SPATIAL_CSW_ADMIN_USR','SYSKM',\n 'SYSMAN_TYPES', 'MGMT_VIEW', 'EUS_ENGINE_USER',\n 'EXFSYS','SYSMAN_APM' )\n AND rp.granted_role NOT IN\n (\n 'EXP_FULL_DATABASE','AQ_ADMINISTRATOR_ROLE','DV_REALM_RESOURCE',\n 'DBA','CDB_DBA','OEM_ADVISOR','RECOVERY_CATALOG_OWNER',\n 'EM_EXPRESS_ALL','SCHEDULER_ADMIN','OLAP_USER',\n 'RESOURCE','EM_EXPRESS_BASIC','IMP_FULL_DATABASE','CONNECT',\n 'AUDIT_ADMIN','DATAPUMP_EXP_FULL_DATABASE','GSMADMIN_ROLE',\n 'DV_REALM_OWNER','OLAP_DBA','JAVADEBUGPRIV',\n 'DATAPUMP_IMP_FULL_DATABASE','OEM_MONITOR',\n 'APEX_GRANTS_FOR_NEW_USERS_ROLE'\n )\n UNION\n\n SELECT\n 'User '\n ||grantee\n ||' is granted '\n ||privilege\n ||' on '\n ||owner\n ||'.'\n ||table_name\n ||'.'\n ||column_name\n ||' by '\n ||grantor\n FROM dba_col_privs\n WHERE grantee NOT IN\n (\n 'XDB', 'SYSTEM', 'SYS', 'LBACSYS',\n 'DVSYS', 'DVF', 'SYSMAN_RO', 'SYSMAN_BIPLATFORM',\n 'SYSMAN_MDS', 'SYSMAN_OPSS', 'SYSMAN_STB', 'DBSNMP',\n 'SYSMAN', 'APEX_040200', 'WMSYS', 'SYSDG',\n 'SYSBACKUP', 'SPATIAL_WFS_ADMIN_USR',\n 'SPATIAL_CSW_ADMIN_US','GSMCATUSER',\n 'OLAPSYS', 'SI_INFORMTN_SCHEMA', 'OUTLN', 'ORDSYS',\n 'ORDDATA', 'OJVMSYS', 'ORACLE_OCM', 'MDSYS',\n 'ORDPLUGINS', 'GSMADMIN_INTERNAL', 'MDDATA',\n 'FLOWS_FILES', 'IMP_FULL_DATABASE',\n 'DIP', 'CTXSYS', 'AUDSYS', 'APPQOSSYS',\n 'APEX_PUBLIC_USER', 'ANONYMOUS',\n 'SPATIAL_CSW_ADMIN_USR','SYSKM',\n 'SYSMAN_TYPES', 'MGMT_VIEW', 'EUS_ENGINE_USER',\n 'EXFSYS','SYSMAN_APM'\n )\n ;\n\n (The lists of special accounts that are excluded from this requirement may not\n be complete. It is expected that the DBA will edit the lists to suit local\n circumstances, adding other special accounts as necessary, and removing any\n that are not supposed to be in use in the Oracle deployment that is under\n review. Similarly, the lists of privileges and roles excluded from the\n subqueries may be modified according to circumstances.)\"\n tag \"fix\": \"Define DBMS user roles based on privilege and job function\n requirements.\n\n Assign the required privileges to the role, and assign the role to authorized\n DBMS user accounts.\n\n Revoke any privileges directly assigned to DBMS user accounts, and assign them\n to a role the DBMS user already has assigned.\"\n describe 'A manual review is required to ensure the DBMS implements separation of duties through assigned\n information access authorizations' do\n skip 'A manual review is required to ensure the DBMS implements separation of duties through assigned\n information access authorizations'\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61751.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61809.rb", "line": 1 }, - "id": "V-61751" + "id": "V-61809" }, { - "title": "The system must protect audit information from any type of\n unauthorized access.", - "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 difficult, if not impossible, to achieve. In addition, access to\n audit records provides information an attacker could potentially use to his or\n her advantage.\n\n To ensure the veracity of audit data, the information system and/or the\n application must protect audit information from any and all unauthorized\n access. This includes read, write, copy, etc.\n\n This requirement can be achieved through multiple methods which will depend\n upon system architecture and design. Some commonly employed methods include\n ensuring log files enjoy the proper file system permissions utilizing file\n system protections and limiting log data location.\n\n Additionally, applications with user interfaces to audit records must not\n allow for the unfettered manipulation of or access to those records via the\n application. If the application provides access to the audit data, the\n application becomes accountable for ensuring that audit information is\n protected from unauthorized access.\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.", + "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": "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 difficult, if not impossible, to achieve. In addition, access to\n audit records provides information an attacker could potentially use to his or\n her advantage.\n\n To ensure the veracity of audit data, the information system and/or the\n application must protect audit information from any and all unauthorized\n access. This includes read, write, copy, etc.\n\n This requirement can be achieved through multiple methods which will depend\n upon system architecture and design. Some commonly employed methods include\n ensuring log files enjoy the proper file system permissions utilizing file\n system protections and limiting log data location.\n\n Additionally, applications with user interfaces to audit records must not\n allow for the unfettered manipulation of or access to those records via the\n application. If the application provides access to the audit data, the\n application becomes accountable for ensuring that audit information is\n protected from unauthorized access.\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." + "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, + "impact": 0.5, "refs": [], "tags": { - "gtitle": "SRG-APP-000118-DB-000059", - "gid": "V-61653", - "rid": "SV-76143r2_rule", - "stig_id": "O121-C2-009300", - "fix_id": "F-67567r3_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-000162" + "CCI-000158" ], "nist": [ - "AU-9", + "AU-7 (1)", "Rev_4" ], "false_negatives": null, @@ -4846,35 +4942,39 @@ "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 access.\n\n If appropriate controls and permissions do not exist, this is a finding.\n\n - - - - -\n If Standard Auditing is used:\n DBA_TAB_PRIVS describes all object grants in the database. Check to see who\n has permissions on the AUD$ table.\n\n Related View\n\n DBA_TAB_PRIVS describes the object grants for which the current user is the\n object owner, grantor, or grantee.\n Column Datatype NULL Description\n GRANTEE VARCHAR2(30) NOT NULL Name of the user to whom access was granted\n 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 with the\n GRANT OPTION (YES) or not (NO)\n HIERARCHY VARCHAR2(3) Indicates whether the privilege was granted with the\n HIERARCHY OPTION (YES) or not (NO)\n COMMON VARCHAR2(3)\n TYPE VARCHAR2(24)\n\n sqlplus connect as sysdba;\n\n SQL> SELECT GRANTEE, TABLE_NAME, PRIVILEGE\n FROM DBA_TAB_PRIVS where table_name = 'AUD$';\n\n If Unified Auditing is used:\n DBA_TAB_PRIVS describes all object grants in the database. Check to see who\n has permissions on the AUDSYS tables.\n\n Related View\n\n DBA_TAB_PRIVS describes the object grants for which the current user is the\n object owner, grantor, or grantee.\n Column Datatype NULL Description\n GRANTEE VARCHAR2(30) NOT NULL Name of the user to whom access was\n 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 with\n the GRANT OPTION (YES) or not (NO)\n HIERARCHY VARCHAR2(3) Indicates whether the privilege was granted with\n 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 access, whether stored in the database itself or at the\n OS level." + "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-61653' do\n title \"The system must protect audit information from any type of\n unauthorized access.\"\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 difficult, if not impossible, to achieve. In addition, access to\n audit records provides information an attacker could potentially use to his or\n her advantage.\n\n To ensure the veracity of audit data, the information system and/or the\n application must protect audit information from any and all unauthorized\n access. This includes read, write, copy, etc.\n\n This requirement can be achieved through multiple methods which will depend\n upon system architecture and design. Some commonly employed methods include\n ensuring log files enjoy the proper file system permissions utilizing file\n system protections and limiting log data location.\n\n Additionally, applications with user interfaces to audit records must not\n allow for the unfettered manipulation of or access to those records via the\n application. If the application provides access to the audit data, the\n application becomes accountable for ensuring that audit information is\n protected from unauthorized access.\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 impact 0.5\n tag \"gtitle\": 'SRG-APP-000118-DB-000059'\n tag \"gid\": 'V-61653'\n tag \"rid\": 'SV-76143r2_rule'\n tag \"stig_id\": 'O121-C2-009300'\n tag \"fix_id\": 'F-67567r3_fix'\n tag \"cci\": ['CCI-000162']\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 access.\n\n If appropriate controls and permissions do not exist, this is a finding.\n\n - - - - -\n If Standard Auditing is used:\n DBA_TAB_PRIVS describes all object grants in the database. Check to see who\n has permissions on the AUD$ table.\n\n Related View\n\n DBA_TAB_PRIVS describes the object grants for which the current user is the\n object owner, grantor, or grantee.\n Column Datatype NULL Description\n GRANTEE VARCHAR2(30) NOT NULL Name of the user to whom access was granted\n 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 with the\n GRANT OPTION (YES) or not (NO)\n HIERARCHY VARCHAR2(3) Indicates whether the privilege was granted with the\n HIERARCHY OPTION (YES) or not (NO)\n COMMON VARCHAR2(3)\n TYPE VARCHAR2(24)\n\n sqlplus connect as sysdba;\n\n SQL> SELECT GRANTEE, TABLE_NAME, PRIVILEGE\n FROM DBA_TAB_PRIVS where table_name = 'AUD$';\n\n If Unified Auditing is used:\n DBA_TAB_PRIVS describes all object grants in the database. Check to see who\n has permissions on the AUDSYS tables.\n\n Related View\n\n DBA_TAB_PRIVS describes the object grants for which the current user is the\n object owner, grantor, or grantee.\n Column Datatype NULL Description\n GRANTEE VARCHAR2(30) NOT NULL Name of the user to whom access was\n 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 with\n the GRANT OPTION (YES) or not (NO)\n HIERARCHY VARCHAR2(3) Indicates whether the privilege was granted with\n 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 access, whether stored in the database itself or at the\n OS level.\"\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-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-61653.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61649.rb", "line": 1 }, - "id": "V-61653" + "id": "V-61649" }, { - "title": "Oracle roles granted using the WITH ADMIN OPTION must not be granted\n to unauthorized accounts.", - "desc": "The WITH ADMIN OPTION allows the grantee to grant a role to another\n database account. Best security practice restricts the privilege of assigning\n privileges to authorized personnel. Authorized personnel include DBAs, object\n owners, and, where designed and included in the application's functions,\n application administrators. Restricting privilege-granting functions to\n authorized accounts can help decrease mismanagement of privileges and wrongful\n assignments to unauthorized accounts.", + "title": "The DBMS, when using PKI-based authentication, must enforce authorized\n access to the corresponding private key.", + "desc": "The cornerstone of the PKI is the private key used to encrypt or\n digitally sign information.\n\n If the private key is stolen, this will lead to the compromise of the\n authentication and non-repudiation gained through PKI because the attacker can\n use the private key to digitally sign documents and can pretend to be the\n authorized user.\n\n Both the holders of a digital certificate and the issuing authority must\n protect the computers, storage devices, or whatever they use to keep the\n private keys.\n\n All access to the private key of the DBMS must be restricted to authorized\n and authenticated users. If unauthorized users have access to the DBMS’s\n private key, an attacker could gain access to the primary key and use it to\n impersonate the database on the network.\n\n Transport Layer Security (TLS) is the successor protocol to Secure Sockets\n Layer (SSL). Although the Oracle configuration parameters have names including\n 'SSL', such as SSL_VERSION and SSL_CIPHER_SUITES, they refer to TLS.", "descriptions": { - "default": "The WITH ADMIN OPTION allows the grantee to grant a role to another\n database account. Best security practice restricts the privilege of assigning\n privileges to authorized personnel. Authorized personnel include DBAs, object\n owners, and, where designed and included in the application's functions,\n application administrators. Restricting privilege-granting functions to\n authorized accounts can help decrease mismanagement of privileges and wrongful\n assignments to unauthorized accounts." + "default": "The cornerstone of the PKI is the private key used to encrypt or\n digitally sign information.\n\n If the private key is stolen, this will lead to the compromise of the\n authentication and non-repudiation gained through PKI because the attacker can\n use the private key to digitally sign documents and can pretend to be the\n authorized user.\n\n Both the holders of a digital certificate and the issuing authority must\n protect the computers, storage devices, or whatever they use to keep the\n private keys.\n\n All access to the private key of the DBMS must be restricted to authorized\n and authenticated users. If unauthorized users have access to the DBMS’s\n private key, an attacker could gain access to the primary key and use it to\n impersonate the database on the network.\n\n Transport Layer Security (TLS) is the successor protocol to Secure Sockets\n Layer (SSL). Although the Oracle configuration parameters have names including\n 'SSL', such as SSL_VERSION and SSL_CIPHER_SUITES, they refer to TLS." }, "impact": 0, - "refs": [], + "refs": [ + { + "ref": [] + } + ], "tags": { - "gtitle": "SRG-APP-000516-DB-999900", - "gid": "V-61437", - "rid": "SV-75927r3_rule", - "stig_id": "O121-BP-022500", - "fix_id": "F-67353r2_fix", + "gtitle": "SRG-APP-000176-DB-000068", + "gid": "V-61543", + "rid": "SV-76033r3_rule", + "stig_id": "O121-C1-015400", + "fix_id": "F-67459r1_fix", "cci": [ - "CCI-000366" + "CCI-000186" ], "nist": [ - "CM-6 b", + "IA-5 (2) (b)", "Rev_4" ], "false_negatives": null, @@ -4887,35 +4987,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "A default Oracle Database installation provides a set of\n predefined administrative accounts and non-administrative accounts. These are\n accounts that have special privileges required to administer areas of the\n database, such as the CREATE ANY TABLE or ALTER SESSION privilege, or EXECUTE\n privileges on packages owned by the SYS schema. The default tablespace for\n administrative accounts is either SYSTEM or SYSAUX. Non-administrative user\n accounts only have the minimum privileges needed to perform their jobs. Their\n default tablespace is USERS.\n\n To protect these accounts from unauthorized access, the installation process\n expires and locks most of these accounts, except where noted below. The\n database administrator is responsible for unlocking and resetting these\n accounts, as required.\n\n Non-Administrative Accounts - Expired and locked:\n APEX_PUBLIC_USER, DIP, FLOWS_040100*, FLOWS_FILES, MDDATA, ORACLE_OCM,\n SPATIAL_CSW_ADMIN_USR, SPATIAL_WFS_ADMIN_USR, XS$NULL\n\n Administrative Accounts - Expired and Locked:\n ANONYMOUS, CTXSTS, EXFSYS, LBACSYS, MDSYS, OLAPSYS, OEDDATA, OWBSYS,\n ORDPLUGINS, ORDSYS, OUTLN, SI_INFORMTN_SCHEMA, WK_TEST, WK_SYS, WKPROXY, WMSYS,\n XDB\n\n Administrative Accounts - Open:\n DBSNMP, MGMT_VIEW, SYS, SYSMAN, SYSTEM\n\n * Subject to change based on version installed\n\n Run the SQL statement:\n\n select grantee||': '||granted_role from dba_role_privs\n where admin_option = 'YES' and grantee not in\n (select distinct owner from dba_objects)\n and grantee not in\n (select grantee from dba_role_privs\n where granted_role = 'DBA')\n order by grantee;\n\n (With respect to the list of special accounts that are excluded from this\n requirement, it is expected that the DBA will maintain the list to suit local\n circumstances, adding special accounts as necessary and removing any that are\n not supposed to be in use in the Oracle deployment that is under review.)\n\n Review the System Security Plan to confirm any grantees listed are\n ISSO-authorized DBA accounts or application administration roles.\n\n If any grantees listed are not authorized and documented, this is a finding.", - "fix": "Revoke assignment of roles with the WITH ADMIN OPTION from\n unauthorized grantees and re-grant them without the option if required.\n\n SQL statements to remove the admin option from an unauthorized grantee:\n revoke from ;\n grant to ;\n\n Restrict use of the WITH ADMIN OPTION to authorized administrators.\n\n Document authorized role assignments with the WITH ADMIN OPTION in the System\n Security Plan." + "check": "If PKI is not enabled in Oracle Database, this is not a finding.\n\n Review DBMS configuration to determine whether appropriate access controls\n exist to protect the DBMS’s private key. If strong access controls do not exist\n to enforce authorized access to the private key, this is a finding.\n\n - - - - -\n The database supports authentication by using digital certificates over TLS in\n addition to the native encryption and data integrity capabilities of these\n protocols.\n\n An Oracle Wallet is a container that is used to store authentication and\n signing credentials, including private keys, certificates, and trusted\n certificates needed by TLS. In an Oracle environment, every entity that\n communicates over TLS must have a wallet containing an X.509 version 3\n certificate, private key, and list of trusted certificates, with the exception\n of Diffie-Hellman.\n\n If the $ORACLE_HOME/network/admin/sqlnet.ora contains the following entries,\n TLS is installed. (Note: This assumes that a single sqlnet.ora file, in the\n default location, is in use. Please see the supplemental file \"Non-default\n sqlnet.ora configurations.pdf\" for how to find multiple and/or differently\n located sqlnet.ora files.)\n\n WALLET_LOCATION = (SOURCE=\n (METHOD = FILE)\n (METHOD_DATA =\n DIRECTORY=/wallet)\n\n SSL_CIPHER_SUITES=(SSL_cipher_suiteExample)\n SSL_VERSION = 1.2 or 1.1\n SSL_CLIENT_AUTHENTICATION=FALSE/TRUE\n\n Note: \"SSL_VERSION = 1.2 or 1.1\" is the actual value, not a suggestion to\n use one or the other.", + "fix": "Implement strong access and authentication controls to protect\n the database’s private key.\n\n Configure the database to support Transport Layer Security (TLS) protocols and\n the Oracle Wallet to store authentication and signing credentials, including\n private keys." }, - "code": "control 'V-61437' do\n title \"Oracle roles granted using the WITH ADMIN OPTION must not be granted\n to unauthorized accounts.\"\n desc \"The WITH ADMIN OPTION allows the grantee to grant a role to another\n database account. Best security practice restricts the privilege of assigning\n privileges to authorized personnel. Authorized personnel include DBAs, object\n owners, and, where designed and included in the application's functions,\n application administrators. Restricting privilege-granting functions to\n authorized accounts can help decrease mismanagement of privileges and wrongful\n assignments to unauthorized accounts.\"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000516-DB-999900'\n tag \"gid\": 'V-61437'\n tag \"rid\": 'SV-75927r3_rule'\n tag \"stig_id\": 'O121-BP-022500'\n tag \"fix_id\": 'F-67353r2_fix'\n tag \"cci\": ['CCI-000366']\n tag \"nist\": ['CM-6 b', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"A default Oracle Database installation provides a set of\n predefined administrative accounts and non-administrative accounts. These are\n accounts that have special privileges required to administer areas of the\n database, such as the CREATE ANY TABLE or ALTER SESSION privilege, or EXECUTE\n privileges on packages owned by the SYS schema. The default tablespace for\n administrative accounts is either SYSTEM or SYSAUX. Non-administrative user\n accounts only have the minimum privileges needed to perform their jobs. Their\n default tablespace is USERS.\n\n To protect these accounts from unauthorized access, the installation process\n expires and locks most of these accounts, except where noted below. The\n database administrator is responsible for unlocking and resetting these\n accounts, as required.\n\n Non-Administrative Accounts - Expired and locked:\n APEX_PUBLIC_USER, DIP, FLOWS_040100*, FLOWS_FILES, MDDATA, ORACLE_OCM,\n SPATIAL_CSW_ADMIN_USR, SPATIAL_WFS_ADMIN_USR, XS$NULL\n\n Administrative Accounts - Expired and Locked:\n ANONYMOUS, CTXSTS, EXFSYS, LBACSYS, MDSYS, OLAPSYS, OEDDATA, OWBSYS,\n ORDPLUGINS, ORDSYS, OUTLN, SI_INFORMTN_SCHEMA, WK_TEST, WK_SYS, WKPROXY, WMSYS,\n XDB\n\n Administrative Accounts - Open:\n DBSNMP, MGMT_VIEW, SYS, SYSMAN, SYSTEM\n\n * Subject to change based on version installed\n\n Run the SQL statement:\n\n select grantee||': '||granted_role from dba_role_privs\n where admin_option = 'YES' and grantee not in\n (select distinct owner from dba_objects)\n and grantee not in\n (select grantee from dba_role_privs\n where granted_role = 'DBA')\n order by grantee;\n\n (With respect to the list of special accounts that are excluded from this\n requirement, it is expected that the DBA will maintain the list to suit local\n circumstances, adding special accounts as necessary and removing any that are\n not supposed to be in use in the Oracle deployment that is under review.)\n\n Review the System Security Plan to confirm any grantees listed are\n ISSO-authorized DBA accounts or application administration roles.\n\n If any grantees listed are not authorized and documented, this is a finding.\"\n tag \"fix\": \"Revoke assignment of roles with the WITH ADMIN OPTION from\n unauthorized grantees and re-grant them without the option if required.\n\n SQL statements to remove the admin option from an unauthorized grantee:\n revoke from ;\n grant to ;\n\n Restrict use of the WITH ADMIN OPTION to authorized administrators.\n\n Document authorized role assignments with the WITH ADMIN OPTION in the System\n Security Plan.\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n users_with_admin_option = sql.query(\"select grantee from dba_role_privs\n where admin_option = 'YES' and grantee not in\n (select distinct owner from dba_objects)\n and grantee not in\n (select grantee from dba_role_privs\n where granted_role = 'DBA')\n order by grantee;\").column('grantee').uniq\n if users_with_admin_option.empty?\n impact 0.0\n describe 'There are no oracle users with the admin option, therefore control N/A' do\n skip 'There are no oracle users with the admin option, therefore control N/A'\n end\n else\n users_with_admin_option.each do |user|\n describe \"oracle users with admin option: #{user}\" do\n subject { user }\n it { should be_in input('allowed_dbadmin_users') }\n end\n end\n end\nend\n", + "code": " control 'V-61543' 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-61437.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61543.rb", "line": 1 }, - "id": "V-61437" + "id": "V-61543" }, { - "title": "The DBMS must take needed steps to protect data at rest and ensure\n confidentiality and integrity of application data.", - "desc": "This control is intended to address the confidentiality and integrity\n of information at rest in non-mobile devices and covers user information and\n system information. Information at rest refers to the state of information when\n it is located on a secondary storage device (e.g., disk drive, tape drive)\n within an organizational information system. Applications and application users\n generate information throughout the course of their application use.\n\n User-generated data and application specific configuration data both need\n to be protected. Configurations and/or rule sets for firewalls, gateways,\n intrusion detection/prevention systems, and filtering routers and authenticator\n content are examples of system information likely requiring protection.\n Organizations may choose to employ different mechanisms to achieve\n confidentiality and integrity protections, as appropriate.\n\n If the confidentiality and integrity of application data is not protected,\n the data will be open to compromise and unauthorized modification.", + "title": "Sensitive information from production database exports must be\n modified before import to a development database.", + "desc": "Data export from production databases may include sensitive data.\n Application developers do not have a need to know to sensitive data. Any access\n they may have to production data would be considered unauthorized access and\n subject the sensitive data to unlawful or unauthorized disclosure. See DODD\n 8500.1 for a definition of Sensitive Information.", "descriptions": { - "default": "This control is intended to address the confidentiality and integrity\n of information at rest in non-mobile devices and covers user information and\n system information. Information at rest refers to the state of information when\n it is located on a secondary storage device (e.g., disk drive, tape drive)\n within an organizational information system. Applications and application users\n generate information throughout the course of their application use.\n\n User-generated data and application specific configuration data both need\n to be protected. Configurations and/or rule sets for firewalls, gateways,\n intrusion detection/prevention systems, and filtering routers and authenticator\n content are examples of system information likely requiring protection.\n Organizations may choose to employ different mechanisms to achieve\n confidentiality and integrity protections, as appropriate.\n\n If the confidentiality and integrity of application data is not protected,\n the data will be open to compromise and unauthorized modification." + "default": "Data export from production databases may include sensitive data.\n Application developers do not have a need to know to sensitive data. Any access\n they may have to production data would be considered unauthorized access and\n subject the sensitive data to unlawful or unauthorized disclosure. See DODD\n 8500.1 for a definition of Sensitive Information." }, "impact": 0.5, "refs": [], "tags": { - "gtitle": "SRG-APP-000231-DB-000154", - "gid": "V-61771", - "rid": "SV-76261r2_rule", - "stig_id": "O121-C2-018300", - "fix_id": "F-67687r1_fix", + "gtitle": "SRG-APP-000516-DB-999900", + "gid": "V-61453", + "rid": "SV-75943r2_rule", + "stig_id": "O121-BP-023300", + "fix_id": "F-67369r1_fix", "cci": [ - "CCI-001199" + "CCI-000366" ], "nist": [ - "SC-28", + "CM-6 b", "Rev_4" ], "false_negatives": null, @@ -4928,35 +5028,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "If the application owner and Authorizing Official have\n determined that encryption of data at rest is NOT required, this is not a\n finding.\n\n Review DBMS settings to determine whether controls exist to protect the\n confidentiality and integrity of data at rest in the database.\n\n If controls do not exist or are not enabled, this is a finding.\n\n To ensure that the appropriate controls are in place, discuss the precautions\n taken with the site Database Administrators and System Administrators and try\n to modify data at rest.\n\n Oracle recommends using Transparent Data Encryption to protect data.\n\n In order to check to see if the data is encrypted, for example, upon an\n auditor's request, Oracle provides views that document the encryption status of\n the database. For TDE column encryption, use the view 'dba_encrypted_columns',\n which lists the owner, table name, column name, encryption algorithm, and salt\n for all encrypted columns. For TDE tablespace encryption, the following SQL\n statement lists all encrypted tablespaces with their encryption algorithm and\n corresponding, encrypted, data files. Issue the following commands to check to\n see if the data at rest is encrypted.\n\n $ sqlplus connect as sysdba\n\n SQL> SELECT t.name \"TSName\",\n e.encryptionalg \"Algorithm\",\n d.file_name \"File Name\"\n FROM v$tablespace t,\n v$encrypted_tablespaces e,\n dba_data_files d\n WHERE t.ts# = e.ts#\n and t.name = d.tablespace_name;\n\n The next SQL statement lists the table owner, tables within encrypted\n tablespaces, and the encryption algorithm:\n\n SQL> SELECT a.owner \"Owner\",\n a.table_name \"Table Name\",\n e.encryptionalg \"Algorithm\"\n FROM dba_tables a,\n v$encrypted_tablespaces e\n WHERE a.tablespace_name in (select t.name from v$tablespace t,\n v$encrypted_tablespaces e where t.ts# = e.ts#);", - "fix": "Apply appropriate controls to protect the confidentiality and\n integrity of data at rest in the database.\n\n If no site-specific precautions are in place, use Oracle Advanced Security\n Option to encrypt data at rest.\n\n If ASO is not an option, use site-specific procedures to secure data at rest." + "check": "If the database being reviewed is a production database, this\n check is not a finding.\n\n Review policy, procedures and restrictions for data imports of production data\n containing sensitive information into development databases.\n\n If data imports of production data are allowed, review procedures for\n protecting any sensitive data included in production exports.\n\n If sensitive data is included in the exports and no procedures are in place to\n remove or modify the data to render it not sensitive prior to import into a\n development database or policy and procedures are not in place to ensure\n authorization of development personnel to access sensitive information\n contained in production data, this is a finding.", + "fix": "Develop, document and implement policy, procedures and\n restrictions for production data import.\n\n Require any users assigned privileges that allow the export of production data\n from the database to acknowledge understanding of import policies, procedures\n and restrictions.\n\n Restrict permissions of development personnel requiring use or access to\n production data imported into development databases containing sensitive\n information to authorized users.\n\n Implement policy and procedures to modify or remove sensitive information in\n production exports prior to import into development databases." }, - "code": "control 'V-61771' do\n title \"The DBMS must take needed steps to protect data at rest and ensure\n confidentiality and integrity of application data.\"\n desc \"This control is intended to address the confidentiality and integrity\n of information at rest in non-mobile devices and covers user information and\n system information. Information at rest refers to the state of information when\n it is located on a secondary storage device (e.g., disk drive, tape drive)\n within an organizational information system. Applications and application users\n generate information throughout the course of their application use.\n\n User-generated data and application specific configuration data both need\n to be protected. Configurations and/or rule sets for firewalls, gateways,\n intrusion detection/prevention systems, and filtering routers and authenticator\n content are examples of system information likely requiring protection.\n Organizations may choose to employ different mechanisms to achieve\n confidentiality and integrity protections, as appropriate.\n\n If the confidentiality and integrity of application data is not protected,\n the data will be open to compromise and unauthorized modification.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000231-DB-000154'\n tag \"gid\": 'V-61771'\n tag \"rid\": 'SV-76261r2_rule'\n tag \"stig_id\": 'O121-C2-018300'\n tag \"fix_id\": 'F-67687r1_fix'\n tag \"cci\": ['CCI-001199']\n tag \"nist\": ['SC-28', '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 application owner and Authorizing Official have\n determined that encryption of data at rest is NOT required, this is not a\n finding.\n\n Review DBMS settings to determine whether controls exist to protect the\n confidentiality and integrity of data at rest in the database.\n\n If controls do not exist or are not enabled, this is a finding.\n\n To ensure that the appropriate controls are in place, discuss the precautions\n taken with the site Database Administrators and System Administrators and try\n to modify data at rest.\n\n Oracle recommends using Transparent Data Encryption to protect data.\n\n In order to check to see if the data is encrypted, for example, upon an\n auditor's request, Oracle provides views that document the encryption status of\n the database. For TDE column encryption, use the view 'dba_encrypted_columns',\n which lists the owner, table name, column name, encryption algorithm, and salt\n for all encrypted columns. For TDE tablespace encryption, the following SQL\n statement lists all encrypted tablespaces with their encryption algorithm and\n corresponding, encrypted, data files. Issue the following commands to check to\n see if the data at rest is encrypted.\n\n $ sqlplus connect as sysdba\n\n SQL> SELECT t.name \\\"TSName\\\",\n e.encryptionalg \\\"Algorithm\\\",\n d.file_name \\\"File Name\\\"\n FROM v$tablespace t,\n v$encrypted_tablespaces e,\n dba_data_files d\n WHERE t.ts# = e.ts#\n and t.name = d.tablespace_name;\n\n The next SQL statement lists the table owner, tables within encrypted\n tablespaces, and the encryption algorithm:\n\n SQL> SELECT a.owner \\\"Owner\\\",\n a.table_name \\\"Table Name\\\",\n e.encryptionalg \\\"Algorithm\\\"\n FROM dba_tables a,\n v$encrypted_tablespaces e\n WHERE a.tablespace_name in (select t.name from v$tablespace t,\n v$encrypted_tablespaces e where t.ts# = e.ts#);\"\n tag \"fix\": \"Apply appropriate controls to protect the confidentiality and\n integrity of data at rest in the database.\n\n If no site-specific precautions are in place, use Oracle Advanced Security\n Option to encrypt data at rest.\n\n If ASO is not an option, use site-specific procedures to secure data at rest.\"\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\nend\n", + "code": "control 'V-61453' do\n title \"Sensitive information from production database exports must be\n modified before import to a development database.\"\n desc \"Data export from production databases may include sensitive data.\n Application developers do not have a need to know to sensitive data. Any access\n they may have to production data would be considered unauthorized access and\n subject the sensitive data to unlawful or unauthorized disclosure. See DODD\n 8500.1 for a definition of Sensitive Information.\"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000516-DB-999900'\n tag \"gid\": 'V-61453'\n tag \"rid\": 'SV-75943r2_rule'\n tag \"stig_id\": 'O121-BP-023300'\n tag \"fix_id\": 'F-67369r1_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 database being reviewed is a production database, this\n check is not a finding.\n\n Review policy, procedures and restrictions for data imports of production data\n containing sensitive information into development databases.\n\n If data imports of production data are allowed, review procedures for\n protecting any sensitive data included in production exports.\n\n If sensitive data is included in the exports and no procedures are in place to\n remove or modify the data to render it not sensitive prior to import into a\n development database or policy and procedures are not in place to ensure\n authorization of development personnel to access sensitive information\n contained in production data, this is a finding.\"\n tag \"fix\": \"Develop, document and implement policy, procedures and\n restrictions for production data import.\n\n Require any users assigned privileges that allow the export of production data\n from the database to acknowledge understanding of import policies, procedures\n and restrictions.\n\n Restrict permissions of development personnel requiring use or access to\n production data imported into development databases containing sensitive\n information to authorized users.\n\n Implement policy and procedures to modify or remove sensitive information in\n production exports prior to import into development databases.\"\n describe 'A manual review is required to ensure sensitive information from production database exports are\n modified before import to a development database' do\n skip 'A manual review is required to ensure sensitive information from production database exports are\n modified before import to a development database'\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61771.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61453.rb", "line": 1 }, - "id": "V-61771" + "id": "V-61453" }, { - "title": "The DBMS must notify appropriate individuals when account disabling\n actions are taken.", - "desc": "When application accounts are disabled, user accessibility is\n affected. Accounts are utilized for identifying individual application users or\n for identifying the application processes themselves.\n\n In order to detect and respond to events that affect user accessibility and\n application processing, applications must audit account disabling actions and,\n as required, notify the appropriate individuals so they can investigate the\n event. Such a capability greatly reduces the risk that application\n accessibility will be negatively affected for extended periods of time and also\n provides logging that can be used for forensic purposes.\n\n Note that user authentication and account management must be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP. This requirement applies to cases where accounts are\n directly managed by Oracle.\n\n Notwithstanding how accounts are normally managed, the DBMS must support\n the requirement to notify appropriate individuals upon the disabling of an\n account within Oracle. Indeed, in a configuration where accounts are managed\n externally, the manipulation of an account within Oracle may indicate hostile\n activity.", + "title": "The DBMS must terminate user sessions upon user logoff or any other\n organization or policy-defined session termination events, such as idle time\n limit exceeded.", + "desc": "This requirement focuses on communications protection at the\n application session, versus network packet, level.\n\n Session IDs are tokens generated by web applications to uniquely identify\n an application user's session. Applications will make application decisions\n and execute business logic based on the session ID. Unique session identifiers\n or IDs are the opposite of sequentially generated session IDs, which can be\n easily guessed by an attacker. Unique session IDs help to reduce predictability\n of said identifiers. Unique session IDs address man-in-the-middle attacks,\n including session hijacking or insertion of false information into a session.\n If the attackers are unable to identify or guess the session information\n related to pending application traffic, they will have more difficulty in\n hijacking the session or otherwise manipulating valid sessions. When a user\n logs out, or when any other session termination event occurs, the application\n must terminate the user session to minimize the potential for an attacker to\n hijack that particular user session.\n\n Database sessions must be terminated when no longer in use in order to\n prevent session hijacking.", "descriptions": { - "default": "When application accounts are disabled, user accessibility is\n affected. Accounts are utilized for identifying individual application users or\n for identifying the application processes themselves.\n\n In order to detect and respond to events that affect user accessibility and\n application processing, applications must audit account disabling actions and,\n as required, notify the appropriate individuals so they can investigate the\n event. Such a capability greatly reduces the risk that application\n accessibility will be negatively affected for extended periods of time and also\n provides logging that can be used for forensic purposes.\n\n Note that user authentication and account management must be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP. This requirement applies to cases where accounts are\n directly managed by Oracle.\n\n Notwithstanding how accounts are normally managed, the DBMS must support\n the requirement to notify appropriate individuals upon the disabling of an\n account within Oracle. Indeed, in a configuration where accounts are managed\n externally, the manipulation of an account within Oracle may indicate hostile\n activity." + "default": "This requirement focuses on communications protection at the\n application session, versus network packet, level.\n\n Session IDs are tokens generated by web applications to uniquely identify\n an application user's session. Applications will make application decisions\n and execute business logic based on the session ID. Unique session identifiers\n or IDs are the opposite of sequentially generated session IDs, which can be\n easily guessed by an attacker. Unique session IDs help to reduce predictability\n of said identifiers. Unique session IDs address man-in-the-middle attacks,\n including session hijacking or insertion of false information into a session.\n If the attackers are unable to identify or guess the session information\n related to pending application traffic, they will have more difficulty in\n hijacking the session or otherwise manipulating valid sessions. When a user\n logs out, or when any other session termination event occurs, the application\n must terminate the user session to minimize the potential for an attacker to\n hijack that particular user session.\n\n Database sessions must be terminated when no longer in use in order to\n prevent session hijacking." }, "impact": 0.5, "refs": [], "tags": { - "gtitle": "SRG-APP-000293-DB-000130", - "gid": "V-61801", - "rid": "SV-76291r2_rule", - "stig_id": "O121-C2-020600", - "fix_id": "F-67717r1_fix", + "gtitle": "SRG-APP-000220-DB-000149", + "gid": "V-61765", + "rid": "SV-76255r2_rule", + "stig_id": "O121-C2-017600", + "fix_id": "F-67681r4_fix", "cci": [ - "CCI-001685" + "CCI-001185" ], "nist": [ - "AC-2 (4)", + "SC-23 (1)", "Rev_4" ], "false_negatives": null, @@ -4969,35 +5069,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Check DBMS settings to determine whether it will notify\n appropriate individuals when account disabling actions are taken.\n\n If the DBMS does not notify appropriate individuals when account disabling\n actions are taken, this is a finding.", - "fix": "Working with the DBA and site management, determine the\n appropriate individuals (by job role) to be notified.\n\n If Oracle Audit Vault is available, configure it to notify the appropriate\n individuals when accounts are disabled.\n\n If Oracle Audit Vault is not available, configure the Oracle DBMS's auditing\n feature to record disabling of accounts.\n\n If Standard Auditing is used:\n Create and deploy a mechanism, such as a frequently-run job, to monitor the\n SYS.AUD$ table for these records and notify the appropriate individuals.\n\n If unified Auditing is used:\n Create and deploy a mechanism, such as a frequently-run job, to monitor the\n SYS.UNIFIED_AUDIT_TRAIL view for these records and notify the appropriate\n individuals." + "check": "Review DBMS settings and vendor documentation to verify user\n sessions are terminated upon user logout. If they are not, this is a finding.\n\n Review system documentation and organization policy to identify other events\n that should result in session terminations. If other session termination events\n are defined, review DBMS settings to verify occurrences of these events would\n cause session termination.\n\n If occurrences of defined session-terminating events do not cause session\n terminations, this is a finding.\n\n When a user logs off of an Oracle session gracefully or has the session\n terminated for an idle timeout or any other reason, the session is terminated,\n and the resources are returned to the system. Check with the DBA to see what\n mechanism is used to disconnect the session and what events the site uses to\n determine if a connection needs to be terminated.\n\n To test for timeout, open a connection and leave it idle for a period greater\n than the defined idle timeout setting enforced by the system. Then try to use\n the connection. If the connection is no longer active, then the mechanism\n deployed to terminate the connection is active and working.", + "fix": "Configure DBMS settings to terminate sessions upon user logoff.\n Configure DBMS settings to terminate sessions upon the occurrence of any\n organization or policy-defined session termination event.\n\n - - - - -\n\n To configure specific session termination processes, we need to define the\n organization or policy-defined session termination event. Below are some\n examples.\n\n Oracle has several ways to disconnect idle sessions, both from within SQL*Plus\n via resources profiles (connect_time, idle_time) and with the SQL*net expire\n time parameter.\n\n Can use profiles to set the connect time and idle time with \"alter profile\"\n statements:\n\n alter profile senior_claim_analyst limit\n connect_time 15\n sessions_per_user 2\n ldle_time 10;\n\n Profiles comprise a named set of resource limits. By default, when users are\n created, they are given the default profile, which provides unlimited use of\n all resources.\n\n The syntax to create a profile follows:\n\n CREATE PROFILE LIMIT resource_parameters|password_parameters;\n Resource_parameters:\n [SESSIONS_PER_USER n|UNLIMITED|DEFAULT]\n [CPU_PER_SESSION n|UNLIMITED|DEFAULT]\n [CPU_PER_CALL n|UNLIMITED|DEFAULT]\n [CONNECT_TIME n|UNLIMITED|DEFAULT]\n [IDLE_TIME n|UNLIMITED|DEFAULT]\n\n By setting resource limits, can prevent users from performing operations that\n will tie up the system and prevent other users from performing operations. Can\n use resource limits for security, to ensure that users log off the system, so\n as not to leave the session connected for long periods of time.\n\n The system resource limits can be enforced at the session level, the call\n level, or both. The session level is calculated from the time the user logs on\n to the database until the user exits. The call level applies to each SQL\n command issued. Session-level limits are enforced for each connection. When a\n session-level limit is exceeded, only the last SQL command issued is rolled\n back; no further work can be performed until a commit, rollback, or exit is\n performed.\n\n Using SQLNET.EXPIRE_TIME\n\n The sqlnet.expire_time parameter is used to set a time interval, in minutes, to\n determine how often a probe should be sent verifying that client/server\n connections are active. If there is a need to ensure that connections are not\n left open indefinitely (or up to the time set by operating system-specific\n parameters), set a value that is greater than 0. This protects the system from\n connections left open due to an abnormal client termination.\n\n When the probe detects a terminated connection or a connection no longer in\n use, it signals an error, causing the server process to exit. This setting is\n intended for use on the database server side of the connection, which usually\n handles multiple connections at any one time. Limitations on using this\n terminated (dead) connection detection feature are:\n\n sqlnet.expire_time cannot be used on bequeathed connections.\n\n The SQL*Net expire_time probe packet will generate additional network traffic\n that may downgrade the network's performance, depending on the number of\n connections.\n\n Depending on the operating system that is in use, additional server processing\n may need to be performed to distinguish the connection probe from other events\n that occur. This overhead for detection of probe events can result in\n downgraded network performance.\n\n Turning-on expire_time\n\n To set up these advanced features, simply edit the sqlnet.ora file. If a\n beginner, follow this procedure:\n\n Start the Oracle Network Manager GUI.\n\n In the GUI navigator pane, expand the icons Local >> Profile.\n\n From the list on the right-hand pane, select General.\n\n Click on the Advanced tab.\n\n Next, enter the values for the fields or options to set.\n\n When finished, choose File >> Save Network Configuration to write the changes\n to the sqlnet.ora file. (Note: This assumes that a single sqlnet.ora file, in\n the default location, is in use. Please see the supplemental file \"Non-default\n sqlnet.ora configurations.pdf\" for how to find multiple and/or differently\n located sqlnet.ora files.)\n\n The sqlnet.ora inbound_connect_timeout parameter\n\n The sqlnet.ora inbound_connect_timeout parameter is used to limit the time, set\n in seconds, for a client to connect with the database server and provide the\n required authentication information.\n\n Also see sqlnet.inbound_connect_timeout tips.\n\n To limit consumption of Oracle resources by unauthorized users and enable an\n audit trail, should set time-limit values for the\n sqlnet.inbound_connect_timeout parameter in wall-clock seconds. (This parameter\n does not have default values.) Failure resulting from\n sqlnet.inbound_connect_timeout will throw an ORA-03136 inbound connection timed\n out error. " }, - "code": "control 'V-61801' do\n title \"The DBMS must notify appropriate individuals when account disabling\n actions are taken.\"\n desc \"When application accounts are disabled, user accessibility is\n affected. Accounts are utilized for identifying individual application users or\n for identifying the application processes themselves.\n\n In order to detect and respond to events that affect user accessibility and\n application processing, applications must audit account disabling actions and,\n as required, notify the appropriate individuals so they can investigate the\n event. Such a capability greatly reduces the risk that application\n accessibility will be negatively affected for extended periods of time and also\n provides logging that can be used for forensic purposes.\n\n Note that user authentication and account management must be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP. This requirement applies to cases where accounts are\n directly managed by Oracle.\n\n Notwithstanding how accounts are normally managed, the DBMS must support\n the requirement to notify appropriate individuals upon the disabling of an\n account within Oracle. Indeed, in a configuration where accounts are managed\n externally, the manipulation of an account within Oracle may indicate hostile\n activity.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000293-DB-000130'\n tag \"gid\": 'V-61801'\n tag \"rid\": 'SV-76291r2_rule'\n tag \"stig_id\": 'O121-C2-020600'\n tag \"fix_id\": 'F-67717r1_fix'\n tag \"cci\": ['CCI-001685']\n tag \"nist\": ['AC-2 (4)', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Check DBMS settings to determine whether it will notify\n appropriate individuals when account disabling actions are taken.\n\n If the DBMS does not notify appropriate individuals when account disabling\n actions are taken, this is a finding.\"\n tag \"fix\": \"Working with the DBA and site management, determine the\n appropriate individuals (by job role) to be notified.\n\n If Oracle Audit Vault is available, configure it to notify the appropriate\n individuals when accounts are disabled.\n\n If Oracle Audit Vault is not available, configure the Oracle DBMS's auditing\n feature to record disabling of accounts.\n\n If Standard Auditing is used:\n Create and deploy a mechanism, such as a frequently-run job, to monitor the\n SYS.AUD$ table for these records and notify the appropriate individuals.\n\n If unified Auditing is used:\n Create and deploy a mechanism, such as a frequently-run job, to monitor the\n SYS.UNIFIED_AUDIT_TRAIL view for these records and notify the appropriate\n individuals.\"\n describe 'A manual review is required to ensure the DBMS notifies the appropriate individuals when account disabling\n actions are taken' do\n skip 'A manual review is required to ensure the DBMS notifies the appropriate individuals when account disabling\n actions are taken'\n end\nend\n", + "code": "control 'V-61765' do\n title \"The DBMS must terminate user sessions upon user logoff or any other\n organization or policy-defined session termination events, such as idle time\n limit exceeded.\"\n desc \"This requirement focuses on communications protection at the\n application session, versus network packet, level.\n\n Session IDs are tokens generated by web applications to uniquely identify\n an application user's session. Applications will make application decisions\n and execute business logic based on the session ID. Unique session identifiers\n or IDs are the opposite of sequentially generated session IDs, which can be\n easily guessed by an attacker. Unique session IDs help to reduce predictability\n of said identifiers. Unique session IDs address man-in-the-middle attacks,\n including session hijacking or insertion of false information into a session.\n If the attackers are unable to identify or guess the session information\n related to pending application traffic, they will have more difficulty in\n hijacking the session or otherwise manipulating valid sessions. When a user\n logs out, or when any other session termination event occurs, the application\n must terminate the user session to minimize the potential for an attacker to\n hijack that particular user session.\n\n Database sessions must be terminated when no longer in use in order to\n prevent session hijacking.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000220-DB-000149'\n tag \"gid\": 'V-61765'\n tag \"rid\": 'SV-76255r2_rule'\n tag \"stig_id\": 'O121-C2-017600'\n tag \"fix_id\": 'F-67681r4_fix'\n tag \"cci\": ['CCI-001185']\n tag \"nist\": ['SC-23 (1)', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Review DBMS settings and vendor documentation to verify user\n sessions are terminated upon user logout. If they are not, this is a finding.\n\n Review system documentation and organization policy to identify other events\n that should result in session terminations. If other session termination events\n are defined, review DBMS settings to verify occurrences of these events would\n cause session termination.\n\n If occurrences of defined session-terminating events do not cause session\n terminations, this is a finding.\n\n When a user logs off of an Oracle session gracefully or has the session\n terminated for an idle timeout or any other reason, the session is terminated,\n and the resources are returned to the system. Check with the DBA to see what\n mechanism is used to disconnect the session and what events the site uses to\n determine if a connection needs to be terminated.\n\n To test for timeout, open a connection and leave it idle for a period greater\n than the defined idle timeout setting enforced by the system. Then try to use\n the connection. If the connection is no longer active, then the mechanism\n deployed to terminate the connection is active and working.\"\n tag \"fix\": \"Configure DBMS settings to terminate sessions upon user logoff.\n Configure DBMS settings to terminate sessions upon the occurrence of any\n organization or policy-defined session termination event.\n\n - - - - -\n\n To configure specific session termination processes, we need to define the\n organization or policy-defined session termination event. Below are some\n examples.\n\n Oracle has several ways to disconnect idle sessions, both from within SQL*Plus\n via resources profiles (connect_time, idle_time) and with the SQL*net expire\n time parameter.\n\n Can use profiles to set the connect time and idle time with \\\"alter profile\\\"\n statements:\n\n alter profile senior_claim_analyst limit\n connect_time 15\n sessions_per_user 2\n ldle_time 10;\n\n Profiles comprise a named set of resource limits. By default, when users are\n created, they are given the default profile, which provides unlimited use of\n all resources.\n\n The syntax to create a profile follows:\n\n CREATE PROFILE LIMIT resource_parameters|password_parameters;\n Resource_parameters:\n [SESSIONS_PER_USER n|UNLIMITED|DEFAULT]\n [CPU_PER_SESSION n|UNLIMITED|DEFAULT]\n [CPU_PER_CALL n|UNLIMITED|DEFAULT]\n [CONNECT_TIME n|UNLIMITED|DEFAULT]\n [IDLE_TIME n|UNLIMITED|DEFAULT]\n\n By setting resource limits, can prevent users from performing operations that\n will tie up the system and prevent other users from performing operations. Can\n use resource limits for security, to ensure that users log off the system, so\n as not to leave the session connected for long periods of time.\n\n The system resource limits can be enforced at the session level, the call\n level, or both. The session level is calculated from the time the user logs on\n to the database until the user exits. The call level applies to each SQL\n command issued. Session-level limits are enforced for each connection. When a\n session-level limit is exceeded, only the last SQL command issued is rolled\n back; no further work can be performed until a commit, rollback, or exit is\n performed.\n\n Using SQLNET.EXPIRE_TIME\n\n The sqlnet.expire_time parameter is used to set a time interval, in minutes, to\n determine how often a probe should be sent verifying that client/server\n connections are active. If there is a need to ensure that connections are not\n left open indefinitely (or up to the time set by operating system-specific\n parameters), set a value that is greater than 0. This protects the system from\n connections left open due to an abnormal client termination.\n\n When the probe detects a terminated connection or a connection no longer in\n use, it signals an error, causing the server process to exit. This setting is\n intended for use on the database server side of the connection, which usually\n handles multiple connections at any one time. Limitations on using this\n terminated (dead) connection detection feature are:\n\n sqlnet.expire_time cannot be used on bequeathed connections.\n\n The SQL*Net expire_time probe packet will generate additional network traffic\n that may downgrade the network's performance, depending on the number of\n connections.\n\n Depending on the operating system that is in use, additional server processing\n may need to be performed to distinguish the connection probe from other events\n that occur. This overhead for detection of probe events can result in\n downgraded network performance.\n\n Turning-on expire_time\n\n To set up these advanced features, simply edit the sqlnet.ora file. If a\n beginner, follow this procedure:\n\n Start the Oracle Network Manager GUI.\n\n In the GUI navigator pane, expand the icons Local >> Profile.\n\n From the list on the right-hand pane, select General.\n\n Click on the Advanced tab.\n\n Next, enter the values for the fields or options to set.\n\n When finished, choose File >> Save Network Configuration to write the changes\n to the sqlnet.ora file. (Note: This assumes that a single sqlnet.ora file, in\n the default location, is in use. Please see the supplemental file \\\"Non-default\n sqlnet.ora configurations.pdf\\\" for how to find multiple and/or differently\n located sqlnet.ora files.)\n\n The sqlnet.ora inbound_connect_timeout parameter\n\n The sqlnet.ora inbound_connect_timeout parameter is used to limit the time, set\n in seconds, for a client to connect with the database server and provide the\n required authentication information.\n\n Also see sqlnet.inbound_connect_timeout tips.\n\n To limit consumption of Oracle resources by unauthorized users and enable an\n audit trail, should set time-limit values for the\n sqlnet.inbound_connect_timeout parameter in wall-clock seconds. (This parameter\n does not have default values.) Failure resulting from\n sqlnet.inbound_connect_timeout will throw an ORA-03136 inbound connection timed\n out error. \"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n query_idle_time = %{\n SELECT PROFILE, RESOURCE_NAME, LIMIT FROM DBA_PROFILES WHERE PROFILE =\n '%s' AND RESOURCE_NAME = 'IDLE_TIME'\n }\n\n query_sessions_per_user = %{\n SELECT PROFILE, RESOURCE_NAME, LIMIT FROM DBA_PROFILES WHERE PROFILE =\n '%s' AND RESOURCE_NAME = 'SESSIONS_PER_USER'\n }\n\n query_connect_time = %{\n SELECT PROFILE, RESOURCE_NAME, LIMIT FROM DBA_PROFILES WHERE PROFILE =\n '%s' AND RESOURCE_NAME = 'CONNECT_TIME'\n }\n\n user_profiles = sql.query('SELECT profile FROM dba_users;').column('profile').uniq\n\n user_profiles.each do |profile|\n idle_time = sql.query(format(query_idle_time, profile: profile)).column('limit')\n sessions_per_user = sql.query(format(query_sessions_per_user, profile: profile)).column('limit')\n connect_time = sql.query(format(query_connect_time, profile: profile)).column('limit')\n\n describe \"The oracle database idle time for profile: #{profile}\" do\n subject { idle_time }\n it { should cmp <= 15 }\n end\n\n describe \"The oracle database number of sessions per user for profile: #{profile}\" do\n subject { sessions_per_user }\n it { should cmp <= 3 }\n end\n\n describe \"The oracle database connect time for profile: #{profile}\" do\n subject { connect_time }\n it { should cmp <= 15 }\n end\n end\n if user_profiles.empty?\n describe 'There are no user profiles, therefore this control is NA' do\n skip 'There are no user profiles, therefore this control is NA'\n end\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61801.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61765.rb", "line": 1 }, - "id": "V-61801" + "id": "V-61765" }, { - "title": "The system must protect audit tools from unauthorized modification.", - "desc": "Protecting audit data also includes identifying and protecting the\n tools used to view and manipulate log data.\n\n Depending upon the log format and application, system and application log\n tools may provide the only means to manipulate and manage application and\n system log data.\n\n If the tools are compromised it could provide attackers with the capability\n to manipulate log data. It is, therefore, imperative that audit tools be\n controlled and protected from unauthorized modification.\n\n Audit tools include, but are not limited to, OS provided audit tools,\n vendor provided audit tools, and open source audit tools needed to successfully\n view and manipulate audit information system activity and records.\n\n If an attacker were to gain access to audit tools he could analyze audit\n logs for system weaknesses or weaknesses in the auditing itself. An attacker\n could also manipulate logs to hide evidence of malicious activity.", + "title": "The DBMS must provide audit record generation capability for\n organization-defined auditable events within the database.", + "desc": "Audit records can be generated from various components within the\n information system. (e.g., network interface, hard disk, modem, etc.). From an\n application perspective, certain specific application functionalities may be\n audited as well.\n\n The list of audited events is the set of events for which audits are to be\n generated. This set of events is typically a subset of the list of all events\n for which the system is capable of generating audit records (i.e., auditable\n events, timestamps, source and destination addresses, user/process identifiers,\n event descriptions, success/fail indications, file names involved, and access\n control or flow control rules invoked).\n\n Organizations define which application components shall provide auditable\n events.\n\n The DBMS must provide auditing for the list of events defined by the\n organization or risk negatively impacting forensic investigations into\n malicious behavior in the information system. Audit records can be generated\n from various components within the information system, such as network\n interfaces, hard disks, modems, etc. From an application perspective, certain\n specific application functionalities may be audited, as well.\n\n The list of audited events is the set of events for which audits are to be\n generated. This set of events is typically a subset of the list of all events\n for which the system is capable of generating audit records (i.e., auditable\n events, timestamps, source and destination addresses, user/process identifiers,\n event descriptions, success/fail indications, file names involved, and access\n control or flow control rules invoked).\n\n Organizations may define the organizational personnel accountable for\n determining which application components shall provide auditable events.\n\n Auditing provides accountability for changes made to the DBMS configuration\n or its objects and data. It provides a means to discover suspicious activity\n and unauthorized changes. Without auditing, a compromise may go undetected and\n without a means to determine accountability.\n\n The Department of Defense has established the following as the minimum set\n of auditable events. Most can be audited via Oracle settings; some - marked\n here with an asterisk - cannot, and may require OS settings.\n - Successful and unsuccessful attempts to access, modify, or delete\n privileges, security objects, security levels, or categories of information\n (e.g. classification levels).\n - Successful and unsuccessful logon attempts, privileged activities or\n other system level access\n - Starting and ending time for user access to the system, concurrent logons\n from different workstations.\n - Successful and unsuccessful accesses to objects.\n - All program initiations.\n - *All direct access to the information system.\n - All account creations, modifications, disabling, and terminations.\n - *All kernel module loads, unloads, and restarts.", "descriptions": { - "default": "Protecting audit data also includes identifying and protecting the\n tools used to view and manipulate log data.\n\n Depending upon the log format and application, system and application log\n tools may provide the only means to manipulate and manage application and\n system log data.\n\n If the tools are compromised it could provide attackers with the capability\n to manipulate log data. It is, therefore, imperative that audit tools be\n controlled and protected from unauthorized modification.\n\n Audit tools include, but are not limited to, OS provided audit tools,\n vendor provided audit tools, and open source audit tools needed to successfully\n view and manipulate audit information system activity and records.\n\n If an attacker were to gain access to audit tools he could analyze audit\n logs for system weaknesses or weaknesses in the auditing itself. An attacker\n could also manipulate logs to hide evidence of malicious activity." + "default": "Audit records can be generated from various components within the\n information system. (e.g., network interface, hard disk, modem, etc.). From an\n application perspective, certain specific application functionalities may be\n audited as well.\n\n The list of audited events is the set of events for which audits are to be\n generated. This set of events is typically a subset of the list of all events\n for which the system is capable of generating audit records (i.e., auditable\n events, timestamps, source and destination addresses, user/process identifiers,\n event descriptions, success/fail indications, file names involved, and access\n control or flow control rules invoked).\n\n Organizations define which application components shall provide auditable\n events.\n\n The DBMS must provide auditing for the list of events defined by the\n organization or risk negatively impacting forensic investigations into\n malicious behavior in the information system. Audit records can be generated\n from various components within the information system, such as network\n interfaces, hard disks, modems, etc. From an application perspective, certain\n specific application functionalities may be audited, as well.\n\n The list of audited events is the set of events for which audits are to be\n generated. This set of events is typically a subset of the list of all events\n for which the system is capable of generating audit records (i.e., auditable\n events, timestamps, source and destination addresses, user/process identifiers,\n event descriptions, success/fail indications, file names involved, and access\n control or flow control rules invoked).\n\n Organizations may define the organizational personnel accountable for\n determining which application components shall provide auditable events.\n\n Auditing provides accountability for changes made to the DBMS configuration\n or its objects and data. It provides a means to discover suspicious activity\n and unauthorized changes. Without auditing, a compromise may go undetected and\n without a means to determine accountability.\n\n The Department of Defense has established the following as the minimum set\n of auditable events. Most can be audited via Oracle settings; some - marked\n here with an asterisk - cannot, and may require OS settings.\n - Successful and unsuccessful attempts to access, modify, or delete\n privileges, security objects, security levels, or categories of information\n (e.g. classification levels).\n - Successful and unsuccessful logon attempts, privileged activities or\n other system level access\n - Starting and ending time for user access to the system, concurrent logons\n from different workstations.\n - Successful and unsuccessful accesses to objects.\n - All program initiations.\n - *All direct access to the information system.\n - All account creations, modifications, disabling, and terminations.\n - *All kernel module loads, unloads, and restarts." }, - "impact": 0, + "impact": 0.5, "refs": [], "tags": { - "gtitle": "SRG-APP-000122-DB-000203", - "gid": "V-61661", - "rid": "SV-76151r1_rule", - "stig_id": "O121-C2-009700", - "fix_id": "F-67575r1_fix", + "gtitle": "SRG-APP-000089-DB-000064", + "gid": "V-61621", + "rid": "SV-76111r1_rule", + "stig_id": "O121-C2-006800", + "fix_id": "F-67537r1_fix", "cci": [ - "CCI-001494" + "CCI-000169" ], "nist": [ - "AU-9", + "AU-12 a", "Rev_4" ], "false_negatives": null, @@ -5010,30 +5110,30 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Review access permissions to tools used to view or modify audit\n log data. These tools may include the DBMS itself or tools external to the\n database.\n\n If appropriate permissions and access controls are not applied to prevent\n unauthorized modification of these tools, this is a finding.", - "fix": "Add or modify access controls and permissions to tools used to\n view or modify audit log data. Tools must be modifiable by authorized personnel\n only." + "check": "Verify, using vendor and system documentation if necessary,\n that the DBMS is configured to use Oracle's auditing features, or that a\n third-party product or custom code is deployed and configured to satisfy this\n requirement.\n\n If a third-party product or custom code is used, compare its current\n configuration with the audit requirements. If any of the requirements is not\n covered by the configuration, this is a finding.\n\n The remainder of this Check is applicable specifically where Oracle auditing is\n in use.\n\n If Standard Auditing is used:\n To see if Oracle is configured to capture audit data, enter the following\n SQL*Plus command:\n SHOW PARAMETER AUDIT_TRAIL\n or the following SQL query:\n SELECT * FROM SYS.V$PARAMETER WHERE NAME = 'audit_trail';\n If Oracle returns the value 'NONE', this is a finding.\n\n To confirm that Oracle audit is capturing information on the required events,\n review the contents of the SYS.AUD$ table or the audit file, whichever is in\n use. If auditable events are not listed, this is a finding.\n\n If Unified Auditing is used:\n To see if Oracle is configured to capture audit data, enter the following\n SQL*Plus command:\n SELECT * FROM V$OPTION WHERE PARAMETER = 'Unified Auditing';\n If Oracle returns the value 'TRUE', this is not a finding.\n\n To confirm that Oracle audit is capturing information on the required events,\n review the contents of the SYS.UNIFIED_AUDIT_TRAIL view. If auditable events\n are not listed, this is a finding.", + "fix": "Configure the DBMS's auditing to audit organization-defined\n auditable events. If preferred, use a third-party tool. The tool must provide\n the minimum capability to audit the required events.\n\n If using a third-party product, proceed in accordance with the product\n documentation. If using Oracle's capabilities, proceed as follows.\n\n If Standard Auditing is used:\n Use this process to ensure auditable events are captured:\n ALTER SYSTEM SET AUDIT_TRAIL= SCOPE=SPFILE;\n Audit trail type can be 'OS', 'DB', 'DB,EXTENDED', 'XML' or 'XML,EXTENDED'.\n After executing this statement, it may be necessary to shut down and restart\n the Oracle database.\n\n If the site-specific audit requirements are not covered by the default audit\n options, deploy and configure Fine-Grained Auditing. For details, refer to\n Oracle documentation at the locations below.\n\n If Unified Auditing is used:\n Use this process to ensure auditable events are captured:\n Link the oracle binary with uniaud_on, and then restart the database. Oracle\n Database Upgrade Guide describes how to enable unified auditing.\n\n For more information on the configuration of auditing, refer to the following\n documents:\n \"Auditing Database Activity\" in the Oracle Database 2 Day + Security Guide:\n http://docs.oracle.com/database/121/TDPSG/tdpsg_auditing.htm#TDPSG50000\n \"Monitoring Database Activity with Auditing\" in the Oracle Database Security\n Guide:\n http://docs.oracle.com/database/121/DBSEG/part_6.htm#CCHEHCGI\n \"DBMS_AUDIT_MGMT\" in the Oracle Database PL/SQL Packages and Types Reference:\n http://docs.oracle.com/database/121/ARPLS/d_audit_mgmt.htm#ARPLS241\n Oracle Database Upgrade Guide:\n http://docs.oracle.com/database/121/UPGRD/afterup.htm#UPGRD52810\n\n If the site-specific audit requirements are not covered by the default audit\n options, deploy and configure Fine-Grained Auditing. For details, refer to\n Oracle documentation at the locations above." }, - "code": "control 'V-61661' do\n title 'The system must protect audit tools from unauthorized modification.'\n desc \"Protecting audit data also includes identifying and protecting the\n tools used to view and manipulate log data.\n\n Depending upon the log format and application, system and application log\n tools may provide the only means to manipulate and manage application and\n system log data.\n\n If the tools are compromised it could provide attackers with the capability\n to manipulate log data. It is, therefore, imperative that audit tools be\n controlled and protected from unauthorized modification.\n\n Audit tools include, but are not limited to, OS provided audit tools,\n vendor provided audit tools, and open source audit tools needed to successfully\n view and manipulate audit information system activity and records.\n\n If an attacker were to gain access to audit tools he could analyze audit\n logs for system weaknesses or weaknesses in the auditing itself. An attacker\n could also manipulate logs to hide evidence of malicious activity.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000122-DB-000203'\n tag \"gid\": 'V-61661'\n tag \"rid\": 'SV-76151r1_rule'\n tag \"stig_id\": 'O121-C2-009700'\n tag \"fix_id\": 'F-67575r1_fix'\n tag \"cci\": ['CCI-001494']\n tag \"nist\": ['AU-9', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Review access permissions to tools used to view or modify audit\n log data. These tools may include the DBMS itself or tools external to the\n database.\n\n If appropriate permissions and access controls are not applied to prevent\n unauthorized modification of these tools, this is a finding.\"\n tag \"fix\": \"Add or modify access controls and permissions to tools used to\n view or modify audit log data. Tools must be modifiable by authorized personnel\n only.\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n users_allowed_access_to_audit_info = sql.query(\"SELECT GRANTEE, TABLE_NAME, PRIVILEGE\n FROM DBA_TAB_PRIVS where owner='AUDSYS';\").column('grantee').uniq\n if users_allowed_access_to_audit_info.empty?\n impact 0.0\n describe 'There are no oracle users allowed access to audit information, control N/A' do\n skip 'There are no oracle users allowed access to audit information'\n end\n else\n users_allowed_access_to_audit_info.each do |user|\n describe \"oracle users: #{user} allowed access to audit information\" do\n subject { user }\n it { should be_in input('allowed_audit_users') }\n end\n end\n end\nend\n", + "code": "control 'V-61621' do\n title \"The DBMS must provide audit record generation capability for\n organization-defined auditable events within the database.\"\n desc \"Audit records can be generated from various components within the\n information system. (e.g., network interface, hard disk, modem, etc.). From an\n application perspective, certain specific application functionalities may be\n audited as well.\n\n The list of audited events is the set of events for which audits are to be\n generated. This set of events is typically a subset of the list of all events\n for which the system is capable of generating audit records (i.e., auditable\n events, timestamps, source and destination addresses, user/process identifiers,\n event descriptions, success/fail indications, file names involved, and access\n control or flow control rules invoked).\n\n Organizations define which application components shall provide auditable\n events.\n\n The DBMS must provide auditing for the list of events defined by the\n organization or risk negatively impacting forensic investigations into\n malicious behavior in the information system. Audit records can be generated\n from various components within the information system, such as network\n interfaces, hard disks, modems, etc. From an application perspective, certain\n specific application functionalities may be audited, as well.\n\n The list of audited events is the set of events for which audits are to be\n generated. This set of events is typically a subset of the list of all events\n for which the system is capable of generating audit records (i.e., auditable\n events, timestamps, source and destination addresses, user/process identifiers,\n event descriptions, success/fail indications, file names involved, and access\n control or flow control rules invoked).\n\n Organizations may define the organizational personnel accountable for\n determining which application components shall provide auditable events.\n\n Auditing provides accountability for changes made to the DBMS configuration\n or its objects and data. It provides a means to discover suspicious activity\n and unauthorized changes. Without auditing, a compromise may go undetected and\n without a means to determine accountability.\n\n The Department of Defense has established the following as the minimum set\n of auditable events. Most can be audited via Oracle settings; some - marked\n here with an asterisk - cannot, and may require OS settings.\n - Successful and unsuccessful attempts to access, modify, or delete\n privileges, security objects, security levels, or categories of information\n (e.g. classification levels).\n - Successful and unsuccessful logon attempts, privileged activities or\n other system level access\n - Starting and ending time for user access to the system, concurrent logons\n from different workstations.\n - Successful and unsuccessful accesses to objects.\n - All program initiations.\n - *All direct access to the information system.\n - All account creations, modifications, disabling, and terminations.\n - *All kernel module loads, unloads, and restarts.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000089-DB-000064'\n tag \"gid\": 'V-61621'\n tag \"rid\": 'SV-76111r1_rule'\n tag \"stig_id\": 'O121-C2-006800'\n tag \"fix_id\": 'F-67537r1_fix'\n tag \"cci\": ['CCI-000169']\n tag \"nist\": ['AU-12 a', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Verify, using vendor and system documentation if necessary,\n that the DBMS is configured to use Oracle's auditing features, or that a\n third-party product or custom code is deployed and configured to satisfy this\n requirement.\n\n If a third-party product or custom code is used, compare its current\n configuration with the audit requirements. If any of the requirements is not\n covered by the configuration, this is a finding.\n\n The remainder of this Check is applicable specifically where Oracle auditing is\n in use.\n\n If Standard Auditing is used:\n To see if Oracle is configured to capture audit data, enter the following\n SQL*Plus command:\n SHOW PARAMETER AUDIT_TRAIL\n or the following SQL query:\n SELECT * FROM SYS.V$PARAMETER WHERE NAME = 'audit_trail';\n If Oracle returns the value 'NONE', this is a finding.\n\n To confirm that Oracle audit is capturing information on the required events,\n review the contents of the SYS.AUD$ table or the audit file, whichever is in\n use. If auditable events are not listed, this is a finding.\n\n If Unified Auditing is used:\n To see if Oracle is configured to capture audit data, enter the following\n SQL*Plus command:\n SELECT * FROM V$OPTION WHERE PARAMETER = 'Unified Auditing';\n If Oracle returns the value 'TRUE', this is not a finding.\n\n To confirm that Oracle audit is capturing information on the required events,\n review the contents of the SYS.UNIFIED_AUDIT_TRAIL view. If auditable events\n are not listed, this is a finding.\"\n tag \"fix\": \"Configure the DBMS's auditing to audit organization-defined\n auditable events. If preferred, use a third-party tool. The tool must provide\n the minimum capability to audit the required events.\n\n If using a third-party product, proceed in accordance with the product\n documentation. If using Oracle's capabilities, proceed as follows.\n\n If Standard Auditing is used:\n Use this process to ensure auditable events are captured:\n ALTER SYSTEM SET AUDIT_TRAIL= SCOPE=SPFILE;\n Audit trail type can be 'OS', 'DB', 'DB,EXTENDED', 'XML' or 'XML,EXTENDED'.\n After executing this statement, it may be necessary to shut down and restart\n the Oracle database.\n\n If the site-specific audit requirements are not covered by the default audit\n options, deploy and configure Fine-Grained Auditing. For details, refer to\n Oracle documentation at the locations below.\n\n If Unified Auditing is used:\n Use this process to ensure auditable events are captured:\n Link the oracle binary with uniaud_on, and then restart the database. Oracle\n Database Upgrade Guide describes how to enable unified auditing.\n\n For more information on the configuration of auditing, refer to the following\n documents:\n \\\"Auditing Database Activity\\\" in the Oracle Database 2 Day + Security Guide:\n http://docs.oracle.com/database/121/TDPSG/tdpsg_auditing.htm#TDPSG50000\n \\\"Monitoring Database Activity with Auditing\\\" in the Oracle Database Security\n Guide:\n http://docs.oracle.com/database/121/DBSEG/part_6.htm#CCHEHCGI\n \\\"DBMS_AUDIT_MGMT\\\" in the Oracle Database PL/SQL Packages and Types Reference:\n http://docs.oracle.com/database/121/ARPLS/d_audit_mgmt.htm#ARPLS241\n Oracle Database Upgrade Guide:\n http://docs.oracle.com/database/121/UPGRD/afterup.htm#UPGRD52810\n\n If the site-specific audit requirements are not covered by the default audit\n options, deploy and configure Fine-Grained Auditing. For details, refer to\n Oracle documentation at the locations above.\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n standard_auditing_used = input('standard_auditing_used')\n unified_auditing_used = input('unified_auditing_used')\n\n describe.one do\n describe 'Standard auditing is in use for audit purposes' do\n subject { standard_auditing_used }\n it { should be true }\n end\n\n describe 'Unified auditing is in use for audit purposes' do\n subject { unified_auditing_used }\n it { should be true }\n end\n end\n\n audit_trail = sql.query(\"select value from v$parameter where name = 'audit_trail';\").column('value')\n audit_info_captured = sql.query('SELECT EVENT_TIMESTAMP FROM UNIFIED_AUDIT_TRAIL ORDER BY EVENT_TIMESTAMP DESC FETCH FIRST 10 ROWS ONLY;').column('event_timestamp')\n\n if standard_auditing_used\n describe 'The oracle database audit_trail parameter' do\n subject { audit_trail }\n it { should_not cmp 'NONE' }\n end\n end\n\n unified_auditing = sql.query(\"SELECT value FROM V$OPTION WHERE PARAMETER = 'Unified Auditing';\").column('value')\n\n if unified_auditing_used\n describe 'The oracle database unified auditing parameter' do\n subject { unified_auditing }\n it { should_not cmp 'FALSE' }\n end\n\n describe 'The oracle database unified auditing events captured' do\n subject { audit_info_captured }\n it { should_not be_empty }\n end\n\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61661.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61621.rb", "line": 1 }, - "id": "V-61661" + "id": "V-61621" }, { - "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": "Database job/batch queues must be reviewed regularly to detect\n unauthorized database job submissions.", + "desc": "Unauthorized users may bypass security mechanisms by submitting jobs\n to job queues managed by the database to be run under a more privileged\n security context of the database or host system. These queues must be monitored\n regularly to detect any such unauthorized job submissions.", "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": "Unauthorized users may bypass security mechanisms by submitting jobs\n to job queues managed by the database to be run under a more privileged\n security context of the database or host system. These queues must be monitored\n regularly to detect any such unauthorized job submissions." }, - "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-000516-DB-999900", + "gid": "V-61449", + "rid": "SV-75939r3_rule", + "stig_id": "O121-BP-023100", + "fix_id": "F-67365r2_fix", "cci": [ "CCI-000366" ], @@ -5051,35 +5151,35 @@ "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": "The DBMS_JOB PL/SQL package has been replaced by DBMS_SCHEDULER\n in Oracle versions 10.1 and higher, though it continues to be supported for\n backward compatibility.\n\n Run this query:\n select value from v$parameter where name = 'job_queue_processes';\n\n Run this query:\n select value from all_scheduler_global_attribute\n where ATTRIBUTE_NAME = 'MAX_JOB_SLAVE_PROCESSES';\n\n To understand the relationship between these settings, review:\n https://docs.oracle.com/database/121/ADMIN/appendix_a.htm#ADMIN11002\n\n Review documented and implemented procedures for monitoring the Oracle DBMS\n job/batch queues for unauthorized submissions. If procedures for job queue\n review are not defined, documented or evidence of implementation does not\n exist, this is a finding.\n\n Job queue information is available from the DBA_JOBS view. The following\n command lists jobs submitted to the queue. DBMS_JOB does not generate a\n 'history' of previous job executions.\n\n Run this query:\n select job, next_date, next_sec, failures, broken from dba_jobs;\n\n Scheduler queue information is available from the DBA_SCHEDULER_JOBS view. The\n following command lists jobs submitted to the queue.\n\n Run this query:\n select owner, job_name, state, job_class, job_type, job_action\n from dba_scheduler_jobs;", + "fix": "Develop, document and implement procedures to monitor the\n database job queues for unauthorized job submissions.\n\n Develop, document and implement a formal migration plan to convert jobs using\n DBMS_JOB to use DBMS_SCHEDULER instead for Oracle versions 10.1 and higher.\n (This does not apply to DBMS_JOB jobs generated by Oracle itself, such as those\n for refreshing materialized views.)\n\n Set the value of the job_queue_processes parameter to a low value to restrict\n concurrent DBMS_JOB executions.\n\n Use auditing to capture use of the DBMS_JOB package in the audit trail. Review\n the audit trail for unauthorized use of the DBMS_JOB package." }, - "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-61449' do\n title \"Database job/batch queues must be reviewed regularly to detect\n unauthorized database job submissions.\"\n desc \"Unauthorized users may bypass security mechanisms by submitting jobs\n to job queues managed by the database to be run under a more privileged\n security context of the database or host system. These queues must be monitored\n regularly to detect any such unauthorized job submissions.\"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000516-DB-999900'\n tag \"gid\": 'V-61449'\n tag \"rid\": 'SV-75939r3_rule'\n tag \"stig_id\": 'O121-BP-023100'\n tag \"fix_id\": 'F-67365r2_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\": \"The DBMS_JOB PL/SQL package has been replaced by DBMS_SCHEDULER\n in Oracle versions 10.1 and higher, though it continues to be supported for\n backward compatibility.\n\n Run this query:\n select value from v$parameter where name = 'job_queue_processes';\n\n Run this query:\n select value from all_scheduler_global_attribute\n where ATTRIBUTE_NAME = 'MAX_JOB_SLAVE_PROCESSES';\n\n To understand the relationship between these settings, review:\n https://docs.oracle.com/database/121/ADMIN/appendix_a.htm#ADMIN11002\n\n Review documented and implemented procedures for monitoring the Oracle DBMS\n job/batch queues for unauthorized submissions. If procedures for job queue\n review are not defined, documented or evidence of implementation does not\n exist, this is a finding.\n\n Job queue information is available from the DBA_JOBS view. The following\n command lists jobs submitted to the queue. DBMS_JOB does not generate a\n 'history' of previous job executions.\n\n Run this query:\n select job, next_date, next_sec, failures, broken from dba_jobs;\n\n Scheduler queue information is available from the DBA_SCHEDULER_JOBS view. The\n following command lists jobs submitted to the queue.\n\n Run this query:\n select owner, job_name, state, job_class, job_type, job_action\n from dba_scheduler_jobs;\"\n tag \"fix\": \"Develop, document and implement procedures to monitor the\n database job queues for unauthorized job submissions.\n\n Develop, document and implement a formal migration plan to convert jobs using\n DBMS_JOB to use DBMS_SCHEDULER instead for Oracle versions 10.1 and higher.\n (This does not apply to DBMS_JOB jobs generated by Oracle itself, such as those\n for refreshing materialized views.)\n\n Set the value of the job_queue_processes parameter to a low value to restrict\n concurrent DBMS_JOB executions.\n\n Use auditing to capture use of the DBMS_JOB package in the audit trail. Review\n the audit trail for unauthorized use of the DBMS_JOB package.\"\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_jobs = sql.query(\"select owner, job_name, state, job_class, job_type, job_action\n from dba_scheduler_jobs;\").column('job_name')\n\n describe \"You must manually review the database jobs to detect unauthorized database job submissions. The jobs to review are: #{database_jobs}\" do\n skip \"You must manually review the database jobs to detect unauthorized database job submissions. The jobs to review are: #{database_jobs}\"\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61843.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61449.rb", "line": 1 }, - "id": "V-61843" + "id": "V-61449" }, { - "title": "The DBMS must allow designated organizational personnel to select\n which auditable events are to be audited by the database.", - "desc": "The list of audited events is the set of events for which audits are\n to be generated. This set of events is typically a subset of the list of all\n events for which the system is capable of generating audit records (i.e.,\n auditable events, timestamps, source and destination addresses, user/process\n identifiers, event descriptions, success/fail indications, file names involved,\n and access control or flow control rules invoked).\n\n If the list of auditable events is not configurable, events that should be\n caught by auditing may be missed. This may allow malicious activity to be\n overlooked.", + "title": "The DBMS must notify appropriate individuals when account disabling\n actions are taken.", + "desc": "When application accounts are disabled, user accessibility is\n affected. Accounts are utilized for identifying individual application users or\n for identifying the application processes themselves.\n\n In order to detect and respond to events that affect user accessibility and\n application processing, applications must audit account disabling actions and,\n as required, notify the appropriate individuals so they can investigate the\n event. Such a capability greatly reduces the risk that application\n accessibility will be negatively affected for extended periods of time and also\n provides logging that can be used for forensic purposes.\n\n Note that user authentication and account management must be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP. This requirement applies to cases where accounts are\n directly managed by Oracle.\n\n Notwithstanding how accounts are normally managed, the DBMS must support\n the requirement to notify appropriate individuals upon the disabling of an\n account within Oracle. Indeed, in a configuration where accounts are managed\n externally, the manipulation of an account within Oracle may indicate hostile\n activity.", "descriptions": { - "default": "The list of audited events is the set of events for which audits are\n to be generated. This set of events is typically a subset of the list of all\n events for which the system is capable of generating audit records (i.e.,\n auditable events, timestamps, source and destination addresses, user/process\n identifiers, event descriptions, success/fail indications, file names involved,\n and access control or flow control rules invoked).\n\n If the list of auditable events is not configurable, events that should be\n caught by auditing may be missed. This may allow malicious activity to be\n overlooked." + "default": "When application accounts are disabled, user accessibility is\n affected. Accounts are utilized for identifying individual application users or\n for identifying the application processes themselves.\n\n In order to detect and respond to events that affect user accessibility and\n application processing, applications must audit account disabling actions and,\n as required, notify the appropriate individuals so they can investigate the\n event. Such a capability greatly reduces the risk that application\n accessibility will be negatively affected for extended periods of time and also\n provides logging that can be used for forensic purposes.\n\n Note that user authentication and account management must be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP. This requirement applies to cases where accounts are\n directly managed by Oracle.\n\n Notwithstanding how accounts are normally managed, the DBMS must support\n the requirement to notify appropriate individuals upon the disabling of an\n account within Oracle. Indeed, in a configuration where accounts are managed\n externally, the manipulation of an account within Oracle may indicate hostile\n activity." }, "impact": 0.5, "refs": [], "tags": { - "gtitle": "SRG-APP-000090-DB-000065", - "gid": "V-61623", - "rid": "SV-76113r1_rule", - "stig_id": "O121-C2-006900", - "fix_id": "F-67539r2_fix", + "gtitle": "SRG-APP-000293-DB-000130", + "gid": "V-61801", + "rid": "SV-76291r2_rule", + "stig_id": "O121-C2-020600", + "fix_id": "F-67717r1_fix", "cci": [ - "CCI-000171" + "CCI-001685" ], "nist": [ - "AU-12 b", + "AC-2 (4)", "Rev_4" ], "false_negatives": null, @@ -5092,35 +5192,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Check DBMS settings and documentation to determine whether\n designated personnel are able to select which auditable events are being\n audited. If designated personnel are not able to configure auditable events,\n this is a finding.", - "fix": "Configure the DBMS's settings to allow designated personnel to\n select which auditable events are audited.\n\n Note the following:\n In Oracle, any user can configure auditing for the objects in his or her own\n schema by using the AUDIT statement. To undo the audit configuration for an\n object, the user can use the NOAUDIT statement. No additional privileges are\n needed to perform this task.\n\n To audit objects in another schema, the user must have the AUDIT ANY system\n privilege.\n To audit system privileges, the user must have the AUDIT SYSTEM privilege.\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" + "check": "Check DBMS settings to determine whether it will notify\n appropriate individuals when account disabling actions are taken.\n\n If the DBMS does not notify appropriate individuals when account disabling\n actions are taken, this is a finding.", + "fix": "Working with the DBA and site management, determine the\n appropriate individuals (by job role) to be notified.\n\n If Oracle Audit Vault is available, configure it to notify the appropriate\n individuals when accounts are disabled.\n\n If Oracle Audit Vault is not available, configure the Oracle DBMS's auditing\n feature to record disabling of accounts.\n\n If Standard Auditing is used:\n Create and deploy a mechanism, such as a frequently-run job, to monitor the\n SYS.AUD$ table for these records and notify the appropriate individuals.\n\n If unified Auditing is used:\n Create and deploy a mechanism, such as a frequently-run job, to monitor the\n SYS.UNIFIED_AUDIT_TRAIL view for these records and notify the appropriate\n individuals." }, - "code": "control 'V-61623' do\n title \"The DBMS must allow designated organizational personnel to select\n which auditable events are to be audited by the database.\"\n desc \"The list of audited events is the set of events for which audits are\n to be generated. This set of events is typically a subset of the list of all\n events for which the system is capable of generating audit records (i.e.,\n auditable events, timestamps, source and destination addresses, user/process\n identifiers, event descriptions, success/fail indications, file names involved,\n and access control or flow control rules invoked).\n\n If the list of auditable events is not configurable, events that should be\n caught by auditing may be missed. This may allow malicious activity to be\n overlooked.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000090-DB-000065'\n tag \"gid\": 'V-61623'\n tag \"rid\": 'SV-76113r1_rule'\n tag \"stig_id\": 'O121-C2-006900'\n tag \"fix_id\": 'F-67539r2_fix'\n tag \"cci\": ['CCI-000171']\n tag \"nist\": ['AU-12 b', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Check DBMS settings and documentation to determine whether\n designated personnel are able to select which auditable events are being\n audited. If designated personnel are not able to configure auditable events,\n this is a finding.\"\n tag \"fix\": \"Configure the DBMS's settings to allow designated personnel to\n select which auditable events are audited.\n\n Note the following:\n In Oracle, any user can configure auditing for the objects in his or her own\n schema by using the AUDIT statement. To undo the audit configuration for an\n object, the user can use the NOAUDIT statement. No additional privileges are\n needed to perform this task.\n\n To audit objects in another schema, the user must have the AUDIT ANY system\n privilege.\n To audit system privileges, the user must have the AUDIT SYSTEM privilege.\n\n For more information on the configuration of auditing, refer to the following\n documents:\n \\\"Auditing Database Activity\\\" in the Oracle Database 2 Day + Security Guide:\n http://docs.oracle.com/database/121/TDPSG/tdpsg_auditing.htm#TDPSG50000\n \\\"Monitoring Database Activity with Auditing\\\" in the Oracle Database Security\n Guide:\n http://docs.oracle.com/database/121/DBSEG/part_6.htm#CCHEHCGI\n \\\"DBMS_AUDIT_MGMT\\\" in the Oracle Database PL/SQL Packages and Types Reference:\n http://docs.oracle.com/database/121/ARPLS/d_audit_mgmt.htm#ARPLS241\"\n describe 'A manual review is required to ensure the DBMS allows designated organizational personnel to select\n which auditable events are to be audited by the database' do\n skip 'A manual review is required to ensure the DBMS allows designated organizational personnel to select\n which auditable events are to be audited by the database'\n end\nend\n", + "code": "control 'V-61801' do\n title \"The DBMS must notify appropriate individuals when account disabling\n actions are taken.\"\n desc \"When application accounts are disabled, user accessibility is\n affected. Accounts are utilized for identifying individual application users or\n for identifying the application processes themselves.\n\n In order to detect and respond to events that affect user accessibility and\n application processing, applications must audit account disabling actions and,\n as required, notify the appropriate individuals so they can investigate the\n event. Such a capability greatly reduces the risk that application\n accessibility will be negatively affected for extended periods of time and also\n provides logging that can be used for forensic purposes.\n\n Note that user authentication and account management must be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP. This requirement applies to cases where accounts are\n directly managed by Oracle.\n\n Notwithstanding how accounts are normally managed, the DBMS must support\n the requirement to notify appropriate individuals upon the disabling of an\n account within Oracle. Indeed, in a configuration where accounts are managed\n externally, the manipulation of an account within Oracle may indicate hostile\n activity.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000293-DB-000130'\n tag \"gid\": 'V-61801'\n tag \"rid\": 'SV-76291r2_rule'\n tag \"stig_id\": 'O121-C2-020600'\n tag \"fix_id\": 'F-67717r1_fix'\n tag \"cci\": ['CCI-001685']\n tag \"nist\": ['AC-2 (4)', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Check DBMS settings to determine whether it will notify\n appropriate individuals when account disabling actions are taken.\n\n If the DBMS does not notify appropriate individuals when account disabling\n actions are taken, this is a finding.\"\n tag \"fix\": \"Working with the DBA and site management, determine the\n appropriate individuals (by job role) to be notified.\n\n If Oracle Audit Vault is available, configure it to notify the appropriate\n individuals when accounts are disabled.\n\n If Oracle Audit Vault is not available, configure the Oracle DBMS's auditing\n feature to record disabling of accounts.\n\n If Standard Auditing is used:\n Create and deploy a mechanism, such as a frequently-run job, to monitor the\n SYS.AUD$ table for these records and notify the appropriate individuals.\n\n If unified Auditing is used:\n Create and deploy a mechanism, such as a frequently-run job, to monitor the\n SYS.UNIFIED_AUDIT_TRAIL view for these records and notify the appropriate\n individuals.\"\n describe 'A manual review is required to ensure the DBMS notifies the appropriate individuals when account disabling\n actions are taken' do\n skip 'A manual review is required to ensure the DBMS notifies the appropriate individuals when account disabling\n actions are taken'\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61623.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61801.rb", "line": 1 }, - "id": "V-61623" + "id": "V-61801" }, { - "title": "Logic modules within the database (to include packages, procedures,\n functions and triggers) must be monitored to discover unauthorized changes.", - "desc": "Any changes to the hardware, software, and/or firmware components of\n the information system and/or application can potentially have significant\n effects on the overall security of the system. This includes the logic modules\n implemented within the database, such as packages, procedures, functions and\n triggers.\n\n If the DBMS were to allow any user to make changes to these, then those\n changes might be implemented without undergoing the appropriate testing and\n approvals that are part of a robust change management process.\n\n Accordingly, only qualified and authorized individuals shall be allowed to\n obtain access to information system components for purposes of initiating\n changes, including upgrades and modifications.\n\n Unmanaged changes that occur to the database logic modules can lead to\n unauthorized or compromised installations.", + "title": "The DBMS must employ strong identification and authentication\n techniques when establishing nonlocal maintenance and diagnostic sessions.", + "desc": "Non-local maintenance and diagnostic activities are those activities\n conducted by individuals communicating through a network, either an external\n network (e.g., the Internet) or an internal network.\n\n The act of managing systems and applications includes the ability to access\n sensitive application information, such as system configuration details,\n diagnostic information, user information, and potentially sensitive application\n data.\n\n When applications provide a remote management capability inherent to the\n application, the application needs to ensure the identification and\n authentication techniques used to remotely access the system are strong enough\n to protect the system. If the communication channel is not adequately\n protected, authentication information, application data, and configuration\n information could be compromised.", "descriptions": { - "default": "Any changes to the hardware, software, and/or firmware components of\n the information system and/or application can potentially have significant\n effects on the overall security of the system. This includes the logic modules\n implemented within the database, such as packages, procedures, functions and\n triggers.\n\n If the DBMS were to allow any user to make changes to these, then those\n changes might be implemented without undergoing the appropriate testing and\n approvals that are part of a robust change management process.\n\n Accordingly, only qualified and authorized individuals shall be allowed to\n obtain access to information system components for purposes of initiating\n changes, including upgrades and modifications.\n\n Unmanaged changes that occur to the database logic modules can lead to\n unauthorized or compromised installations." + "default": "Non-local maintenance and diagnostic activities are those activities\n conducted by individuals communicating through a network, either an external\n network (e.g., the Internet) or an internal network.\n\n The act of managing systems and applications includes the ability to access\n sensitive application information, such as system configuration details,\n diagnostic information, user information, and potentially sensitive application\n data.\n\n When applications provide a remote management capability inherent to the\n application, the application needs to ensure the identification and\n authentication techniques used to remotely access the system are strong enough\n to protect the system. If the communication channel is not adequately\n protected, authentication information, application data, and configuration\n information could be compromised." }, "impact": 0.5, "refs": [], "tags": { - "gtitle": "SRG-APP-000133-DB-000179", - "gid": "V-68863", - "rid": "SV-83467r1_rule", - "stig_id": "O121-OS-010710", - "fix_id": "F-75045r1_fix", + "gtitle": "SRG-APP-000185-DB-000116", + "gid": "V-61751", + "rid": "SV-76241r1_rule", + "stig_id": "O121-C2-016100", + "fix_id": "F-67667r1_fix", "cci": [ - "CCI-001499" + "CCI-000877" ], "nist": [ - "CM-5 (6)", + "MA-4 c)", "Rev_4" ], "false_negatives": null, @@ -5133,35 +5233,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Review monitoring procedures and implementation evidence to\n verify that monitoring of changes to database logic modules is done.\n\n Verify the list of objects (packages, procedures, functions, and triggers)\n being monitored is complete. If monitoring does not occur or is not complete,\n this is a finding.", - "fix": "Implement procedures to monitor for unauthorized changes to\n database logic modules. If a third-party automated tool is not employed, an\n automated job that reports on the objects of interest and compares them to the\n baseline report for the same will meet the requirement." + "check": "Review DBMS settings to determine whether strong identification\n and authentication techniques are required for nonlocal maintenance and\n diagnostic sessions.\n\n If strong identification and authentication techniques are not required, this\n is a finding.", + "fix": "Configure DBMS settings to use strong identification and\n authentication techniques for nonlocal maintenance and diagnostic sessions." }, - "code": "control 'V-68863' do\n title \"Logic modules within the database (to include packages, procedures,\n functions and triggers) must be monitored to discover unauthorized changes.\"\n desc \"Any changes to the hardware, software, and/or firmware components of\n the information system and/or application can potentially have significant\n effects on the overall security of the system. This includes the logic modules\n implemented within the database, such as packages, procedures, functions and\n triggers.\n\n If the DBMS were to allow any user to make changes to these, then those\n changes might be implemented without undergoing the appropriate testing and\n approvals that are part of a robust change management process.\n\n Accordingly, only qualified and authorized individuals shall be allowed to\n obtain access to information system components for purposes of initiating\n changes, including upgrades and modifications.\n\n Unmanaged changes that occur to the database logic modules can lead to\n unauthorized or compromised installations.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000133-DB-000179'\n tag \"gid\": 'V-68863'\n tag \"rid\": 'SV-83467r1_rule'\n tag \"stig_id\": 'O121-OS-010710'\n tag \"fix_id\": 'F-75045r1_fix'\n tag \"cci\": ['CCI-001499']\n tag \"nist\": ['CM-5 (6)', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Review monitoring procedures and implementation evidence to\n verify that monitoring of changes to database logic modules is done.\n\n Verify the list of objects (packages, procedures, functions, and triggers)\n being monitored is complete. If monitoring does not occur or is not complete,\n this is a finding.\"\n tag \"fix\": \"Implement procedures to monitor for unauthorized changes to\n database logic modules. If a third-party automated tool is not employed, an\n automated job that reports on the objects of interest and compares them to the\n baseline report for the same will meet the requirement.\"\n describe 'A manual review is required to ensure the logic modules within the database (to include packages, procedures,\n functions and triggers) are monitored to discover unauthorized changes' do\n skip 'A manual review is required to ensure the logic modules within the database (to include packages, procedures,\n functions and triggers) are monitored to discover unauthorized changes'\n end\nend\n", + "code": "control 'V-61751' do\n title \"The DBMS must employ strong identification and authentication\n techniques when establishing nonlocal maintenance and diagnostic sessions.\"\n desc \"Non-local maintenance and diagnostic activities are those activities\n conducted by individuals communicating through a network, either an external\n network (e.g., the Internet) or an internal network.\n\n The act of managing systems and applications includes the ability to access\n sensitive application information, such as system configuration details,\n diagnostic information, user information, and potentially sensitive application\n data.\n\n When applications provide a remote management capability inherent to the\n application, the application needs to ensure the identification and\n authentication techniques used to remotely access the system are strong enough\n to protect the system. If the communication channel is not adequately\n protected, authentication information, application data, and configuration\n information could be compromised.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000185-DB-000116'\n tag \"gid\": 'V-61751'\n tag \"rid\": 'SV-76241r1_rule'\n tag \"stig_id\": 'O121-C2-016100'\n tag \"fix_id\": 'F-67667r1_fix'\n tag \"cci\": ['CCI-000877']\n tag \"nist\": ['MA-4 c)', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Review DBMS settings to determine whether strong identification\n and authentication techniques are required for nonlocal maintenance and\n diagnostic sessions.\n\n If strong identification and authentication techniques are not required, this\n is a finding.\"\n tag \"fix\": \"Configure DBMS settings to use strong identification and\n authentication techniques for nonlocal maintenance and diagnostic sessions.\"\n describe 'A manual review is required to ensure the DBMS employs strong identification and authentication\n techniques when establishing nonlocal maintenance and diagnostic sessions' do\n skip 'A manual review is required to ensure the DBMS employs strong identification and authentication\n techniques when establishing nonlocal maintenance and diagnostic sessions'\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-68863.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61751.rb", "line": 1 }, - "id": "V-68863" + "id": "V-61751" }, { - "title": "The DBMS must provide the ability to write specified audit record\n content to a centralized audit log repository.", - "desc": "Information system auditing capability is critical for accurate\n forensic analysis. Audit record content that may be necessary to satisfy the\n requirement of this control includes but is not limited: timestamps, source\n and destination IP addresses, user/process identifiers, event descriptions,\n application specific events, success/fail indications, file names involved,\n access control or flow control rules invoked.\n\n Centralized management of audit records and logs provides for efficiency in\n maintenance and management of records, as well as, the backup and archiving of\n those records. When organizations define application components requiring\n centralized audit log management, applications need to support that requirement.\n\n Database audit records not stored in a centralized audit log management\n tool may be overlooked during investigation of a security incident or may be\n subject to intentional or accidental manipulation by privileged users of the\n database.", + "title": "DBMS symmetric keys must be protected in accordance with NSA or\n NIST-approved key management technology or processes.", + "desc": "Symmetric keys used for encryption protect data from unauthorized\n access. However, if not protected in accordance with acceptable standards, the\n keys themselves may be compromised and used for unauthorized data access.", "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: timestamps, source\n and destination IP addresses, user/process identifiers, event descriptions,\n application specific events, success/fail indications, file names involved,\n access control or flow control rules invoked.\n\n Centralized management of audit records and logs provides for efficiency in\n maintenance and management of records, as well as, the backup and archiving of\n those records. When organizations define application components requiring\n centralized audit log management, applications need to support that requirement.\n\n Database audit records not stored in a centralized audit log management\n tool may be overlooked during investigation of a security incident or may be\n subject to intentional or accidental manipulation by privileged users of the\n database." + "default": "Symmetric keys used for encryption protect data from unauthorized\n access. However, if not protected in accordance with acceptable standards, the\n keys themselves may be compromised and used for unauthorized data access." }, "impact": 0.5, "refs": [], "tags": { - "gtitle": "SRG-APP-000102-DB-000045", - "gid": "V-61871", - "rid": "SV-76361r1_rule", - "stig_id": "O121-P2-008100", - "fix_id": "F-67787r1_fix", + "gtitle": "SRG-APP-000516-DB-999900", + "gid": "V-61525", + "rid": "SV-76015r1_rule", + "stig_id": "O121-BP-026100", + "fix_id": "F-67441r1_fix", "cci": [ - "CCI-001844" + "CCI-000366" ], "nist": [ - "AU-3 (2)", + "CM-6 b", "Rev_4" ], "false_negatives": null, @@ -5174,35 +5274,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "If the organization does not require the use of a centralized\n audit log repository, this is not a finding.\n\n If the organization requires the use of a centralized audit log repository,\n continue.\n\n Check that Oracle PL/SQL code or other software is in place to copy or transfer\n the specified audit record content to a centralized audit log repository. If\n it is not, this is a finding.\n\n Check that permissions are set on the Oracle audit trail tables and on the\n target repository to enable the required transfer of audit data. If they are\n not, this is a finding.\n\n Verify that the specified audit record content is indeed copied or transferred\n to the central repository. If it is not, this is a finding.", - "fix": "If the organization requires the use of a centralized audit log\n repository, employ PL/SQL code or other software to copy or transfer the\n specified audit record content to the repository.\n\n Ensure that permissions are set to enable transfer of the data.\n\n If, after the preceding steps, the transfer is not succeeding, diagnose and\n repair the problem.\n\n For more information on the configuration of auditing, refer to the following\n documents:\n \"Auditing Database Activity\" in the Oracle Database 2 Day + Security Guide:\n http://docs.oracle.com/database/121/TDPSG/tdpsg_auditing.htm#TDPSG50000\n \"Monitoring Database Activity with Auditing\" in the Oracle Database Security\n Guide:\n http://docs.oracle.com/database/121/DBSEG/part_6.htm#CCHEHCGI\n \"DBMS_AUDIT_MGMT\" in the Oracle Database PL/SQL Packages and Types Reference:\n http://docs.oracle.com/database/121/ARPLS/d_audit_mgmt.htm#ARPLS241" + "check": "If the symmetric key management procedures and configuration\n settings for the DBMS are not specified in the System Security Plan, this is a\n finding.\n\n If the procedures are not followed, with evidence for audit, this is a finding.\n\n Note: This check does not include a review of the key management procedures\n for validity. Specific key management requirements may be covered under\n separate checks.", + "fix": "Implement the following for symmetric and other encryption keys:\n - protection from unauthorized access in transit and in storage\n - utilization of accepted algorithms\n - generation in accordance with required standards for the key's use\n - expiration date\n - continuity - key backup and recovery\n - key change\n - archival key storage (as necessary)\n\n Details for key management requirements are provided by FIPS 140-2 key\n management standards available from NIST." }, - "code": "control 'V-61871' do\n title \"The DBMS must provide the ability to write specified audit record\n content to a centralized audit log repository.\"\n desc \"Information system auditing capability is critical for accurate\n forensic analysis. Audit record content that may be necessary to satisfy the\n requirement of this control includes but is not limited: timestamps, source\n and destination IP addresses, user/process identifiers, event descriptions,\n application specific events, success/fail indications, file names involved,\n access control or flow control rules invoked.\n\n Centralized management of audit records and logs provides for efficiency in\n maintenance and management of records, as well as, the backup and archiving of\n those records. When organizations define application components requiring\n centralized audit log management, applications need to support that requirement.\n\n Database audit records not stored in a centralized audit log management\n tool may be overlooked during investigation of a security incident or may be\n subject to intentional or accidental manipulation by privileged users of the\n database.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000102-DB-000045'\n tag \"gid\": 'V-61871'\n tag \"rid\": 'SV-76361r1_rule'\n tag \"stig_id\": 'O121-P2-008100'\n tag \"fix_id\": 'F-67787r1_fix'\n tag \"cci\": ['CCI-001844']\n tag \"nist\": ['AU-3 (2)', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"If the organization does not require the use of a centralized\n audit log repository, this is not a finding.\n\n If the organization requires the use of a centralized audit log repository,\n continue.\n\n Check that Oracle PL/SQL code or other software is in place to copy or transfer\n the specified audit record content to a centralized audit log repository. If\n it is not, this is a finding.\n\n Check that permissions are set on the Oracle audit trail tables and on the\n target repository to enable the required transfer of audit data. If they are\n not, this is a finding.\n\n Verify that the specified audit record content is indeed copied or transferred\n to the central repository. If it is not, this is a finding.\"\n tag \"fix\": \"If the organization requires the use of a centralized audit log\n repository, employ PL/SQL code or other software to copy or transfer the\n specified audit record content to the repository.\n\n Ensure that permissions are set to enable transfer of the data.\n\n If, after the preceding steps, the transfer is not succeeding, diagnose and\n repair the problem.\n\n For more information on the configuration of auditing, refer to the following\n documents:\n \\\"Auditing Database Activity\\\" in the Oracle Database 2 Day + Security Guide:\n http://docs.oracle.com/database/121/TDPSG/tdpsg_auditing.htm#TDPSG50000\n \\\"Monitoring Database Activity with Auditing\\\" in the Oracle Database Security\n Guide:\n http://docs.oracle.com/database/121/DBSEG/part_6.htm#CCHEHCGI\n \\\"DBMS_AUDIT_MGMT\\\" in the Oracle Database PL/SQL Packages and Types Reference:\n http://docs.oracle.com/database/121/ARPLS/d_audit_mgmt.htm#ARPLS241\"\n describe 'A manual review is required to ensure the DBMS provides the ability to write specified audit record\n content to a centralized audit log repository' do\n skip 'A manual review is required to ensure the DBMS provides the ability to write specified audit record\n content to a centralized audit log repository'\n end\nend\n", + "code": "control 'V-61525' do\n title \"DBMS symmetric keys must be protected in accordance with NSA or\n NIST-approved key management technology or processes.\"\n desc \"Symmetric keys used for encryption protect data from unauthorized\n access. However, if not protected in accordance with acceptable standards, the\n keys themselves may be compromised and used for unauthorized data access.\"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000516-DB-999900'\n tag \"gid\": 'V-61525'\n tag \"rid\": 'SV-76015r1_rule'\n tag \"stig_id\": 'O121-BP-026100'\n tag \"fix_id\": 'F-67441r1_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 symmetric key management procedures and configuration\n settings for the DBMS are not specified in the System Security Plan, this is a\n finding.\n\n If the procedures are not followed, with evidence for audit, this is a finding.\n\n Note: This check does not include a review of the key management procedures\n for validity. Specific key management requirements may be covered under\n separate checks.\"\n tag \"fix\": \"Implement the following for symmetric and other encryption keys:\n - protection from unauthorized access in transit and in storage\n - utilization of accepted algorithms\n - generation in accordance with required standards for the key's use\n - expiration date\n - continuity - key backup and recovery\n - key change\n - archival key storage (as necessary)\n\n Details for key management requirements are provided by FIPS 140-2 key\n management standards available from NIST.\"\n describe 'A manual review is required to ensure the DBMS symmetric keys are protected in accordance with NSA or\n NIST-approved key management technology or processes.' do\n skip 'A manual review is required to ensure the DBMS symmetric keys are protected in accordance with NSA or\n NIST-approved key management technology or processes.'\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61871.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61525.rb", "line": 1 }, - "id": "V-61871" + "id": "V-61525" }, { - "title": "Database objects must be owned by accounts authorized for ownership.", - "desc": "Within the database, object ownership implies full privileges to the\n owned object including the privilege to assign access to the owned objects to\n other subjects. Unmanaged or uncontrolled ownership of objects can lead to\n unauthorized object grants and alterations, and unauthorized modifications to\n data.\n\n If critical tables or other objects rely on unauthorized owner accounts,\n these objects can be lost when an account is removed.\n\n It may be the case that there are accounts that are authorized to own\n synonyms, but no other objects. If this is so, it should be documented.", + "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": "Within the database, object ownership implies full privileges to the\n owned object including the privilege to assign access to the owned objects to\n other subjects. Unmanaged or uncontrolled ownership of objects can lead to\n unauthorized object grants and alterations, and unauthorized modifications to\n data.\n\n If critical tables or other objects rely on unauthorized owner accounts,\n these objects can be lost when an account is removed.\n\n It may be the case that there are accounts that are authorized to own\n synonyms, but no other objects. If this is so, it should be documented." + "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, + "impact": 0.5, "refs": [], "tags": { - "gtitle": "SRG-APP-000133-DB-000200", - "gid": "V-61673", - "rid": "SV-76163r2_rule", - "stig_id": "O121-C2-011000", - "fix_id": "F-67587r1_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-001499" + "CCI-000764" ], "nist": [ - "CM-5 (6)", + "IA-2", "Rev_4" ], "false_negatives": null, @@ -5215,39 +5315,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Review system documentation to identify accounts authorized to\n own database objects. Review accounts in DBMS that own objects.\n\n If any database objects are found to be owned by users not authorized to own\n database objects, this is a finding.\n\n - - - - -\n Query the object DBA_OBJECTS to show the users who own objects in the database.\n The query below will return all of the users who own objects.\n\n sqlplus connect as sysdba\n\n SQL>select owner, object_type, count(*) from dba_objects\n group by owner, object_type\n order by owner, object_type;\n\n If these owners are not authorized owners, select all of the objects these\n owners have generated and decide who they should belong to. To make a list of\n all of the objects, the unauthorized owner has to perform the following query.\n\n SQL>select * from dba_objects where owner =&unauthorized_owner;", - "fix": "Update system documentation to include list of accounts\n authorized for object ownership.\n\n Re-assign ownership of authorized objects to authorized object owner accounts." + "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-61673' do\n title 'Database objects must be owned by accounts authorized for ownership.'\n desc \"Within the database, object ownership implies full privileges to the\n owned object including the privilege to assign access to the owned objects to\n other subjects. Unmanaged or uncontrolled ownership of objects can lead to\n unauthorized object grants and alterations, and unauthorized modifications to\n data.\n\n If critical tables or other objects rely on unauthorized owner accounts,\n these objects can be lost when an account is removed.\n\n It may be the case that there are accounts that are authorized to own\n synonyms, but no other objects. If this is so, it should be documented.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000133-DB-000200'\n tag \"gid\": 'V-61673'\n tag \"rid\": 'SV-76163r2_rule'\n tag \"stig_id\": 'O121-C2-011000'\n tag \"fix_id\": 'F-67587r1_fix'\n tag \"cci\": ['CCI-001499']\n tag \"nist\": ['CM-5 (6)', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Review system documentation to identify accounts authorized to\n own database objects. Review accounts in DBMS that own objects.\n\n If any database objects are found to be owned by users not authorized to own\n database objects, this is a finding.\n\n - - - - -\n Query the object DBA_OBJECTS to show the users who own objects in the database.\n The query below will return all of the users who own objects.\n\n sqlplus connect as sysdba\n\n SQL>select owner, object_type, count(*) from dba_objects\n group by owner, object_type\n order by owner, object_type;\n\n If these owners are not authorized owners, select all of the objects these\n owners have generated and decide who they should belong to. To make a list of\n all of the objects, the unauthorized owner has to perform the following query.\n\n SQL>select * from dba_objects where owner =&unauthorized_owner;\"\n tag \"fix\": \"Update system documentation to include list of accounts\n authorized for object ownership.\n\n Re-assign ownership of authorized objects to authorized object owner accounts.\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n dba_object_owners = sql.query('select DISTINCT owner from dba_objects;').column('owner').uniq\n if dba_object_owners .empty?\n impact 0.0\n describe 'There are no oracle dba object owners, control N/A' do\n skip 'There are no oracle dba object owners, control N/A'\n end\n else\n dba_object_owners .each do |owner|\n describe \"oracle datbase object owner: #{owner}\" do\n subject { owner }\n it { should be_in input('allowed_dbaobject_owners') }\n end\n end\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-61673.rb", - "line": 2 + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61879.rb", + "line": 1 }, - "id": "V-61673" + "id": "V-61879" }, { - "title": "The DBMS, when using PKI-based authentication, must enforce authorized\n access to the corresponding private key.", - "desc": "The cornerstone of the PKI is the private key used to encrypt or\n digitally sign information.\n\n If the private key is stolen, this will lead to the compromise of the\n authentication and non-repudiation gained through PKI because the attacker can\n use the private key to digitally sign documents and can pretend to be the\n authorized user.\n\n Both the holders of a digital certificate and the issuing authority must\n protect the computers, storage devices, or whatever they use to keep the\n private keys.\n\n All access to the private key of the DBMS must be restricted to authorized\n and authenticated users. If unauthorized users have access to the DBMS’s\n private key, an attacker could gain access to the primary key and use it to\n impersonate the database on the network.\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": "The DBMS must generate audit records for the DoD-selected list of\n auditable events, to the extent such information is available.", + "desc": "Audit records can be generated from various components within the\n information system, such as network interfaces, hard disks, modems, etc. From\n an application perspective, certain specific application functionalities may be\n audited, as well.\n\n The list of audited events is the set of events for which audits are to be\n generated. This set of events is typically a subset of the list of all events\n for which the system is capable of generating audit records (i.e., auditable\n events, timestamps, source and destination addresses, user/process identifiers,\n event descriptions, success/fail indications, file names involved, and access\n control or flow control rules invoked).\n\n Organizations may define the organizational personnel accountable for\n determining which application components shall provide auditable events.\n\n Auditing provides accountability for changes made to the DBMS configuration\n or its objects and data. It provides a means to discover suspicious activity\n and unauthorized changes. Without auditing, a compromise may go undetected and\n without a means to determine accountability.\n\n The Department of Defense has established the following as the minimum set\n of auditable events. Most can be audited via Oracle settings; some - marked\n here with an asterisk - cannot, and may require OS settings.\n - Successful and unsuccessful attempts to access, modify, or delete\n privileges, security objects, security levels, or categories of information\n (e.g. classification levels).\n - Successful and unsuccessful logon attempts, privileged activities or\n other system level access\n - Starting and ending time for user access to the system, concurrent logons\n from different workstations.\n - Successful and unsuccessful accesses to objects.\n - All program initiations.\n - *All direct access to the information system.\n - All account creations, modifications, disabling, and terminations.\n - *All kernel module loads, unloads, and restarts.", "descriptions": { - "default": "The cornerstone of the PKI is the private key used to encrypt or\n digitally sign information.\n\n If the private key is stolen, this will lead to the compromise of the\n authentication and non-repudiation gained through PKI because the attacker can\n use the private key to digitally sign documents and can pretend to be the\n authorized user.\n\n Both the holders of a digital certificate and the issuing authority must\n protect the computers, storage devices, or whatever they use to keep the\n private keys.\n\n All access to the private key of the DBMS must be restricted to authorized\n and authenticated users. If unauthorized users have access to the DBMS’s\n private key, an attacker could gain access to the primary key and use it to\n impersonate the database on the network.\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": "Audit records can be generated from various components within the\n information system, such as network interfaces, hard disks, modems, etc. From\n an application perspective, certain specific application functionalities may be\n audited, as well.\n\n The list of audited events is the set of events for which audits are to be\n generated. This set of events is typically a subset of the list of all events\n for which the system is capable of generating audit records (i.e., auditable\n events, timestamps, source and destination addresses, user/process identifiers,\n event descriptions, success/fail indications, file names involved, and access\n control or flow control rules invoked).\n\n Organizations may define the organizational personnel accountable for\n determining which application components shall provide auditable events.\n\n Auditing provides accountability for changes made to the DBMS configuration\n or its objects and data. It provides a means to discover suspicious activity\n and unauthorized changes. Without auditing, a compromise may go undetected and\n without a means to determine accountability.\n\n The Department of Defense has established the following as the minimum set\n of auditable events. Most can be audited via Oracle settings; some - marked\n here with an asterisk - cannot, and may require OS settings.\n - Successful and unsuccessful attempts to access, modify, or delete\n privileges, security objects, security levels, or categories of information\n (e.g. classification levels).\n - Successful and unsuccessful logon attempts, privileged activities or\n other system level access\n - Starting and ending time for user access to the system, concurrent logons\n from different workstations.\n - Successful and unsuccessful accesses to objects.\n - All program initiations.\n - *All direct access to the information system.\n - All account creations, modifications, disabling, and terminations.\n - *All kernel module loads, unloads, and restarts." }, - "impact": 0, - "refs": [ - { - "ref": [] - } - ], + "impact": 0.5, + "refs": [], "tags": { - "gtitle": "SRG-APP-000176-DB-000068", - "gid": "V-61543", - "rid": "SV-76033r3_rule", - "stig_id": "O121-C1-015400", - "fix_id": "F-67459r1_fix", + "gtitle": "SRG-APP-000091-DB-000066", + "gid": "V-61625", + "rid": "SV-76115r3_rule", + "stig_id": "O121-C2-007000", + "fix_id": "F-67541r1_fix", "cci": [ - "CCI-000186" + "CCI-000172" ], "nist": [ - "IA-5 (2) (b)", + "AU-12 c", "Rev_4" ], "false_negatives": null, @@ -5260,40 +5356,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "If PKI is not enabled in Oracle Database, this is not a finding.\n\n Review DBMS configuration to determine whether appropriate access controls\n exist to protect the DBMS’s private key. If strong access controls do not exist\n to enforce authorized access to the private key, this is a finding.\n\n - - - - -\n The database supports authentication by using digital certificates over TLS in\n addition to the native encryption and data integrity capabilities of these\n protocols.\n\n An Oracle Wallet is a container that is used to store authentication and\n signing credentials, including private keys, certificates, and trusted\n certificates needed by TLS. In an Oracle environment, every entity that\n communicates over TLS must have a wallet containing an X.509 version 3\n certificate, private key, and list of trusted certificates, with the exception\n of Diffie-Hellman.\n\n If the $ORACLE_HOME/network/admin/sqlnet.ora contains the following entries,\n TLS is installed. (Note: This assumes that a single sqlnet.ora file, in the\n default location, is in use. Please see the supplemental file \"Non-default\n sqlnet.ora configurations.pdf\" for how to find multiple and/or differently\n located sqlnet.ora files.)\n\n WALLET_LOCATION = (SOURCE=\n (METHOD = FILE)\n (METHOD_DATA =\n DIRECTORY=/wallet)\n\n SSL_CIPHER_SUITES=(SSL_cipher_suiteExample)\n SSL_VERSION = 1.2 or 1.1\n SSL_CLIENT_AUTHENTICATION=FALSE/TRUE\n\n Note: \"SSL_VERSION = 1.2 or 1.1\" is the actual value, not a suggestion to\n use one or the other.", - "fix": "Implement strong access and authentication controls to protect\n the database’s private key.\n\n Configure the database to support Transport Layer Security (TLS) protocols and\n the Oracle Wallet to store authentication and signing credentials, including\n private keys." + "check": "Check DBMS settings to determine if auditing is being performed\n on the events on the DoD-selected list of auditable events that lie within the\n scope of Oracle audit capabilities:\n - Successful and unsuccessful attempts to access, modify, or delete privileges,\n security objects, security levels, or categories of information (e.g.,\n classification levels).\n - Successful and unsuccessful logon attempts, privileged activities or other\n system-level access\n - Starting and ending time for user access to the system, concurrent logons\n from different workstations.\n - Successful and unsuccessful accesses to objects.\n - All program initiations.\n - All account creations, modifications, disabling, and terminations.\n\n If auditing is not being performed for any of these events, this is a finding.\n\n Notes on Oracle audit capabilities follow.\n\n Unified Audit supports named audit policies, which are defined using the CREATE\n AUDIT POLICY statement. A policy specifies the actions that should be audited\n and the objects to which it should apply. If no specific objects are included\n in the policy definition, it applies to all objects.\n\n A named policy is enabled using the AUDIT POLICY statement. It can be enabled\n for all users, for specific users only, or for all except a specified list of\n users. The policy can audit successful actions, unsuccessful actions, or both.\n\n Verifying existing audit policy: existing Unified Audit policies are listed in\n the view AUDIT_UNIFIED_POLICIES. The AUDIT_OPTION column contains one of the\n actions specified in a CREATE AUDIT POLICY statement. The AUDIT_OPTION_TYPE\n column contains 'STANDARD ACTION' for a policy that applies to all objects or\n 'OBJECT ACTION' for a policy that audits actions on a specific object.\n\n select POLICY_NAME from SYS.AUDIT_UNIFIED_POLICIES where AUDIT_OPTION='GRANT'\n and AUDIT_OPTION_TYPE='STANDARD ACTION';\n\n To find policies that audit privilege grants on specific objects:\n\n select POLICY_NAME,OBJECT_SCHEMA,OBJECT_NAME from SYS.AUDIT_UNIFIED_POLICIES\n where AUDIT_OPTION='GRANT' and AUDIT_OPTION_TYPE='OBJECT ACTION';\n\n The view AUDIT_UNIFIED_ENABLED_POLICIES shows which Unified Audit policies are\n enabled. The ENABLED_OPT and USER_NAME columns show the users for whom the\n policy is enabled or 'ALL USERS'. The SUCCESS and FAILURE columns indicate if\n the policy is enabled for successful or unsuccessful actions, respectively.\n\n select POLICY_NAME,ENABLED_OPT,USER_NAME,SUCCESS,FAILURE from\n SYS.AUDIT_UNIFIED_ENABLED_POLICIES where POLICY_NAME='POLICY1';", + "fix": "Configure the DBMS's auditing settings to include auditing of\n events on the DoD-selected list of auditable events.\n\n 1) Successful and unsuccessful attempts to access, modify, or delete\n privileges, security objects, security levels, or categories of information\n (e.g., classification levels)\n\n To audit granting and revocation of any privilege:\n create audit policy policy1 actions grant;\n create audit policy policy2 actions revoke;\n\n To audit grants of object privileges on a specific object:\n create audit policy policy3 actions grant on .;\n\n If Oracle Label Security is enabled, this will audit all OLS administrative\n actions:\n create audit policy policy4 actions component = OLS all;\n\n 2) Successful and unsuccessful logon attempts, privileged activities or other\n system-level access\n\n To audit all user logon attempts:\n create audit policy policy5 actions logon;\n\n To audit only logon attempts using administrative privileges (e.g. AS SYSDBA):\n audit policy policy5 by SYS, SYSOPER, SYSBACKUP, SYSDG, SYSKM;\n\n 3) Starting and ending time for user access to the system, concurrent logons\n from different workstations\n\n This policy will audit all logon and logoff events. An individual session is\n identified in the UNIFIED_AUDIT_TRAIL by the tuple (DBID, INSTANCE_ID,\n SESSIONID) and the start and end time will be indicated by the EVENT_TIMESTAMP\n of the logon and logoff events:\n create audit policy policy6 actions logon, logoff;\n\n 4) Successful and unsuccessful accesses to objects\n\n To audit all accesses to a specific table:\n create audit policy policy7 actions select, insert, delete, alter on\n .;\n\n Different actions are defined for other object types. To audit all supported\n actions on a specific object:\n create audit policy policy8 actions all on .;\n\n 5) All program initiations\n\n To audit execution of any PL/SQL program unit:\n create audit policy policy9 actions EXECUTE;\n\n To audit execution of a specific function, procedure, or package:\n create audit policy policy10 actions EXECUTE on .;\n\n 6) All direct access to the information system\n\n [Not applicable to Database audit. Monitor using OS auditing.]\n\n 7) All account creations, modifications, disabling, and terminations\n\n To audit all user administration actions:\n create audit policy policy11 actions create user, alter user, drop user, change\n password;\n\n 8) All kernel module loads, unloads, and restarts\n\n [Not applicable to Database audit. Monitor using OS auditing.]\n\n 9) All database parameter changes\n\n To audit any database parameter changes, dynamic or static:\n create audit policy policy12 actions alter database, alter system, create\n spfile;\n\n Applying the Policy\n\n The following command will enable the policy in all database sessions and audit\n both successful and unsuccessful actions:\n audit policy policy1;\n\n To audit only unsuccessful actions, add the WHENEVER NOT SUCCESSFUL modifier:\n audit policy policy1 whenever not successful;\n\n Either command above can be limited to only database sessions started by a\n specific user as follows:\n audit policy policy1 by ;\n audit policy policy1 by whenever not successful;" }, - "code": " control 'V-61543' 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-61625' do\n title \"The DBMS must generate audit records for the DoD-selected list of\n auditable events, to the extent such information is available.\"\n desc \"Audit records can be generated from various components within the\n information system, such as network interfaces, hard disks, modems, etc. From\n an application perspective, certain specific application functionalities may be\n audited, as well.\n\n The list of audited events is the set of events for which audits are to be\n generated. This set of events is typically a subset of the list of all events\n for which the system is capable of generating audit records (i.e., auditable\n events, timestamps, source and destination addresses, user/process identifiers,\n event descriptions, success/fail indications, file names involved, and access\n control or flow control rules invoked).\n\n Organizations may define the organizational personnel accountable for\n determining which application components shall provide auditable events.\n\n Auditing provides accountability for changes made to the DBMS configuration\n or its objects and data. It provides a means to discover suspicious activity\n and unauthorized changes. Without auditing, a compromise may go undetected and\n without a means to determine accountability.\n\n The Department of Defense has established the following as the minimum set\n of auditable events. Most can be audited via Oracle settings; some - marked\n here with an asterisk - cannot, and may require OS settings.\n - Successful and unsuccessful attempts to access, modify, or delete\n privileges, security objects, security levels, or categories of information\n (e.g. classification levels).\n - Successful and unsuccessful logon attempts, privileged activities or\n other system level access\n - Starting and ending time for user access to the system, concurrent logons\n from different workstations.\n - Successful and unsuccessful accesses to objects.\n - All program initiations.\n - *All direct access to the information system.\n - All account creations, modifications, disabling, and terminations.\n - *All kernel module loads, unloads, and restarts.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000091-DB-000066'\n tag \"gid\": 'V-61625'\n tag \"rid\": 'SV-76115r3_rule'\n tag \"stig_id\": 'O121-C2-007000'\n tag \"fix_id\": 'F-67541r1_fix'\n tag \"cci\": ['CCI-000172']\n tag \"nist\": ['AU-12 c', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Check DBMS settings to determine if auditing is being performed\n on the events on the DoD-selected list of auditable events that lie within the\n scope of Oracle audit capabilities:\n - Successful and unsuccessful attempts to access, modify, or delete privileges,\n security objects, security levels, or categories of information (e.g.,\n classification levels).\n - Successful and unsuccessful logon attempts, privileged activities or other\n system-level access\n - Starting and ending time for user access to the system, concurrent logons\n from different workstations.\n - Successful and unsuccessful accesses to objects.\n - All program initiations.\n - All account creations, modifications, disabling, and terminations.\n\n If auditing is not being performed for any of these events, this is a finding.\n\n Notes on Oracle audit capabilities follow.\n\n Unified Audit supports named audit policies, which are defined using the CREATE\n AUDIT POLICY statement. A policy specifies the actions that should be audited\n and the objects to which it should apply. If no specific objects are included\n in the policy definition, it applies to all objects.\n\n A named policy is enabled using the AUDIT POLICY statement. It can be enabled\n for all users, for specific users only, or for all except a specified list of\n users. The policy can audit successful actions, unsuccessful actions, or both.\n\n Verifying existing audit policy: existing Unified Audit policies are listed in\n the view AUDIT_UNIFIED_POLICIES. The AUDIT_OPTION column contains one of the\n actions specified in a CREATE AUDIT POLICY statement. The AUDIT_OPTION_TYPE\n column contains 'STANDARD ACTION' for a policy that applies to all objects or\n 'OBJECT ACTION' for a policy that audits actions on a specific object.\n\n select POLICY_NAME from SYS.AUDIT_UNIFIED_POLICIES where AUDIT_OPTION='GRANT'\n and AUDIT_OPTION_TYPE='STANDARD ACTION';\n\n To find policies that audit privilege grants on specific objects:\n\n select POLICY_NAME,OBJECT_SCHEMA,OBJECT_NAME from SYS.AUDIT_UNIFIED_POLICIES\n where AUDIT_OPTION='GRANT' and AUDIT_OPTION_TYPE='OBJECT ACTION';\n\n The view AUDIT_UNIFIED_ENABLED_POLICIES shows which Unified Audit policies are\n enabled. The ENABLED_OPT and USER_NAME columns show the users for whom the\n policy is enabled or 'ALL USERS'. The SUCCESS and FAILURE columns indicate if\n the policy is enabled for successful or unsuccessful actions, respectively.\n\n select POLICY_NAME,ENABLED_OPT,USER_NAME,SUCCESS,FAILURE from\n SYS.AUDIT_UNIFIED_ENABLED_POLICIES where POLICY_NAME='POLICY1';\"\n tag \"fix\": \"Configure the DBMS's auditing settings to include auditing of\n events on the DoD-selected list of auditable events.\n\n 1) Successful and unsuccessful attempts to access, modify, or delete\n privileges, security objects, security levels, or categories of information\n (e.g., classification levels)\n\n To audit granting and revocation of any privilege:\n create audit policy policy1 actions grant;\n create audit policy policy2 actions revoke;\n\n To audit grants of object privileges on a specific object:\n create audit policy policy3 actions grant on .;\n\n If Oracle Label Security is enabled, this will audit all OLS administrative\n actions:\n create audit policy policy4 actions component = OLS all;\n\n 2) Successful and unsuccessful logon attempts, privileged activities or other\n system-level access\n\n To audit all user logon attempts:\n create audit policy policy5 actions logon;\n\n To audit only logon attempts using administrative privileges (e.g. AS SYSDBA):\n audit policy policy5 by SYS, SYSOPER, SYSBACKUP, SYSDG, SYSKM;\n\n 3) Starting and ending time for user access to the system, concurrent logons\n from different workstations\n\n This policy will audit all logon and logoff events. An individual session is\n identified in the UNIFIED_AUDIT_TRAIL by the tuple (DBID, INSTANCE_ID,\n SESSIONID) and the start and end time will be indicated by the EVENT_TIMESTAMP\n of the logon and logoff events:\n create audit policy policy6 actions logon, logoff;\n\n 4) Successful and unsuccessful accesses to objects\n\n To audit all accesses to a specific table:\n create audit policy policy7 actions select, insert, delete, alter on\n .;\n\n Different actions are defined for other object types. To audit all supported\n actions on a specific object:\n create audit policy policy8 actions all on .;\n\n 5) All program initiations\n\n To audit execution of any PL/SQL program unit:\n create audit policy policy9 actions EXECUTE;\n\n To audit execution of a specific function, procedure, or package:\n create audit policy policy10 actions EXECUTE on .;\n\n 6) All direct access to the information system\n\n [Not applicable to Database audit. Monitor using OS auditing.]\n\n 7) All account creations, modifications, disabling, and terminations\n\n To audit all user administration actions:\n create audit policy policy11 actions create user, alter user, drop user, change\n password;\n\n 8) All kernel module loads, unloads, and restarts\n\n [Not applicable to Database audit. Monitor using OS auditing.]\n\n 9) All database parameter changes\n\n To audit any database parameter changes, dynamic or static:\n create audit policy policy12 actions alter database, alter system, create\n spfile;\n\n Applying the Policy\n\n The following command will enable the policy in all database sessions and audit\n both successful and unsuccessful actions:\n audit policy policy1;\n\n To audit only unsuccessful actions, add the WHENEVER NOT SUCCESSFUL modifier:\n audit policy policy1 whenever not successful;\n\n Either command above can be limited to only database sessions started by a\n specific user as follows:\n audit policy policy1 by ;\n audit policy policy1 by whenever not successful;\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n standard_auditing_used = input('standard_auditing_used')\n unified_auditing_used = input('unified_auditing_used')\n\n describe.one do\n describe 'Standard auditing is in use for audit purposes' do\n subject { standard_auditing_used }\n it { should be true }\n end\n\n describe 'Unified auditing is in use for audit purposes' do\n subject { unified_auditing_used }\n it { should be true }\n end\n end\n\n audit_trail = sql.query(\"select value from v$parameter where name = 'audit_trail';\").column('value')\n audit_policies_auditing_grant_privileges = sql.query(\"select DISTINCT POLICY_NAME from AUDIT_UNIFIED_POLICIES\n where AUDIT_OPTION='GRANT' and AUDIT_OPTION_TYPE='OBJECT ACTION';\").column('policy_name')\n unified_audit_policies_enabled = sql.query('select POLICY_NAME from AUDIT_UNIFIED_ENABLED_POLICIES;').column('policy_name')\n\n if standard_auditing_used\n describe 'The oracle database audit_trail parameter' do\n subject { audit_trail }\n it { should_not cmp 'NONE' }\n end\n end\n\n unified_auditing = sql.query(\"SELECT value FROM V$OPTION WHERE PARAMETER = 'Unified Auditing';\").column('value')\n\n if unified_auditing_used\n describe 'The oracle database unified auditing parameter' do\n subject { unified_auditing }\n it { should_not cmp 'FALSE' }\n end\n\n describe 'The audit policies that audit privilege grants on specific objects' do\n subject { audit_policies_auditing_grant_privileges }\n it { should_not be_empty }\n end\n\n describe 'The list of unified audit policies enabled' do\n subject { unified_audit_policies_enabled }\n it { should_not be_empty }\n end\n\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61543.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61625.rb", "line": 1 }, - "id": "V-61543" + "id": "V-61625" }, { - "title": "Administrative privileges must be assigned to database accounts via\n database roles.", - "desc": "Applications employ the concept of least privilege for specific duties\n and information systems (including specific functions, ports, protocols, and\n services). The concept of least privilege is also applied to information system\n processes, ensuring that the processes operate at privilege levels no higher\n than necessary to accomplish required organizational missions and/or functions.\n Organizations consider the creation of additional processes, roles, and\n information system accounts as necessary to achieve least privilege.\n Organizations also apply least privilege concepts to the design, development,\n implementation, and operations of information systems.\n Privileges granted outside the context of the application user job function\n are more likely to go unmanaged or without oversight for authorization.\n Maintenance of privileges using roles defined for discrete job functions offers\n improved oversight of application user privilege assignments and helps to\n protect against unauthorized privilege assignment.", + "title": "The system must provide an audit log reduction capability.", + "desc": "Audit reduction is used to reduce the volume of audit records in order\n to facilitate manual review. Before a security review, information systems\n and/or applications with an audit reduction capability may remove many audit\n records known to have 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. Audit\n reduction does not alter original audit records.\n\n An audit reduction capability provides support for near real-time audit\n review and analysis requirements and after-the-fact investigations of security\n incidents.\n\n The lack of audit reduction in a database can require the DBA, or others\n responsible for reviewing audit logs, to sort through large amounts of data in\n order to find relevant records. This can cause important audit records to be\n missed.", "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 Privileges granted outside the context of the application user job function\n are more likely to go unmanaged or without oversight for authorization.\n Maintenance of privileges using roles defined for discrete job functions offers\n improved oversight of application user privilege assignments and helps to\n protect against unauthorized privilege assignment." + "default": "Audit reduction is used to reduce the volume of audit records in order\n to facilitate manual review. Before a security review, information systems\n and/or applications with an audit reduction capability may remove many audit\n records known to have 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. Audit\n reduction does not alter original audit records.\n\n An audit reduction capability provides support for near real-time audit\n review and analysis requirements and after-the-fact investigations of security\n incidents.\n\n The lack of audit reduction in a database can require the DBA, or others\n responsible for reviewing audit logs, to sort through large amounts of data in\n order to find relevant records. This can cause important audit records to be\n missed." }, - "impact": 0.5, - "refs": [ - { - "ref": [] - } - ], + "impact": 0.3, + "refs": [], "tags": { - "gtitle": "SRG-APP-000062-DB-000034", - "gid": "V-61591", - "rid": "SV-76081r3_rule", - "stig_id": "O121-C2-004000", - "fix_id": "F-67507r1_fix", + "gtitle": "SRG-APP-000113-DB-000053", + "gid": "V-61813", + "rid": "SV-76303r1_rule", + "stig_id": "O121-C3-008700", + "fix_id": "F-67729r1_fix", "cci": [ - "CCI-000366", - "CCI-002220" + "CCI-001875" ], "nist": [ - "AC-5 c", + "AU-7 a", "Rev_4" ], "false_negatives": null, @@ -5306,35 +5397,39 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Review accounts for direct assignment of administrative\n privileges. Connected as SYSDBA, run the query:\n SELECT grantee, privilege\n FROM dba_sys_privs\n WHERE grantee IN\n (\n SELECT username\n FROM dba_users\n WHERE username NOT IN\n (\n 'XDB', 'SYSTEM', 'SYS', 'LBACSYS',\n 'DVSYS', 'DVF', 'SYSMAN_RO',\n 'SYSMAN_BIPLATFORM', 'SYSMAN_MDS',\n 'SYSMAN_OPSS', 'SYSMAN_STB', 'DBSNMP',\n 'SYSMAN', 'APEX_040200', 'WMSYS',\n 'SYSDG', 'SYSBACKUP', 'SPATIAL_WFS_ADMIN_USR',\n 'SPATIAL_CSW_ADMIN_US', 'GSMCATUSER',\n 'OLAPSYS', 'SI_INFORMTN_SCHEMA',\n 'OUTLN', 'ORDSYS', 'ORDDATA', 'OJVMSYS',\n 'ORACLE_OCM', 'MDSYS', 'ORDPLUGINS',\n 'GSMADMIN_INTERNAL', 'MDDATA', 'FLOWS_FILES',\n 'DIP', 'CTXSYS', 'AUDSYS',\n 'APPQOSSYS', 'APEX_PUBLIC_USER', 'ANONYMOUS',\n 'SPATIAL_CSW_ADMIN_USR', 'SYSKM',\n 'SYSMAN_TYPES', 'MGMT_VIEW',\n 'EUS_ENGINE_USER', 'EXFSYS', 'SYSMAN_APM'\n )\n )\n AND privilege NOT IN ('UNLIMITED TABLESPACE'\n , 'REFERENCES', 'INDEX', 'SYSDBA', 'SYSOPER'\n )\n ORDER BY 1, 2;\n If any administrative privileges have been assigned directly to a database\n account, this is a finding.\n (The list of special accounts that are excluded from this requirement may not\n be complete. It is expected that the DBA will edit the list to suit local\n circumstances, adding other special accounts as necessary, and removing any\n that are not supposed to be in use in the Oracle deployment that is under\n review.)", - "fix": "Create roles for administrative function assignments. Assign the\n necessary privileges for the administrative functions to a role. Do not assign\n administrative privileges directly to users, except for those that Oracle does\n not permit to be assigned via roles." + "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.\n\n If this capability has not been implemented, this is a finding.", + "fix": "Deploy software capable of performing audit data reduction." }, - "code": "control 'V-61591' do\n title \"Administrative privileges must be assigned to database accounts via\n database roles.\"\n desc \"Applications employ the concept of least privilege for specific duties\n and information systems (including specific functions, ports, protocols, and\n services). The concept of least privilege is also applied to information system\n processes, ensuring that the processes operate at privilege levels no higher\n than necessary to accomplish required organizational missions and/or functions.\n Organizations consider the creation of additional processes, roles, and\n information system accounts as necessary to achieve least privilege.\n Organizations also apply least privilege concepts to the design, development,\n implementation, and operations of information systems.\n Privileges granted outside the context of the application user job function\n are more likely to go unmanaged or without oversight for authorization.\n Maintenance of privileges using roles defined for discrete job functions offers\n improved oversight of application user privilege assignments and helps to\n protect against unauthorized privilege assignment.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000062-DB-000034'\n tag \"gid\": 'V-61591'\n tag \"rid\": 'SV-76081r3_rule'\n tag \"stig_id\": 'O121-C2-004000'\n tag \"fix_id\": 'F-67507r1_fix'\n tag \"cci\": ['CCI-000366', 'CCI-002220']\n tag \"nist\": ['CM-6 b', 'Rev_4']\n tag \"nist\": ['AC-5 c', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Review accounts for direct assignment of administrative\n privileges. Connected as SYSDBA, run the query:\n SELECT grantee, privilege\n FROM dba_sys_privs\n WHERE grantee IN\n (\n SELECT username\n FROM dba_users\n WHERE username NOT IN\n (\n 'XDB', 'SYSTEM', 'SYS', 'LBACSYS',\n 'DVSYS', 'DVF', 'SYSMAN_RO',\n 'SYSMAN_BIPLATFORM', 'SYSMAN_MDS',\n 'SYSMAN_OPSS', 'SYSMAN_STB', 'DBSNMP',\n 'SYSMAN', 'APEX_040200', 'WMSYS',\n 'SYSDG', 'SYSBACKUP', 'SPATIAL_WFS_ADMIN_USR',\n 'SPATIAL_CSW_ADMIN_US', 'GSMCATUSER',\n 'OLAPSYS', 'SI_INFORMTN_SCHEMA',\n 'OUTLN', 'ORDSYS', 'ORDDATA', 'OJVMSYS',\n 'ORACLE_OCM', 'MDSYS', 'ORDPLUGINS',\n 'GSMADMIN_INTERNAL', 'MDDATA', 'FLOWS_FILES',\n 'DIP', 'CTXSYS', 'AUDSYS',\n 'APPQOSSYS', 'APEX_PUBLIC_USER', 'ANONYMOUS',\n 'SPATIAL_CSW_ADMIN_USR', 'SYSKM',\n 'SYSMAN_TYPES', 'MGMT_VIEW',\n 'EUS_ENGINE_USER', 'EXFSYS', 'SYSMAN_APM'\n )\n )\n AND privilege NOT IN ('UNLIMITED TABLESPACE'\n , 'REFERENCES', 'INDEX', 'SYSDBA', 'SYSOPER'\n )\n ORDER BY 1, 2;\n If any administrative privileges have been assigned directly to a database\n account, this is a finding.\n (The list of special accounts that are excluded from this requirement may not\n be complete. It is expected that the DBA will edit the list to suit local\n circumstances, adding other special accounts as necessary, and removing any\n that are not supposed to be in use in the Oracle deployment that is under\n review.)\"\n tag \"fix\": \"Create roles for administrative function assignments. Assign the\n necessary privileges for the administrative functions to a role. Do not assign\n administrative privileges directly to users, except for those that Oracle does\n not permit to be assigned via roles.\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n database_accounts_with_administrative_privs = sql.query(\"SELECT grantee\n FROM dba_sys_privs\n WHERE grantee IN\n (\n SELECT username\n FROM dba_users\n WHERE username NOT IN\n (\n 'XDB', 'SYSTEM', 'SYS', 'LBACSYS',\n 'DVSYS', 'DVF', 'SYSMAN_RO',\n 'SYSMAN_BIPLATFORM', 'SYSMAN_MDS',\n 'SYSMAN_OPSS', 'SYSMAN_STB', 'DBSNMP',\n 'SYSMAN', 'APEX_040200', 'WMSYS',\n 'SYSDG', 'SYSBACKUP', 'SPATIAL_WFS_ADMIN_USR',\n 'SPATIAL_CSW_ADMIN_US', 'GSMCATUSER',\n 'OLAPSYS', 'SI_INFORMTN_SCHEMA',\n 'OUTLN', 'ORDSYS', 'ORDDATA', 'OJVMSYS',\n 'ORACLE_OCM', 'MDSYS', 'ORDPLUGINS',\n 'GSMADMIN_INTERNAL', 'MDDATA', 'FLOWS_FILES',\n 'DIP', 'CTXSYS', 'AUDSYS',\n 'APPQOSSYS', 'APEX_PUBLIC_USER', 'ANONYMOUS',\n 'SPATIAL_CSW_ADMIN_USR', 'SYSKM',\n 'SYSMAN_TYPES', 'MGMT_VIEW',\n 'EUS_ENGINE_USER', 'EXFSYS', 'SYSMAN_APM', 'RDSADMIN'\n )\n )\n AND privilege NOT IN ('UNLIMITED TABLESPACE'\n , 'REFERENCES', 'INDEX', 'SYSDBA', 'SYSOPER'\n );\").column('grantee').uniq\n\n describe 'Database accounts with administrative privileges' do\n subject { database_accounts_with_administrative_privs }\n it { should be_empty }\n end\nend\n", + "code": "control 'V-61813' do\n title 'The system must provide an audit log reduction capability.'\n desc \"Audit reduction is used to reduce the volume of audit records in order\n to facilitate manual review. Before a security review, information systems\n and/or applications with an audit reduction capability may remove many audit\n records known to have 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. Audit\n reduction does not alter original audit records.\n\n An audit reduction capability provides support for near real-time audit\n review and analysis requirements and after-the-fact investigations of security\n incidents.\n\n The lack of audit reduction in a database can require the DBA, or others\n responsible for reviewing audit logs, to sort through large amounts of data in\n order to find relevant records. This can cause important audit records to be\n missed.\n \"\n impact 0.3\n tag \"gtitle\": 'SRG-APP-000113-DB-000053'\n tag \"gid\": 'V-61813'\n tag \"rid\": 'SV-76303r1_rule'\n tag \"stig_id\": 'O121-C3-008700'\n tag \"fix_id\": 'F-67729r1_fix'\n tag \"cci\": ['CCI-001875']\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.\n\n If this capability has not been implemented, this is a finding.\"\n tag \"fix\": 'Deploy software capable of performing audit data reduction.'\n describe 'A manual review is required to ensure the system provides an audit log reduction capability' do\n skip 'A manual review is required to ensure the system provides an audit log reduction capability'\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61591.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61813.rb", "line": 1 }, - "id": "V-61591" + "id": "V-61813" }, { - "title": "The DBMS must have allocated audit record storage capacity.", - "desc": "Applications need to be cognizant of potential audit log storage\n capacity issues. During the installation and/or configuration process,\n applications should detect and determine if adequate storage capacity has been\n allocated for audit logs.\n\n During the installation process, a notification may be provided to the\n installer indicating, based on the auditing configuration chosen and the amount\n of storage space allocated for audit logs, the amount of storage capacity\n available is not sufficient to meet storage requirements.\n\n When insufficient space in directories is allocated for audit records,\n database audit logs can fill up and begin to overwrite earlier logs, database\n activity can stop altogether, or auditing could fail and crucial tracking data\n could be lost.", + "title": "The DBMS must employ cryptographic mechanisms preventing the\n unauthorized disclosure of information during transmission unless the\n transmitted data is otherwise protected by alternative physical measures.", + "desc": "Preventing the disclosure of transmitted information requires that\n applications take measures to employ some form of cryptographic mechanism in\n order to protect the information during transmission. This is usually achieved\n through the use of Transport Layer Security (TLS), SSL VPN, or IPSEC tunnel.\n\n Alternative physical protection measures include Protected Distribution\n Systems (PDS). PDS are used to transmit unencrypted classified NSI through an\n area of lesser classification or control. Inasmuch as the classified NSI is\n unencrypted, the PDS must provide adequate electrical, electromagnetic, and\n physical safeguards to deter exploitation. Refer to NSTSSI No. 7003 for\n additional details on a PDS.\n\n Information in transmission is particularly vulnerable to attack. If the\n DBMS does not employ cryptographic mechanisms preventing unauthorized\n disclosure of information during transit, the information may be compromised.\n\n SHA-1 is in the process of being removed from service within the DoD and\n it's use is to be limited during the transition to SHA-2. Use of SHA-1 for\n digital signature generation is prohibited. Allowable uses during the\n transition include CHECKSUM usage and verification of legacy certificate\n signatures. SHA-1 is considered a temporary solution during legacy application\n transitionary periods and should not be engineered into new applications. SHA-2\n is the path forward for DoD.", "descriptions": { - "default": "Applications need to be cognizant of potential audit log storage\n capacity issues. During the installation and/or configuration process,\n applications should detect and determine if adequate storage capacity has been\n allocated for audit logs.\n\n During the installation process, a notification may be provided to the\n installer indicating, based on the auditing configuration chosen and the amount\n of storage space allocated for audit logs, the amount of storage capacity\n available is not sufficient to meet storage requirements.\n\n When insufficient space in directories is allocated for audit records,\n database audit logs can fill up and begin to overwrite earlier logs, database\n activity can stop altogether, or auditing could fail and crucial tracking data\n could be lost." + "default": "Preventing the disclosure of transmitted information requires that\n applications take measures to employ some form of cryptographic mechanism in\n order to protect the information during transmission. This is usually achieved\n through the use of Transport Layer Security (TLS), SSL VPN, or IPSEC tunnel.\n\n Alternative physical protection measures include Protected Distribution\n Systems (PDS). PDS are used to transmit unencrypted classified NSI through an\n area of lesser classification or control. Inasmuch as the classified NSI is\n unencrypted, the PDS must provide adequate electrical, electromagnetic, and\n physical safeguards to deter exploitation. Refer to NSTSSI No. 7003 for\n additional details on a PDS.\n\n Information in transmission is particularly vulnerable to attack. If the\n DBMS does not employ cryptographic mechanisms preventing unauthorized\n disclosure of information during transit, the information may be compromised.\n\n SHA-1 is in the process of being removed from service within the DoD and\n it's use is to be limited during the transition to SHA-2. Use of SHA-1 for\n digital signature generation is prohibited. Allowable uses during the\n transition include CHECKSUM usage and verification of legacy certificate\n signatures. SHA-1 is considered a temporary solution during legacy application\n transitionary periods and should not be engineered into new applications. SHA-2\n is the path forward for DoD." }, - "impact": 0.5, - "refs": [], + "impact": 0, + "refs": [ + { + "ref": [] + } + ], "tags": { - "gtitle": "SRG-APP-000072-DB-000046", - "gid": "V-61615", - "rid": "SV-76105r1_rule", - "stig_id": "O121-C2-005700", - "fix_id": "F-67531r1_fix", + "gtitle": "SRG-APP-000264-DB-000136", + "gid": "V-61545", + "rid": "SV-76035r5_rule", + "stig_id": "O121-C1-019700", + "fix_id": "F-67461r1_fix", "cci": [ - "CCI-001849" + "CCI-002421" ], "nist": [ - "AU-4", + "SC-8 (1)", "Rev_4" ], "false_negatives": null, @@ -5347,35 +5442,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Review the DBMS settings to determine whether audit logging is\n configured to produce logs consistent with the amount of space allocated for\n logging. If auditing will generate excessive logs so that they may outgrow the\n space reserved for logging, this is a finding.\n\n If file-based auditing is in use, check that sufficient space is available to\n support the file(s). If not, this is a finding\n\n If standard, table-based auditing is used: The audit logs are written to a\n table called AUD$, and if a Virtual Private Database is deployed, we also\n create a table called FGA_LOG$. First check the current location of the audit\n trail tables.\n\n CONN / AS SYSDBA\n\n SELECT table_name, tablespace_name\n FROM dba_tables\n WHERE table_name IN ('AUD$', 'FGA_LOG$')\n ORDER BY table_name;\n\n TABLE_NAME TABLESPACE_NAME\n ------------------------------ ------------------------------\n AUD$ SYSTEM\n FGA_LOG$ SYSTEM\n\n If the tablespace name is SYSTEM, the table needs to be relocated to its own\n tablespace. Ensure that adequate space is allocated to that tablespace.\n\n If Unified Auditing is used:\n Audit logs are written to tables in the AUDSYS schema. The default tablespace\n for AUDSYS is USERS. A separate tablespace should be created to contain audit\n data. Ensure that adequate space is allocated to that tablespace.", - "fix": "Allocate sufficient disk space for file-based audit.\n\n Ensure that audit tables are in their own tablespaces and that the tablespaces\n have enough room for the volume of log data that will be produced." + "check": "Check DBMS settings to determine whether cryptographic\n mechanisms are used to prevent the unauthorized disclosure of information\n during transmission. Determine whether physical measures are being used instead\n of cryptographic mechanisms. If neither cryptographic nor physical measures are\n being utilized, this is a finding.\n\n To check that network encryption is enabled and using site-specified encryption\n procedures, look in SQLNET.ORA located at\n $ORACLE_HOME/network/admin/sqlnet.ora. (Note: This assumes that a single\n sqlnet.ora file, in the default location, is in use. Please see the\n supplemental file \"Non-default sqlnet.ora configurations.pdf\" for how to find\n multiple and/or differently located sqlnet.ora files.) If encryption is set,\n entries like the following will be present:\n\n SQLNET.CRYPTO_CHECKSUM_TYPES_CLIENT= (SHA384)\n SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER= (SHA384)\n SQLNET.ENCRYPTION_TYPES_CLIENT= (AES256)\n\n SQLNET.ENCRYPTION_TYPES_SERVER= (AES256)\n SQLNET.CRYPTO_CHECKSUM_CLIENT = requested\n SQLNET.CRYPTO_CHECKSUM_SERVER = required\n\n (The values assigned to the parameters may be different, the combination of\n parameters may be different, and not all of the example parameters will\n necessarily exist in the file.)", + "fix": "Configure DBMS and/or operating system to use cryptographic\n mechanisms to prevent unauthorized disclosure of information during\n transmission where physical measures are not being utilized." }, - "code": "control 'V-61615' do\n title 'The DBMS must have allocated audit record storage capacity.'\n desc \"Applications need to be cognizant of potential audit log storage\n capacity issues. During the installation and/or configuration process,\n applications should detect and determine if adequate storage capacity has been\n allocated for audit logs.\n\n During the installation process, a notification may be provided to the\n installer indicating, based on the auditing configuration chosen and the amount\n of storage space allocated for audit logs, the amount of storage capacity\n available is not sufficient to meet storage requirements.\n\n When insufficient space in directories is allocated for audit records,\n database audit logs can fill up and begin to overwrite earlier logs, database\n activity can stop altogether, or auditing could fail and crucial tracking data\n could be lost.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000072-DB-000046'\n tag \"gid\": 'V-61615'\n tag \"rid\": 'SV-76105r1_rule'\n tag \"stig_id\": 'O121-C2-005700'\n tag \"fix_id\": 'F-67531r1_fix'\n tag \"cci\": ['CCI-001849']\n tag \"nist\": ['AU-4', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Review the DBMS settings to determine whether audit logging is\n configured to produce logs consistent with the amount of space allocated for\n logging. If auditing will generate excessive logs so that they may outgrow the\n space reserved for logging, this is a finding.\n\n If file-based auditing is in use, check that sufficient space is available to\n support the file(s). If not, this is a finding\n\n If standard, table-based auditing is used: The audit logs are written to a\n table called AUD$, and if a Virtual Private Database is deployed, we also\n create a table called FGA_LOG$. First check the current location of the audit\n trail tables.\n\n CONN / AS SYSDBA\n\n SELECT table_name, tablespace_name\n FROM dba_tables\n WHERE table_name IN ('AUD$', 'FGA_LOG$')\n ORDER BY table_name;\n\n TABLE_NAME TABLESPACE_NAME\n ------------------------------ ------------------------------\n AUD$ SYSTEM\n FGA_LOG$ SYSTEM\n\n If the tablespace name is SYSTEM, the table needs to be relocated to its own\n tablespace. Ensure that adequate space is allocated to that tablespace.\n\n If Unified Auditing is used:\n Audit logs are written to tables in the AUDSYS schema. The default tablespace\n for AUDSYS is USERS. A separate tablespace should be created to contain audit\n data. Ensure that adequate space is allocated to that tablespace.\"\n tag \"fix\": \"Allocate sufficient disk space for file-based audit.\n\n Ensure that audit tables are in their own tablespaces and that the tablespaces\n have enough room for the volume of log data that will be produced.\"\n describe 'A manual review is required to ensure the DBMS has allocated audit record storage capacity' do\n skip 'A manual review is required to ensure the DBMS has allocated audit record storage capacity'\n end\nend\n", + "code": " control 'V-61545' 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-61615.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61545.rb", "line": 1 }, - "id": "V-61615" + "id": "V-61545" }, { - "title": "Plans and procedures for testing DBMS installations, upgrades and\n patches must be defined and followed prior to production implementation.", - "desc": "Updates and patches to existing software have the intention of\n improving the security or enhancing or adding features to the product. However,\n it is unfortunately common that updates or patches can render production\n systems inoperable or even introduce serious vulnerabilities. Some updates also\n set security configurations back to unacceptable settings that do not meet\n security requirements. For these reasons, it is a good practice to test updates\n and patches offline before introducing them in a production environment.", + "title": "Procedures for establishing temporary passwords that meet DoD password\n requirements for new accounts must be defined, documented, and implemented.", + "desc": "Password maximum lifetime is the maximum period of time, (typically\n in days) a user's password may be in effect before the user is forced to change\n it.\n\n Passwords need to be changed at specific policy-based intervals as per\n policy. Any password, no matter how complex, can eventually be cracked.\n\n One method of minimizing this risk is to use complex passwords and\n periodically change them. If the application does not limit the lifetime of\n passwords and force users to change their passwords, there is the risk that the\n system and/or application passwords could be compromised.\n\n New accounts authenticated by passwords that are created without a password\n or with an easily guessed password are vulnerable to unauthorized access.\n Procedures for creating new accounts with passwords should include the required\n assignment of a temporary password to be modified by the user upon first use.\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 With respect to Oracle, this requirement applies to cases\n where it is necessary to have accounts directly managed by Oracle.", "descriptions": { - "default": "Updates and patches to existing software have the intention of\n improving the security or enhancing or adding features to the product. However,\n it is unfortunately common that updates or patches can render production\n systems inoperable or even introduce serious vulnerabilities. Some updates also\n set security configurations back to unacceptable settings that do not meet\n security requirements. For these reasons, it is a good practice to test updates\n and patches offline before introducing them in a production environment." + "default": "Password maximum lifetime is the maximum period of time, (typically\n in days) a user's password may be in effect before the user is forced to change\n it.\n\n Passwords need to be changed at specific policy-based intervals as per\n policy. Any password, no matter how complex, can eventually be cracked.\n\n One method of minimizing this risk is to use complex passwords and\n periodically change them. If the application does not limit the lifetime of\n passwords and force users to change their passwords, there is the risk that the\n system and/or application passwords could be compromised.\n\n New accounts authenticated by passwords that are created without a password\n or with an easily guessed password are vulnerable to unauthorized access.\n Procedures for creating new accounts with passwords should include the required\n assignment of a temporary password to be modified by the user upon first use.\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 With respect to Oracle, this requirement applies to cases\n where it is necessary to have accounts directly managed by Oracle." }, "impact": 0.5, "refs": [], "tags": { - "gtitle": "SRG-APP-000516-DB-999900", - "gid": "V-61499", - "rid": "SV-75989r1_rule", - "stig_id": "O121-BP-024700", - "fix_id": "F-67415r1_fix", + "gtitle": "SRG-APP-000174-DB-000077", + "gid": "V-61735", + "rid": "SV-76225r1_rule", + "stig_id": "O121-C2-014900", + "fix_id": "F-67651r1_fix", "cci": [ - "CCI-000366" + "CCI-000199" ], "nist": [ - "CM-6 b", + "IA-5 (1) (d)", "Rev_4" ], "false_negatives": null, @@ -5388,35 +5483,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Review policy and procedures documented or noted in the System\n Security Plan and evidence of implementation for testing DBMS installations,\n upgrades and patches prior to production deployment.\n\n If policy and procedures do not exist or evidence of implementation does not\n exist, this is a finding.", - "fix": "Develop, document and implement procedures for testing DBMS\n installations, upgrades and patches prior to deployment on production systems." + "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 Where accounts are authenticated using passwords, review procedures and\n implementation evidence for creation of temporary passwords.\n\n If the procedures or evidence do not exist or do not enforce passwords to meet\n DoD password requirements, this is a finding.", + "fix": "Implement procedures for assigning temporary passwords to user\n accounts.\n\n Procedures should include instructions to meet current DoD password length and\n complexity requirements and provide a secure method to relay the temporary\n password to the user." }, - "code": "control 'V-61499' do\n title \"Plans and procedures for testing DBMS installations, upgrades and\n patches must be defined and followed prior to production implementation.\"\n desc \"Updates and patches to existing software have the intention of\n improving the security or enhancing or adding features to the product. However,\n it is unfortunately common that updates or patches can render production\n systems inoperable or even introduce serious vulnerabilities. Some updates also\n set security configurations back to unacceptable settings that do not meet\n security requirements. For these reasons, it is a good practice to test updates\n and patches offline before introducing them in a production environment.\"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000516-DB-999900'\n tag \"gid\": 'V-61499'\n tag \"rid\": 'SV-75989r1_rule'\n tag \"stig_id\": 'O121-BP-024700'\n tag \"fix_id\": 'F-67415r1_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 and evidence of implementation for testing DBMS installations,\n upgrades and patches prior to production deployment.\n\n If policy and procedures do not exist or evidence of implementation does not\n exist, this is a finding.\"\n tag \"fix\": \"Develop, document and implement procedures for testing DBMS\n installations, upgrades and patches prior to deployment on production systems.\"\n describe 'A manual review is required to ensure plans and procedures for testing DBMS installations, upgrades and\n patches are defined and followed prior to production implementation' do\n skip 'A manual review is required to ensure plans and procedures for testing DBMS installations, upgrades and\n patches are defined and followed prior to production implementation'\n end\nend\n", + "code": "control 'V-61735' do\n title \"Procedures for establishing temporary passwords that meet DoD password\n requirements for new accounts must be defined, documented, and implemented.\"\n desc \"Password maximum lifetime is the maximum period of time, (typically\n in days) a user's password may be in effect before the user is forced to change\n it.\n\n Passwords need to be changed at specific policy-based intervals as per\n policy. Any password, no matter how complex, can eventually be cracked.\n\n One method of minimizing this risk is to use complex passwords and\n periodically change them. If the application does not limit the lifetime of\n passwords and force users to change their passwords, there is the risk that the\n system and/or application passwords could be compromised.\n\n New accounts authenticated by passwords that are created without a password\n or with an easily guessed password are vulnerable to unauthorized access.\n Procedures for creating new accounts with passwords should include the required\n assignment of a temporary password to be modified by the user upon first use.\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 With respect to Oracle, this requirement applies to cases\n where it is necessary to have accounts directly managed by Oracle.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000174-DB-000077'\n tag \"gid\": 'V-61735'\n tag \"rid\": 'SV-76225r1_rule'\n tag \"stig_id\": 'O121-C2-014900'\n tag \"fix_id\": 'F-67651r1_fix'\n tag \"cci\": ['CCI-000199']\n tag \"nist\": ['IA-5 (1) (d)', '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 Where accounts are authenticated using passwords, review procedures and\n implementation evidence for creation of temporary passwords.\n\n If the procedures or evidence do not exist or do not enforce passwords to meet\n DoD password requirements, this is a finding.\"\n tag \"fix\": \"Implement procedures for assigning temporary passwords to user\n accounts.\n\n Procedures should include instructions to meet current DoD password length and\n complexity requirements and provide a secure method to relay the temporary\n password to the user.\"\n describe 'A manual review is required to ensure procedures for establishing temporary passwords that meet DoD password\n requirements for new accounts are defined, documented, and implemented' do\n skip 'A manual review is required to ensure procedures for establishing temporary passwords that meet DoD password\n requirements for new accounts are defined, documented, and implemented'\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61499.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61735.rb", "line": 1 }, - "id": "V-61499" + "id": "V-61735" }, { - "title": "The DBMS must limit the use of resources by priority and not impede\n the host from servicing processes designated as a higher-priority.", - "desc": "Priority protection helps prevent a lower-priority process from\n delaying or interfering with the information system servicing any\n higher-priority process. This control does not apply to components in the\n information system for which there is only a single user/role. The application\n must limit the use of resources by priority.\n\n The DBMS is often running queries for multiple users. If lower-priority\n processes are utilizing a disproportionately high amount of database resources,\n this can severely impact higher-priority processes.", + "title": "The DBMS host platform and other dependent applications must be\n configured in compliance with applicable STIG requirements.", + "desc": "The security of the data stored in the DBMS is also vulnerable to\n attacks against the host platform, calling applications, and other application\n or optional components.", "descriptions": { - "default": "Priority protection helps prevent a lower-priority process from\n delaying or interfering with the information system servicing any\n higher-priority process. This control does not apply to components in the\n information system for which there is only a single user/role. The application\n must limit the use of resources by priority.\n\n The DBMS is often running queries for multiple users. If lower-priority\n processes are utilizing a disproportionately high amount of database resources,\n this can severely impact higher-priority processes." + "default": "The security of the data stored in the DBMS is also vulnerable to\n attacks against the host platform, calling applications, and other application\n or optional components." }, - "impact": 0.3, + "impact": 0.5, "refs": [], "tags": { - "gtitle": "SRG-APP-000248-DB-000135", - "gid": "V-61819", - "rid": "SV-76309r2_rule", - "stig_id": "O121-C3-019400", - "fix_id": "F-67735r5_fix", + "gtitle": "SRG-APP-000516-DB-999900", + "gid": "V-61491", + "rid": "SV-75981r1_rule", + "stig_id": "O121-BP-024300", + "fix_id": "F-67407r1_fix", "cci": [ - "CCI-002394" + "CCI-000366" ], "nist": [ - "SC-6", + "CM-6 b", "Rev_4" ], "false_negatives": null, @@ -5429,35 +5524,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Review DBMS settings and documentation to determine if the DBMS\n restricts resource usage by priority.\n\n If the DBMS does not restrict resource usage by priority, this is a finding.\n\n - - - - -\n This capability is available in Oracle at both the user and database level.\n\n At the user level, we create resource profiles for users of the database.\n\n Resource Parameters\n SESSIONS_PER_USER - Specify the number of concurrent sessions to which to limit\n the user.\n CPU_PER_SESSION - Specify the CPU time limit for a session, expressed in\n hundredths of seconds.\n CPU_PER_CALL - Specify the CPU time limit for a call (a parse, execute, or\n fetch), expressed in hundredths of seconds.\n CONNECT_TIME - Specify the total elapsed time limit for a session, expressed in\n minutes.\n IDLE_TIME - Specify the permitted periods of continuous inactive time during a\n session, expressed in minutes. Long-running queries and other operations are\n not subject to this limit.\n LOGICAL_READS_PER_SESSION - Specify the permitted number of data blocks read in\n a session, including blocks read from memory and disk.\n LOGICAL_READS_PER_CALL - Specify the permitted number of data blocks read for a\n call to process a SQL statement (a parse, execute, or fetch).\n PRIVATE_SGA - Specify the amount of private space a session can allocate in the\n shared pool of the system global area (SGA).\n COMPOSITE_LIMIT - Specify the total resource cost for a session, expressed in\n service units.\n\n To check the resource controls assigned to a user, query the DBA_PROFILES and\n DBA_USERS tables in the following manner.\n\n set linesize 121\n col username format a20\n col profile format a20\n col resource_name format a25\n col resource_type format a14\n col limit format a10\n select a.username,\n a.profile,\n b.resource_name,\n b.limit\n from dba_users a,\n dba_profiles b\n where b.resource_type is not null and\n a.profile = b.profile order by username;\n\n The output should look like the output below and display the users and the\n contents of their profiles.\n\n USERNAME PROFILE RESOURCE NAME LIMIT\n -------- ------- ------------- -----\n SCOTT DEFAULT SESSIONS_PER_USER UNLIMITED\n SCOTT DEFAULT CPU_PER_SESSION UNLIMITED", - "fix": "Implement measures to restrict the usage of resources by priority.\n\n - - - - -\n To implement security at the user level, assign users a profile that limits\n their resources:\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 Example\n\n $ sqlplus connect as sysdba\n\n ALTER PROFILE ORA_STIG_PROFILE LIMIT\n SESSIONS_PER_USER 1\n IDLE_TIME 30\n CPU_PER_SESSION 100\n CPU_PER_CALL 100\n CONNECT_TIME 600;" + "check": "If the DBMS host being reviewed is not a production DBMS host,\n this check is not a finding.\n\n Review evidence of security hardening and auditing of the DBMS host platform\n with the ISSO.\n\n If the DBMS host platform has not been hardened and received a security audit,\n this is a finding.\n\n Review evidence of security hardening and auditing for all application(s) that\n store data in the database and all other separately configured components that\n access the database including web servers, application servers, report servers,\n etc.\n\n If any have not been hardened and received a security audit, this is a finding.\n\n Review evidence of security hardening and auditing for all application(s)\n installed on the local DBMS host where security hardening and auditing guidance\n exists.\n\n If any have not been hardened and received a security audit, this is a finding.", + "fix": "Configure all related application components and the DBMS host\n platform in accordance with the applicable DoD STIG.\n\n Regularly audit the security configuration of related applications and the host\n platform to confirm continued compliance with security requirements." }, - "code": "control 'V-61819' do\n title \"The DBMS must limit the use of resources by priority and not impede\n the host from servicing processes designated as a higher-priority.\"\n desc \"Priority protection helps prevent a lower-priority process from\n delaying or interfering with the information system servicing any\n higher-priority process. This control does not apply to components in the\n information system for which there is only a single user/role. The application\n must limit the use of resources by priority.\n\n The DBMS is often running queries for multiple users. If lower-priority\n processes are utilizing a disproportionately high amount of database resources,\n this can severely impact higher-priority processes.\n \"\n impact 0.3\n tag \"gtitle\": 'SRG-APP-000248-DB-000135'\n tag \"gid\": 'V-61819'\n tag \"rid\": 'SV-76309r2_rule'\n tag \"stig_id\": 'O121-C3-019400'\n tag \"fix_id\": 'F-67735r5_fix'\n tag \"cci\": ['CCI-002394']\n tag \"nist\": ['SC-6', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Review DBMS settings and documentation to determine if the DBMS\n restricts resource usage by priority.\n\n If the DBMS does not restrict resource usage by priority, this is a finding.\n\n - - - - -\n This capability is available in Oracle at both the user and database level.\n\n At the user level, we create resource profiles for users of the database.\n\n Resource Parameters\n SESSIONS_PER_USER - Specify the number of concurrent sessions to which to limit\n the user.\n CPU_PER_SESSION - Specify the CPU time limit for a session, expressed in\n hundredths of seconds.\n CPU_PER_CALL - Specify the CPU time limit for a call (a parse, execute, or\n fetch), expressed in hundredths of seconds.\n CONNECT_TIME - Specify the total elapsed time limit for a session, expressed in\n minutes.\n IDLE_TIME - Specify the permitted periods of continuous inactive time during a\n session, expressed in minutes. Long-running queries and other operations are\n not subject to this limit.\n LOGICAL_READS_PER_SESSION - Specify the permitted number of data blocks read in\n a session, including blocks read from memory and disk.\n LOGICAL_READS_PER_CALL - Specify the permitted number of data blocks read for a\n call to process a SQL statement (a parse, execute, or fetch).\n PRIVATE_SGA - Specify the amount of private space a session can allocate in the\n shared pool of the system global area (SGA).\n COMPOSITE_LIMIT - Specify the total resource cost for a session, expressed in\n service units.\n\n To check the resource controls assigned to a user, query the DBA_PROFILES and\n DBA_USERS tables in the following manner.\n\n set linesize 121\n col username format a20\n col profile format a20\n col resource_name format a25\n col resource_type format a14\n col limit format a10\n select a.username,\n a.profile,\n b.resource_name,\n b.limit\n from dba_users a,\n dba_profiles b\n where b.resource_type is not null and\n a.profile = b.profile order by username;\n\n The output should look like the output below and display the users and the\n contents of their profiles.\n\n USERNAME PROFILE RESOURCE NAME LIMIT\n -------- ------- ------------- -----\n SCOTT DEFAULT SESSIONS_PER_USER UNLIMITED\n SCOTT DEFAULT CPU_PER_SESSION UNLIMITED\"\n tag \"fix\": \"Implement measures to restrict the usage of resources by priority.\n\n - - - - -\n To implement security at the user level, assign users a profile that limits\n their resources:\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 Example\n\n $ sqlplus connect as sysdba\n\n ALTER PROFILE ORA_STIG_PROFILE LIMIT\n SESSIONS_PER_USER 1\n IDLE_TIME 30\n CPU_PER_SESSION 100\n CPU_PER_CALL 100\n CONNECT_TIME 600;\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n limit = sql.query(\"select\n DISTINCT b.limit\n from dba_users a,\n dba_profiles b\n where b.resource_type is not null and\n a.profile = b.profile;\").column('limit')\n\n describe 'The oracle database user limit' do\n subject { limit }\n it { should_not include 'UNLIMITED' }\n end\nend\n", + "code": "control 'V-61491' do\n title \"The DBMS host platform and other dependent applications must be\n configured in compliance with applicable STIG requirements.\"\n desc \"The security of the data stored in the DBMS is also vulnerable to\n attacks against the host platform, calling applications, and other application\n or optional components.\"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000516-DB-999900'\n tag \"gid\": 'V-61491'\n tag \"rid\": 'SV-75981r1_rule'\n tag \"stig_id\": 'O121-BP-024300'\n tag \"fix_id\": 'F-67407r1_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 host being reviewed is not a production DBMS host,\n this check is not a finding.\n\n Review evidence of security hardening and auditing of the DBMS host platform\n with the ISSO.\n\n If the DBMS host platform has not been hardened and received a security audit,\n this is a finding.\n\n Review evidence of security hardening and auditing for all application(s) that\n store data in the database and all other separately configured components that\n access the database including web servers, application servers, report servers,\n etc.\n\n If any have not been hardened and received a security audit, this is a finding.\n\n Review evidence of security hardening and auditing for all application(s)\n installed on the local DBMS host where security hardening and auditing guidance\n exists.\n\n If any have not been hardened and received a security audit, this is a finding.\"\n tag \"fix\": \"Configure all related application components and the DBMS host\n platform in accordance with the applicable DoD STIG.\n\n Regularly audit the security configuration of related applications and the host\n platform to confirm continued compliance with security requirements.\"\n describe 'A manual review is required to ensure the DBMS host platform and other dependent applications are\n configured in compliance with applicable STIG requirements' do\n skip 'A manual review is required to ensure the DBMS host platform and other dependent applications are\n configured in compliance with applicable STIG requirements'\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61819.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61491.rb", "line": 1 }, - "id": "V-61819" + "id": "V-61491" }, { - "title": "DBMS default accounts must be assigned custom passwords.", - "desc": "Password maximum lifetime is the maximum period of time, (typically\nin days) a user's password may be in effect before the user is forced to change\nit.\n\n Passwords need to be changed at specific policy-based intervals as per\npolicy. Any password, no matter how complex, can eventually be cracked.\n\n One method of minimizing this risk is to use complex passwords and\nperiodically change them. If the application does not limit the lifetime of\npasswords and force users to change their passwords, there is the risk that the\nsystem and/or application passwords could be compromised.\n\n DBMS default passwords provide a commonly known and exploited means for\nunauthorized access to database installations.", + "title": "The DBMS must support taking organization-defined list of least\n disruptive actions to terminate suspicious events.", + "desc": "System availability is a key tenet of system security. Organizations\n need to have the flexibility to be able to define the automated actions taken\n in response to an identified incident. This includes being able to define a\n least disruptive action the application takes to terminate suspicious events. A\n least disruptive action may include initiating a request for human response\n rather than blocking traffic or disrupting system operation.\n\n In order to preserve availability, it is important for the DBMS to\n terminate suspicious events with the least disruptive action possible. If\n suspicious events are not terminated, an attacker may gain entry into the\n system; however, if the system overreacts to a suspicious event and takes an\n overly disruptive action, a Denial of Service (DoS) may occur.", "descriptions": { - "default": "Password maximum lifetime is the maximum period of time, (typically\nin days) a user's password may be in effect before the user is forced to change\nit.\n\n Passwords need to be changed at specific policy-based intervals as per\npolicy. Any password, no matter how complex, can eventually be cracked.\n\n One method of minimizing this risk is to use complex passwords and\nperiodically change them. If the application does not limit the lifetime of\npasswords and force users to change their passwords, there is the risk that the\nsystem and/or application passwords could be compromised.\n\n DBMS default passwords provide a commonly known and exploited means for\nunauthorized access to database installations." + "default": "System availability is a key tenet of system security. Organizations\n need to have the flexibility to be able to define the automated actions taken\n in response to an identified incident. This includes being able to define a\n least disruptive action the application takes to terminate suspicious events. A\n least disruptive action may include initiating a request for human response\n rather than blocking traffic or disrupting system operation.\n\n In order to preserve availability, it is important for the DBMS to\n terminate suspicious events with the least disruptive action possible. If\n suspicious events are not terminated, an attacker may gain entry into the\n system; however, if the system overreacts to a suspicious event and takes an\n overly disruptive action, a Denial of Service (DoS) may occur." }, - "impact": 0.7, + "impact": 0.5, "refs": [], "tags": { - "gtitle": "SRG-APP-000174-DB-000078", - "gid": "V-61541", - "rid": "SV-76031r1_rule", - "stig_id": "O121-C1-015000", - "fix_id": "F-67457r1_fix", + "gtitle": "SRG-APP-000287-DB-000126", + "gid": "V-61795", + "rid": "SV-76285r1_rule", + "stig_id": "O121-C2-020300", + "fix_id": "F-67711r1_fix", "cci": [ - "CCI-000199" + "CCI-001670" ], "nist": [ - "IA-5 (1) (d)", + "SI-4 (7)", "Rev_4" ], "false_negatives": null, @@ -5470,15 +5565,15 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Use this query to identify the Oracle-supplied accounts that\n still have their default passwords:\n SELECT * FROM SYS.DBA_USERS_WITH_DEFPWD;\n\n If any accounts other than XS$NULL are listed, this is a finding.\n\n (XS$NULL is an internal account that represents the absence of a user in a\n session. Because XS$NULL is not a user, this account can only be accessed by\n the Oracle Database instance. XS$NULL has no privileges and no one can\n authenticate as XS$NULL, nor can authentication credentials ever be assigned to\n XS$NULL.)", - "fix": "Change passwords for DBMS accounts to non-default values. Where\n necessary, unlock or enable accounts to change the password, and then return\n the account to disabled or locked status." + "check": "Obtain the CC/S/A/FA's list of suspicious event types and the\n actions to be taken in response, ordered from least disruptive to last resort.\n\n If the list does not exist, this is a finding.\n\n For each event type in the list, review the measures in place in the\n DBMS/database configuration that are designed to detect and/or counter the\n event. (Alerting an administrator or operator to the problem is a valid\n measure.)\n\n If, for any event type defined in the list, no means of detecting the event\n exists, this is a finding.\n\n For each event type where an automatic countermeasure is defined, verify that\n its implementation is congruent with the list of defined actions. If not, this\n is a finding.\n\n Verify that administrators/operators are familiar with the list and the\n notification mechanism and are equipped to follow the instructions in the list.\n If not, this is a finding.", + "fix": "If the list does not exist, create it.\n\n For any event type defined in the list where no means of detecting the event\n exists, either create the means of detection or modify the list.\n\n For each event type where an automatic countermeasure is defined but its\n implementation differs from its description in the list, either modify the\n countermeasure or amend the list.\n\n If any administrators/operators are unfamiliar with the list or the\n notification mechanism, train them.\n\n If any administrators/operators are not equipped to follow the instructions in\n the list, provide them with the means to do so.\n\n Ensure the list is incorporated into, or referenced by, the System Security\n Plan.\n\n Note that Oracle Audit Vault and Oracle Database Vault are optional products\n that can be of considerable use in implementing active protection measures of\n this kind." }, - "code": "control 'V-61541' do\n title 'DBMS default accounts must be assigned custom passwords.'\n desc \"Password maximum lifetime is the maximum period of time, (typically\nin days) a user's password may be in effect before the user is forced to change\nit.\n\n Passwords need to be changed at specific policy-based intervals as per\npolicy. Any password, no matter how complex, can eventually be cracked.\n\n One method of minimizing this risk is to use complex passwords and\nperiodically change them. If the application does not limit the lifetime of\npasswords and force users to change their passwords, there is the risk that the\nsystem and/or application passwords could be compromised.\n\n DBMS default passwords provide a commonly known and exploited means for\nunauthorized access to database installations.\n \"\n impact 0.7\n tag \"gtitle\": 'SRG-APP-000174-DB-000078'\n tag \"gid\": 'V-61541'\n tag \"rid\": 'SV-76031r1_rule'\n tag \"stig_id\": 'O121-C1-015000'\n tag \"fix_id\": 'F-67457r1_fix'\n tag \"cci\": ['CCI-000199']\n tag \"nist\": ['IA-5 (1) (d)', '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\": \"Use this query to identify the Oracle-supplied accounts that\n still have their default passwords:\n SELECT * FROM SYS.DBA_USERS_WITH_DEFPWD;\n\n If any accounts other than XS$NULL are listed, this is a finding.\n\n (XS$NULL is an internal account that represents the absence of a user in a\n session. Because XS$NULL is not a user, this account can only be accessed by\n the Oracle Database instance. XS$NULL has no privileges and no one can\n authenticate as XS$NULL, nor can authentication credentials ever be assigned to\n XS$NULL.)\"\n tag \"fix\": \"Change passwords for DBMS accounts to non-default values. Where\n necessary, unlock or enable accounts to change the password, and then return\n the account to disabled or locked status.\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n sys_dba_users_with_defpwd = sql.query(' SELECT username FROM SYS.DBA_USERS_WITH_DEFPWD;').column('username').uniq\n\n describe.one do\n sys_dba_users_with_defpwd.each do |user|\n describe \"The oracle system database user: #{user} with a default password\" do\n subject { user }\n it { should cmp 'XS$NULL' }\n end\n end\n \n describe sys_dba_users_with_defpwd do\n it { should be_empty }\n end\n end\nend\n", + "code": "control 'V-61795' do\n title \"The DBMS must support taking organization-defined list of least\n disruptive actions to terminate suspicious events.\"\n desc \"System availability is a key tenet of system security. Organizations\n need to have the flexibility to be able to define the automated actions taken\n in response to an identified incident. This includes being able to define a\n least disruptive action the application takes to terminate suspicious events. A\n least disruptive action may include initiating a request for human response\n rather than blocking traffic or disrupting system operation.\n\n In order to preserve availability, it is important for the DBMS to\n terminate suspicious events with the least disruptive action possible. If\n suspicious events are not terminated, an attacker may gain entry into the\n system; however, if the system overreacts to a suspicious event and takes an\n overly disruptive action, a Denial of Service (DoS) may occur.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000287-DB-000126'\n tag \"gid\": 'V-61795'\n tag \"rid\": 'SV-76285r1_rule'\n tag \"stig_id\": 'O121-C2-020300'\n tag \"fix_id\": 'F-67711r1_fix'\n tag \"cci\": ['CCI-001670']\n tag \"nist\": ['SI-4 (7)', '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\": \"Obtain the CC/S/A/FA's list of suspicious event types and the\n actions to be taken in response, ordered from least disruptive to last resort.\n\n If the list does not exist, this is a finding.\n\n For each event type in the list, review the measures in place in the\n DBMS/database configuration that are designed to detect and/or counter the\n event. (Alerting an administrator or operator to the problem is a valid\n measure.)\n\n If, for any event type defined in the list, no means of detecting the event\n exists, this is a finding.\n\n For each event type where an automatic countermeasure is defined, verify that\n its implementation is congruent with the list of defined actions. If not, this\n is a finding.\n\n Verify that administrators/operators are familiar with the list and the\n notification mechanism and are equipped to follow the instructions in the list.\n If not, this is a finding.\"\n tag \"fix\": \"If the list does not exist, create it.\n\n For any event type defined in the list where no means of detecting the event\n exists, either create the means of detection or modify the list.\n\n For each event type where an automatic countermeasure is defined but its\n implementation differs from its description in the list, either modify the\n countermeasure or amend the list.\n\n If any administrators/operators are unfamiliar with the list or the\n notification mechanism, train them.\n\n If any administrators/operators are not equipped to follow the instructions in\n the list, provide them with the means to do so.\n\n Ensure the list is incorporated into, or referenced by, the System Security\n Plan.\n\n Note that Oracle Audit Vault and Oracle Database Vault are optional products\n that can be of considerable use in implementing active protection measures of\n this kind.\"\n describe 'A manual review is required to ensure the DBMS supports taking organization-defined list of least\n disruptive actions to terminate suspicious events.' do\n skip 'A manual review is required to ensure the DBMS supports taking organization-defined list of least\n disruptive actions to terminate suspicious events.'\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61541.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61795.rb", "line": 1 }, - "id": "V-61541" + "id": "V-61795" }, { "title": "The DBMS must manage resources to limit the effects of information\n flooding types of Denial of Service (DoS) incidents.", @@ -5522,24 +5617,24 @@ "id": "V-61817" }, { - "title": "The DBMS must generate audit records for the DoD-selected list of\n auditable events, to the extent such information is available.", - "desc": "Audit records can be generated from various components within the\n information system, such as network interfaces, hard disks, modems, etc. From\n an application perspective, certain specific application functionalities may be\n audited, as well.\n\n The list of audited events is the set of events for which audits are to be\n generated. This set of events is typically a subset of the list of all events\n for which the system is capable of generating audit records (i.e., auditable\n events, timestamps, source and destination addresses, user/process identifiers,\n event descriptions, success/fail indications, file names involved, and access\n control or flow control rules invoked).\n\n Organizations may define the organizational personnel accountable for\n determining which application components shall provide auditable events.\n\n Auditing provides accountability for changes made to the DBMS configuration\n or its objects and data. It provides a means to discover suspicious activity\n and unauthorized changes. Without auditing, a compromise may go undetected and\n without a means to determine accountability.\n\n The Department of Defense has established the following as the minimum set\n of auditable events. Most can be audited via Oracle settings; some - marked\n here with an asterisk - cannot, and may require OS settings.\n - Successful and unsuccessful attempts to access, modify, or delete\n privileges, security objects, security levels, or categories of information\n (e.g. classification levels).\n - Successful and unsuccessful logon attempts, privileged activities or\n other system level access\n - Starting and ending time for user access to the system, concurrent logons\n from different workstations.\n - Successful and unsuccessful accesses to objects.\n - All program initiations.\n - *All direct access to the information system.\n - All account creations, modifications, disabling, and terminations.\n - *All kernel module loads, unloads, and restarts.", + "title": "The system must protect audit tools from unauthorized access.", + "desc": "Protecting audit data also includes identifying and protecting the\n tools used to view and manipulate log data.\n\n Depending upon the log format and application, system and application log\n tools may provide the only means to manipulate and manage application and\n system log data. It is, therefore, imperative that access to audit tools be\n controlled and protected from unauthorized access.\n\n Applications providing tools to interface with audit data will leverage\n user permissions and roles identifying the user accessing the tools and the\n corresponding rights the user enjoys in order make access decisions regarding\n the access to audit tools.\n\n Audit tools include, but are not limited to, OS-provided audit tools,\n vendor-provided audit tools, and open source audit tools needed to successfully\n view and manipulate audit information system activity and records.\n\n If an attacker were to gain access to audit tools, he could analyze audit\n logs for system weaknesses or weaknesses in the auditing itself. An attacker\n could also manipulate logs to hide evidence of malicious activity.", "descriptions": { - "default": "Audit records can be generated from various components within the\n information system, such as network interfaces, hard disks, modems, etc. From\n an application perspective, certain specific application functionalities may be\n audited, as well.\n\n The list of audited events is the set of events for which audits are to be\n generated. This set of events is typically a subset of the list of all events\n for which the system is capable of generating audit records (i.e., auditable\n events, timestamps, source and destination addresses, user/process identifiers,\n event descriptions, success/fail indications, file names involved, and access\n control or flow control rules invoked).\n\n Organizations may define the organizational personnel accountable for\n determining which application components shall provide auditable events.\n\n Auditing provides accountability for changes made to the DBMS configuration\n or its objects and data. It provides a means to discover suspicious activity\n and unauthorized changes. Without auditing, a compromise may go undetected and\n without a means to determine accountability.\n\n The Department of Defense has established the following as the minimum set\n of auditable events. Most can be audited via Oracle settings; some - marked\n here with an asterisk - cannot, and may require OS settings.\n - Successful and unsuccessful attempts to access, modify, or delete\n privileges, security objects, security levels, or categories of information\n (e.g. classification levels).\n - Successful and unsuccessful logon attempts, privileged activities or\n other system level access\n - Starting and ending time for user access to the system, concurrent logons\n from different workstations.\n - Successful and unsuccessful accesses to objects.\n - All program initiations.\n - *All direct access to the information system.\n - All account creations, modifications, disabling, and terminations.\n - *All kernel module loads, unloads, and restarts." + "default": "Protecting audit data also includes identifying and protecting the\n tools used to view and manipulate log data.\n\n Depending upon the log format and application, system and application log\n tools may provide the only means to manipulate and manage application and\n system log data. It is, therefore, imperative that access to audit tools be\n controlled and protected from unauthorized access.\n\n Applications providing tools to interface with audit data will leverage\n user permissions and roles identifying the user accessing the tools and the\n corresponding rights the user enjoys in order make access decisions regarding\n the access to audit tools.\n\n Audit tools include, but are not limited to, OS-provided audit tools,\n vendor-provided audit tools, and open source audit tools needed to successfully\n view and manipulate audit information system activity and records.\n\n If an attacker were to gain access to audit tools, he could analyze audit\n logs for system weaknesses or weaknesses in the auditing itself. An attacker\n could also manipulate logs to hide evidence of malicious activity." }, - "impact": 0.5, + "impact": 0, "refs": [], "tags": { - "gtitle": "SRG-APP-000091-DB-000066", - "gid": "V-61625", - "rid": "SV-76115r3_rule", - "stig_id": "O121-C2-007000", - "fix_id": "F-67541r1_fix", + "gtitle": "SRG-APP-000121-DB-000202", + "gid": "V-61659", + "rid": "SV-76149r1_rule", + "stig_id": "O121-C2-009600", + "fix_id": "F-67573r1_fix", "cci": [ - "CCI-000172" + "CCI-001493" ], "nist": [ - "AU-12 c", + "AU-9", "Rev_4" ], "false_negatives": null, @@ -5552,80 +5647,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Check DBMS settings to determine if auditing is being performed\n on the events on the DoD-selected list of auditable events that lie within the\n scope of Oracle audit capabilities:\n - Successful and unsuccessful attempts to access, modify, or delete privileges,\n security objects, security levels, or categories of information (e.g.,\n classification levels).\n - Successful and unsuccessful logon attempts, privileged activities or other\n system-level access\n - Starting and ending time for user access to the system, concurrent logons\n from different workstations.\n - Successful and unsuccessful accesses to objects.\n - All program initiations.\n - All account creations, modifications, disabling, and terminations.\n\n If auditing is not being performed for any of these events, this is a finding.\n\n Notes on Oracle audit capabilities follow.\n\n Unified Audit supports named audit policies, which are defined using the CREATE\n AUDIT POLICY statement. A policy specifies the actions that should be audited\n and the objects to which it should apply. If no specific objects are included\n in the policy definition, it applies to all objects.\n\n A named policy is enabled using the AUDIT POLICY statement. It can be enabled\n for all users, for specific users only, or for all except a specified list of\n users. The policy can audit successful actions, unsuccessful actions, or both.\n\n Verifying existing audit policy: existing Unified Audit policies are listed in\n the view AUDIT_UNIFIED_POLICIES. The AUDIT_OPTION column contains one of the\n actions specified in a CREATE AUDIT POLICY statement. The AUDIT_OPTION_TYPE\n column contains 'STANDARD ACTION' for a policy that applies to all objects or\n 'OBJECT ACTION' for a policy that audits actions on a specific object.\n\n select POLICY_NAME from SYS.AUDIT_UNIFIED_POLICIES where AUDIT_OPTION='GRANT'\n and AUDIT_OPTION_TYPE='STANDARD ACTION';\n\n To find policies that audit privilege grants on specific objects:\n\n select POLICY_NAME,OBJECT_SCHEMA,OBJECT_NAME from SYS.AUDIT_UNIFIED_POLICIES\n where AUDIT_OPTION='GRANT' and AUDIT_OPTION_TYPE='OBJECT ACTION';\n\n The view AUDIT_UNIFIED_ENABLED_POLICIES shows which Unified Audit policies are\n enabled. The ENABLED_OPT and USER_NAME columns show the users for whom the\n policy is enabled or 'ALL USERS'. The SUCCESS and FAILURE columns indicate if\n the policy is enabled for successful or unsuccessful actions, respectively.\n\n select POLICY_NAME,ENABLED_OPT,USER_NAME,SUCCESS,FAILURE from\n SYS.AUDIT_UNIFIED_ENABLED_POLICIES where POLICY_NAME='POLICY1';", - "fix": "Configure the DBMS's auditing settings to include auditing of\n events on the DoD-selected list of auditable events.\n\n 1) Successful and unsuccessful attempts to access, modify, or delete\n privileges, security objects, security levels, or categories of information\n (e.g., classification levels)\n\n To audit granting and revocation of any privilege:\n create audit policy policy1 actions grant;\n create audit policy policy2 actions revoke;\n\n To audit grants of object privileges on a specific object:\n create audit policy policy3 actions grant on .;\n\n If Oracle Label Security is enabled, this will audit all OLS administrative\n actions:\n create audit policy policy4 actions component = OLS all;\n\n 2) Successful and unsuccessful logon attempts, privileged activities or other\n system-level access\n\n To audit all user logon attempts:\n create audit policy policy5 actions logon;\n\n To audit only logon attempts using administrative privileges (e.g. AS SYSDBA):\n audit policy policy5 by SYS, SYSOPER, SYSBACKUP, SYSDG, SYSKM;\n\n 3) Starting and ending time for user access to the system, concurrent logons\n from different workstations\n\n This policy will audit all logon and logoff events. An individual session is\n identified in the UNIFIED_AUDIT_TRAIL by the tuple (DBID, INSTANCE_ID,\n SESSIONID) and the start and end time will be indicated by the EVENT_TIMESTAMP\n of the logon and logoff events:\n create audit policy policy6 actions logon, logoff;\n\n 4) Successful and unsuccessful accesses to objects\n\n To audit all accesses to a specific table:\n create audit policy policy7 actions select, insert, delete, alter on\n .;\n\n Different actions are defined for other object types. To audit all supported\n actions on a specific object:\n create audit policy policy8 actions all on .;\n\n 5) All program initiations\n\n To audit execution of any PL/SQL program unit:\n create audit policy policy9 actions EXECUTE;\n\n To audit execution of a specific function, procedure, or package:\n create audit policy policy10 actions EXECUTE on .;\n\n 6) All direct access to the information system\n\n [Not applicable to Database audit. Monitor using OS auditing.]\n\n 7) All account creations, modifications, disabling, and terminations\n\n To audit all user administration actions:\n create audit policy policy11 actions create user, alter user, drop user, change\n password;\n\n 8) All kernel module loads, unloads, and restarts\n\n [Not applicable to Database audit. Monitor using OS auditing.]\n\n 9) All database parameter changes\n\n To audit any database parameter changes, dynamic or static:\n create audit policy policy12 actions alter database, alter system, create\n spfile;\n\n Applying the Policy\n\n The following command will enable the policy in all database sessions and audit\n both successful and unsuccessful actions:\n audit policy policy1;\n\n To audit only unsuccessful actions, add the WHENEVER NOT SUCCESSFUL modifier:\n audit policy policy1 whenever not successful;\n\n Either command above can be limited to only database sessions started by a\n specific user as follows:\n audit policy policy1 by ;\n audit policy policy1 by whenever not successful;" + "check": "Review access permissions to tools used to view or modify audit\n log data. These tools may include the DBMS itself or tools external to the\n database.\n\n If appropriate permissions and access controls to prevent unauthorized access\n are not applied to these tools, this is a finding.", + "fix": "Add or modify access controls and permissions to tools used to\n view or modify audit log data. Tools must be accessible by authorized personnel\n only." }, - "code": "control 'V-61625' do\n title \"The DBMS must generate audit records for the DoD-selected list of\n auditable events, to the extent such information is available.\"\n desc \"Audit records can be generated from various components within the\n information system, such as network interfaces, hard disks, modems, etc. From\n an application perspective, certain specific application functionalities may be\n audited, as well.\n\n The list of audited events is the set of events for which audits are to be\n generated. This set of events is typically a subset of the list of all events\n for which the system is capable of generating audit records (i.e., auditable\n events, timestamps, source and destination addresses, user/process identifiers,\n event descriptions, success/fail indications, file names involved, and access\n control or flow control rules invoked).\n\n Organizations may define the organizational personnel accountable for\n determining which application components shall provide auditable events.\n\n Auditing provides accountability for changes made to the DBMS configuration\n or its objects and data. It provides a means to discover suspicious activity\n and unauthorized changes. Without auditing, a compromise may go undetected and\n without a means to determine accountability.\n\n The Department of Defense has established the following as the minimum set\n of auditable events. Most can be audited via Oracle settings; some - marked\n here with an asterisk - cannot, and may require OS settings.\n - Successful and unsuccessful attempts to access, modify, or delete\n privileges, security objects, security levels, or categories of information\n (e.g. classification levels).\n - Successful and unsuccessful logon attempts, privileged activities or\n other system level access\n - Starting and ending time for user access to the system, concurrent logons\n from different workstations.\n - Successful and unsuccessful accesses to objects.\n - All program initiations.\n - *All direct access to the information system.\n - All account creations, modifications, disabling, and terminations.\n - *All kernel module loads, unloads, and restarts.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000091-DB-000066'\n tag \"gid\": 'V-61625'\n tag \"rid\": 'SV-76115r3_rule'\n tag \"stig_id\": 'O121-C2-007000'\n tag \"fix_id\": 'F-67541r1_fix'\n tag \"cci\": ['CCI-000172']\n tag \"nist\": ['AU-12 c', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Check DBMS settings to determine if auditing is being performed\n on the events on the DoD-selected list of auditable events that lie within the\n scope of Oracle audit capabilities:\n - Successful and unsuccessful attempts to access, modify, or delete privileges,\n security objects, security levels, or categories of information (e.g.,\n classification levels).\n - Successful and unsuccessful logon attempts, privileged activities or other\n system-level access\n - Starting and ending time for user access to the system, concurrent logons\n from different workstations.\n - Successful and unsuccessful accesses to objects.\n - All program initiations.\n - All account creations, modifications, disabling, and terminations.\n\n If auditing is not being performed for any of these events, this is a finding.\n\n Notes on Oracle audit capabilities follow.\n\n Unified Audit supports named audit policies, which are defined using the CREATE\n AUDIT POLICY statement. A policy specifies the actions that should be audited\n and the objects to which it should apply. If no specific objects are included\n in the policy definition, it applies to all objects.\n\n A named policy is enabled using the AUDIT POLICY statement. It can be enabled\n for all users, for specific users only, or for all except a specified list of\n users. The policy can audit successful actions, unsuccessful actions, or both.\n\n Verifying existing audit policy: existing Unified Audit policies are listed in\n the view AUDIT_UNIFIED_POLICIES. The AUDIT_OPTION column contains one of the\n actions specified in a CREATE AUDIT POLICY statement. The AUDIT_OPTION_TYPE\n column contains 'STANDARD ACTION' for a policy that applies to all objects or\n 'OBJECT ACTION' for a policy that audits actions on a specific object.\n\n select POLICY_NAME from SYS.AUDIT_UNIFIED_POLICIES where AUDIT_OPTION='GRANT'\n and AUDIT_OPTION_TYPE='STANDARD ACTION';\n\n To find policies that audit privilege grants on specific objects:\n\n select POLICY_NAME,OBJECT_SCHEMA,OBJECT_NAME from SYS.AUDIT_UNIFIED_POLICIES\n where AUDIT_OPTION='GRANT' and AUDIT_OPTION_TYPE='OBJECT ACTION';\n\n The view AUDIT_UNIFIED_ENABLED_POLICIES shows which Unified Audit policies are\n enabled. The ENABLED_OPT and USER_NAME columns show the users for whom the\n policy is enabled or 'ALL USERS'. The SUCCESS and FAILURE columns indicate if\n the policy is enabled for successful or unsuccessful actions, respectively.\n\n select POLICY_NAME,ENABLED_OPT,USER_NAME,SUCCESS,FAILURE from\n SYS.AUDIT_UNIFIED_ENABLED_POLICIES where POLICY_NAME='POLICY1';\"\n tag \"fix\": \"Configure the DBMS's auditing settings to include auditing of\n events on the DoD-selected list of auditable events.\n\n 1) Successful and unsuccessful attempts to access, modify, or delete\n privileges, security objects, security levels, or categories of information\n (e.g., classification levels)\n\n To audit granting and revocation of any privilege:\n create audit policy policy1 actions grant;\n create audit policy policy2 actions revoke;\n\n To audit grants of object privileges on a specific object:\n create audit policy policy3 actions grant on .;\n\n If Oracle Label Security is enabled, this will audit all OLS administrative\n actions:\n create audit policy policy4 actions component = OLS all;\n\n 2) Successful and unsuccessful logon attempts, privileged activities or other\n system-level access\n\n To audit all user logon attempts:\n create audit policy policy5 actions logon;\n\n To audit only logon attempts using administrative privileges (e.g. AS SYSDBA):\n audit policy policy5 by SYS, SYSOPER, SYSBACKUP, SYSDG, SYSKM;\n\n 3) Starting and ending time for user access to the system, concurrent logons\n from different workstations\n\n This policy will audit all logon and logoff events. An individual session is\n identified in the UNIFIED_AUDIT_TRAIL by the tuple (DBID, INSTANCE_ID,\n SESSIONID) and the start and end time will be indicated by the EVENT_TIMESTAMP\n of the logon and logoff events:\n create audit policy policy6 actions logon, logoff;\n\n 4) Successful and unsuccessful accesses to objects\n\n To audit all accesses to a specific table:\n create audit policy policy7 actions select, insert, delete, alter on\n .;\n\n Different actions are defined for other object types. To audit all supported\n actions on a specific object:\n create audit policy policy8 actions all on .;\n\n 5) All program initiations\n\n To audit execution of any PL/SQL program unit:\n create audit policy policy9 actions EXECUTE;\n\n To audit execution of a specific function, procedure, or package:\n create audit policy policy10 actions EXECUTE on .;\n\n 6) All direct access to the information system\n\n [Not applicable to Database audit. Monitor using OS auditing.]\n\n 7) All account creations, modifications, disabling, and terminations\n\n To audit all user administration actions:\n create audit policy policy11 actions create user, alter user, drop user, change\n password;\n\n 8) All kernel module loads, unloads, and restarts\n\n [Not applicable to Database audit. Monitor using OS auditing.]\n\n 9) All database parameter changes\n\n To audit any database parameter changes, dynamic or static:\n create audit policy policy12 actions alter database, alter system, create\n spfile;\n\n Applying the Policy\n\n The following command will enable the policy in all database sessions and audit\n both successful and unsuccessful actions:\n audit policy policy1;\n\n To audit only unsuccessful actions, add the WHENEVER NOT SUCCESSFUL modifier:\n audit policy policy1 whenever not successful;\n\n Either command above can be limited to only database sessions started by a\n specific user as follows:\n audit policy policy1 by ;\n audit policy policy1 by whenever not successful;\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n standard_auditing_used = input('standard_auditing_used')\n unified_auditing_used = input('unified_auditing_used')\n\n describe.one do\n describe 'Standard auditing is in use for audit purposes' do\n subject { standard_auditing_used }\n it { should be true }\n end\n\n describe 'Unified auditing is in use for audit purposes' do\n subject { unified_auditing_used }\n it { should be true }\n end\n end\n\n audit_trail = sql.query(\"select value from v$parameter where name = 'audit_trail';\").column('value')\n audit_policies_auditing_grant_privileges = sql.query(\"select DISTINCT POLICY_NAME from AUDIT_UNIFIED_POLICIES\n where AUDIT_OPTION='GRANT' and AUDIT_OPTION_TYPE='OBJECT ACTION';\").column('policy_name')\n unified_audit_policies_enabled = sql.query('select POLICY_NAME from AUDIT_UNIFIED_ENABLED_POLICIES;').column('policy_name')\n\n if standard_auditing_used\n describe 'The oracle database audit_trail parameter' do\n subject { audit_trail }\n it { should_not cmp 'NONE' }\n end\n end\n\n unified_auditing = sql.query(\"SELECT value FROM V$OPTION WHERE PARAMETER = 'Unified Auditing';\").column('value')\n\n if unified_auditing_used\n describe 'The oracle database unified auditing parameter' do\n subject { unified_auditing }\n it { should_not cmp 'FALSE' }\n end\n\n describe 'The audit policies that audit privilege grants on specific objects' do\n subject { audit_policies_auditing_grant_privileges }\n it { should_not be_empty }\n end\n\n describe 'The list of unified audit policies enabled' do\n subject { unified_audit_policies_enabled }\n it { should_not be_empty }\n end\n\n end\nend\n", + "code": "control 'V-61659' do\n title 'The system must protect audit tools from unauthorized access.'\n desc \"Protecting audit data also includes identifying and protecting the\n tools used to view and manipulate log data.\n\n Depending upon the log format and application, system and application log\n tools may provide the only means to manipulate and manage application and\n system log data. It is, therefore, imperative that access to audit tools be\n controlled and protected from unauthorized access.\n\n Applications providing tools to interface with audit data will leverage\n user permissions and roles identifying the user accessing the tools and the\n corresponding rights the user enjoys in order make access decisions regarding\n the access to audit tools.\n\n Audit tools include, but are not limited to, OS-provided audit tools,\n vendor-provided audit tools, and open source audit tools needed to successfully\n view and manipulate audit information system activity and records.\n\n If an attacker were to gain access to audit tools, he could analyze audit\n logs for system weaknesses or weaknesses in the auditing itself. An attacker\n could also manipulate logs to hide evidence of malicious activity.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000121-DB-000202'\n tag \"gid\": 'V-61659'\n tag \"rid\": 'SV-76149r1_rule'\n tag \"stig_id\": 'O121-C2-009600'\n tag \"fix_id\": 'F-67573r1_fix'\n tag \"cci\": ['CCI-001493']\n tag \"nist\": ['AU-9', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Review access permissions to tools used to view or modify audit\n log data. These tools may include the DBMS itself or tools external to the\n database.\n\n If appropriate permissions and access controls to prevent unauthorized access\n are not applied to these tools, this is a finding.\"\n tag \"fix\": \"Add or modify access controls and permissions to tools used to\n view or modify audit log data. Tools must be accessible by authorized personnel\n only.\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n users_allowed_access_to_audit_info = sql.query(\"SELECT GRANTEE, TABLE_NAME, PRIVILEGE\n FROM DBA_TAB_PRIVS where owner='AUDSYS';\").column('grantee').uniq\n if users_allowed_access_to_audit_info.empty?\n impact 0.0\n describe 'There are no oracle users allowed access to audit information, control N/A' do\n skip 'There are no oracle users allowed access to audit information'\n end\n else\n users_allowed_access_to_audit_info.each do |user|\n describe \"oracle users: #{user} allowed access to audit information\" do\n subject { user }\n it { should be_in input('allowed_audit_users') }\n end\n end\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61625.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61659.rb", "line": 1 }, - "id": "V-61625" + "id": "V-61659" }, { - "title": "The DBMS must ensure users are authenticated with an individual\n authenticator prior to using a shared authenticator.", - "desc": "To assure individual accountability and prevent unauthorized access,\n application users (and any processes acting on behalf of users) must be\n individually identified and authenticated.\n\n A shared authenticator is a generic account used by multiple individuals.\n Use of a shared authenticator alone does not uniquely identify individual\n users. An example of a shared authenticator is the UNIX OS 'root' user account,\n a Windows 'administrator' account, an 'SA' account, or a 'helpdesk' account.\n\n For example, the UNIX and Windows operating systems offer a 'switch user'\n capability allowing users to authenticate with their individual credentials\n and, when needed, 'switch' to the administrator role. This method provides for\n unique individual authentication prior to using a shared authenticator.\n\n Some applications may not have the need to provide a group authenticator;\n this is considered a matter of application design. In those instances where the\n application design includes the use of a shared authenticator, this requirement\n will apply.\n\n There may also be instances when specific user actions need to be performed\n on the information system without unique user identification or authentication.\n An example of this type of access is a web server which contains publicly\n releasable information. These types of accesses are allowed but must be\n explicitly identified and documented by the organization.\n\n When shared accounts are utilized without another means of identifying\n individual users, users may deny having performed a particular action.", + "title": "Changes to configuration options must be audited.", + "desc": "The AUDIT_SYS_OPERATIONS parameter is used to enable auditing of\n actions taken by the user SYS. The SYS user account is a shared account by\n definition and holds all privileges in the Oracle database. It is the account\n accessed by users connecting to the database with SYSDBA or SYSOPER privileges.", "descriptions": { - "default": "To assure individual accountability and prevent unauthorized access,\n application users (and any processes acting on behalf of users) must be\n individually identified and authenticated.\n\n A shared authenticator is a generic account used by multiple individuals.\n Use of a shared authenticator alone does not uniquely identify individual\n users. An example of a shared authenticator is the UNIX OS 'root' user account,\n a Windows 'administrator' account, an 'SA' account, or a 'helpdesk' account.\n\n For example, the UNIX and Windows operating systems offer a 'switch user'\n capability allowing users to authenticate with their individual credentials\n and, when needed, 'switch' to the administrator role. This method provides for\n unique individual authentication prior to using a shared authenticator.\n\n Some applications may not have the need to provide a group authenticator;\n this is considered a matter of application design. In those instances where the\n application design includes the use of a shared authenticator, this requirement\n will apply.\n\n There may also be instances when specific user actions need to be performed\n on the information system without unique user identification or authentication.\n An example of this type of access is a web server which contains publicly\n releasable information. These types of accesses are allowed but must be\n explicitly identified and documented by the organization.\n\n When shared accounts are utilized without another means of identifying\n individual users, users may deny having performed a particular action." + "default": "The AUDIT_SYS_OPERATIONS parameter is used to enable auditing of\n actions taken by the user SYS. The SYS user account is a shared account by\n definition and holds all privileges in the Oracle database. It is the account\n accessed by users connecting to the database with SYSDBA or SYSOPER privileges." }, "impact": 0.5, "refs": [], "tags": { - "gtitle": "SRG-APP-000153-DB-000108", - "gid": "V-61711", - "rid": "SV-76201r1_rule", - "stig_id": "O121-C2-013300", - "fix_id": "F-67627r1_fix", - "cci": [ - "CCI-000770" - ], - "nist": [ - "IA-2 (5)", - "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 settings, OS settings, and/or enterprise-level\n authentication/access mechanism settings to determine whether shared accounts\n exist. If group accounts do not exist, this is NA.\n\n Review DBMS settings to determine if individual authentication is required\n before shared authentication.\n\n If shared authentication does not require prior individual authentication, this\n is a finding.\n\n (Oracle Access Manager may be helpful in meeting this requirement. Notes on\n Oracle Access Manager follow.)\n\n Oracle Access Manager is used when there is a need for multifactor\n authentication of applications front-ending Oracle Datasets that may use group\n accounts. Oracle Access Manager supports using PKI-based smart cards (CAC, PIV)\n for multifactor authentication. When a user authenticates to a smart card\n application, the smart card engine produces a certificate-based authentication\n token. Can configure a certificate-based authentication scheme in Oracle Access\n Manager that uses information from the smart card certificate.\n Certificate-based authentication works with any smart card or similar device\n that presents an X.509 certificate.\n\n Check:\n First, check that the Authentication Module is set up properly:\n 1) Go to Oracle Access Manager Home Screen and click the Policy Configuration\n tab. Select the X509Scheme.\n 2) Make sure the Authentication Module option is set to X509Plugin.\n\n Second, check that the Authentication policy is using the x509Scheme:\n 1) Go to Oracle Access Manager Home Screen and click the Policy Configuration\n tab.\n 2) Select Application Domains. Select Search.\n 3) Select the application domain protecting the Oracle Database.\n 4) Select the Authentication Polices tab and Click Protected Resource Policy.\n 5) Make sure the Authentication Scheme is set to x509Scheme.", - "fix": "Configure DBMS, OS and/or enterprise-level authentication/access\n mechanism to require individual authentication prior to authentication for\n shared account access.\n\n If appropriate, install Oracle Access Manager to provide multifactor\n authentication of applications front-ending Oracle Databases and using shared\n accounts. After installation, use x509 Authentication modules provided out of\n the box." - }, - "code": "control 'V-61711' do\n title \"The DBMS must ensure users are authenticated with an individual\n authenticator prior to using a shared authenticator.\"\n desc \"To assure individual accountability and prevent unauthorized access,\n application users (and any processes acting on behalf of users) must be\n individually identified and authenticated.\n\n A shared authenticator is a generic account used by multiple individuals.\n Use of a shared authenticator alone does not uniquely identify individual\n users. An example of a shared authenticator is the UNIX OS 'root' user account,\n a Windows 'administrator' account, an 'SA' account, or a 'helpdesk' account.\n\n For example, the UNIX and Windows operating systems offer a 'switch user'\n capability allowing users to authenticate with their individual credentials\n and, when needed, 'switch' to the administrator role. This method provides for\n unique individual authentication prior to using a shared authenticator.\n\n Some applications may not have the need to provide a group authenticator;\n this is considered a matter of application design. In those instances where the\n application design includes the use of a shared authenticator, this requirement\n will apply.\n\n There may also be instances when specific user actions need to be performed\n on the information system without unique user identification or authentication.\n An example of this type of access is a web server which contains publicly\n releasable information. These types of accesses are allowed but must be\n explicitly identified and documented by the organization.\n\n When shared accounts are utilized without another means of identifying\n individual users, users may deny having performed a particular action.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000153-DB-000108'\n tag \"gid\": 'V-61711'\n tag \"rid\": 'SV-76201r1_rule'\n tag \"stig_id\": 'O121-C2-013300'\n tag \"fix_id\": 'F-67627r1_fix'\n tag \"cci\": ['CCI-000770']\n tag \"nist\": ['IA-2 (5)', '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 to determine whether shared accounts\n exist. If group accounts do not exist, this is NA.\n\n Review DBMS settings to determine if individual authentication is required\n before shared authentication.\n\n If shared authentication does not require prior individual authentication, this\n is a finding.\n\n (Oracle Access Manager may be helpful in meeting this requirement. Notes on\n Oracle Access Manager follow.)\n\n Oracle Access Manager is used when there is a need for multifactor\n authentication of applications front-ending Oracle Datasets that may use group\n accounts. Oracle Access Manager supports using PKI-based smart cards (CAC, PIV)\n for multifactor authentication. When a user authenticates to a smart card\n application, the smart card engine produces a certificate-based authentication\n token. Can configure a certificate-based authentication scheme in Oracle Access\n Manager that uses information from the smart card certificate.\n Certificate-based authentication works with any smart card or similar device\n that presents an X.509 certificate.\n\n Check:\n First, check that the Authentication Module is set up properly:\n 1) Go to Oracle Access Manager Home Screen and click the Policy Configuration\n tab. Select the X509Scheme.\n 2) Make sure the Authentication Module option is set to X509Plugin.\n\n Second, check that the Authentication policy is using the x509Scheme:\n 1) Go to Oracle Access Manager Home Screen and click the Policy Configuration\n tab.\n 2) Select Application Domains. Select Search.\n 3) Select the application domain protecting the Oracle Database.\n 4) Select the Authentication Polices tab and Click Protected Resource Policy.\n 5) Make sure the Authentication Scheme is set to x509Scheme.\"\n tag \"fix\": \"Configure DBMS, OS and/or enterprise-level authentication/access\n mechanism to require individual authentication prior to authentication for\n shared account access.\n\n If appropriate, install Oracle Access Manager to provide multifactor\n authentication of applications front-ending Oracle Databases and using shared\n accounts. After installation, use x509 Authentication modules provided out of\n the box.\"\n describe 'A manual review is required to ensure the DBMS ensures users are authenticated with an individual\n authenticator prior to using a shared authenticator' do\n skip 'A manual review is required to ensure the DBMS ensures users are authenticated with an individual\n authenticator prior to using a shared authenticator'\n end\nend\n", - "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61711.rb", - "line": 1 - }, - "id": "V-61711" - }, - { - "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": "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": [ - { - "ref": [] - } - ], - "tags": { - "gtitle": "SRG-APP-000165-DB-000081", - "gid": "V-61721", - "rid": "SV-76211r2_rule", - "stig_id": "O121-C2-014000", - "fix_id": "F-67637r2_fix", + "gtitle": "SRG-APP-000516-DB-999900", + "gid": "V-61519", + "rid": "SV-76009r1_rule", + "stig_id": "O121-BP-025800", + "fix_id": "F-67435r1_fix", "cci": [ - "CCI-000200" + "CCI-000366" ], "nist": [ - "IA-5 (1) (e)", + "CM-6 b", "Rev_4" ], "false_negatives": null, @@ -5638,39 +5688,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "If all user accounts are authenticated by the OS or an\n enterprise-level authentication/access mechanism, and not by Oracle, this is\n not a finding.\n\n For each profile that can be applied to accounts where authentication is under\n Oracle's control, determine the password 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;" + "check": "From SQL*Plus:\n\n select value from v$parameter where name = 'audit_sys_operations';\n\n If the value returned is FALSE, this is a finding.", + "fix": "From SQL*Plus:\n\n alter system set audit_sys_operations = TRUE scope = spfile;\n\n The above SQL*Plus command will set the parameter to take effect at next system\n startup." }, - "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", + "code": "control 'V-61519' do\n title 'Changes to configuration options must be audited.'\n desc \"The AUDIT_SYS_OPERATIONS parameter is used to enable auditing of\n actions taken by the user SYS. The SYS user account is a shared account by\n definition and holds all privileges in the Oracle database. It is the account\n accessed by users connecting to the database with SYSDBA or SYSOPER privileges.\"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000516-DB-999900'\n tag \"gid\": 'V-61519'\n tag \"rid\": 'SV-76009r1_rule'\n tag \"stig_id\": 'O121-BP-025800'\n tag \"fix_id\": 'F-67435r1_fix'\n tag \"cci\": ['CCI-000366']\n tag \"nist\": ['CM-6 b', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"From SQL*Plus:\n\n select value from v$parameter where name = 'audit_sys_operations';\n\n If the value returned is FALSE, this is a finding.\"\n tag \"fix\": \"From SQL*Plus:\n\n alter system set audit_sys_operations = TRUE scope = spfile;\n\n The above SQL*Plus command will set the parameter to take effect at next system\n startup.\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n parameter = sql.query(\"select value from v$parameter where name = 'audit_sys_operations';\").column('value')\n\n describe 'The oracle database AUDIT_SYS_OPERATIONS parameter' do\n subject { parameter }\n it { should_not cmp 'FALSE' }\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61721.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61519.rb", "line": 1 }, - "id": "V-61721" + "id": "V-61519" }, { - "title": "DBMS passwords must not be stored in compiled, encoded, or encrypted\n batch jobs or compiled, encoded, or encrypted application source code.", - "desc": "Password maximum lifetime is the maximum period of time, (typically\n in days) a user's password may be in effect before the user is forced to change\n it.\n\n Passwords need to be changed at specific policy-based intervals as per\n policy. Any password, no matter how complex, can eventually be cracked.\n\n One method of minimizing this risk is to use complex passwords and\n periodically change them. If the application does not limit the lifetime of\n passwords and force users to change their passwords, there is the risk that the\n system and/or application passwords could be compromised.\n\n The storage of passwords in application source or batch job code that is\n compiled, encoded, or encrypted prevents compliance with password expiration\n and other management requirements, as well as provides another means for\n potential discovery.\n\n This requirement applies equally to those accounts managed by Oracle and\n those managed and authenticated by the OS or an enterprise-wide mechanism.\n\n This requirement should not be construed as prohibiting or discouraging the\n encryption of source code, which remains an advisable precaution.\n\n Transport Layer Security (TLS) is the successor protocol to Secure Sockets\n Layer (SSL). Although the Oracle configuration parameters have names including\n 'SSL', such as SSL_VERSION and SSL_CIPHER_SUITES, they refer to TLS.\n\n This calls for inspection of application source code, which will require\n collaboration with the application developers. It is recognized that in many\n cases, the database administrator (DBA) is organizationally separate from the\n application developers and may have limited, if any, access to source code.\n Nevertheless, protections of this type are so important to the secure operation\n of databases that they must not be ignored. At a minimum, the DBA must attempt\n to obtain assurances from the development organization that this issue has been\n addressed and must document what has been discovered.", + "title": "Object permissions granted to PUBLIC must be restricted.", + "desc": "Permissions on objects may be granted to the user group PUBLIC.\n Because every database user is a member of the PUBLIC group, granting object\n permissions to PUBLIC gives all users in the database access to that object. In\n a secure environment, granting object permissions to PUBLIC must be restricted\n to those objects that all users are allowed to access. The policy does not\n require object permissions assigned to PUBLIC by the installation of Oracle\n Database server components be revoked.", "descriptions": { - "default": "Password maximum lifetime is the maximum period of time, (typically\n in days) a user's password may be in effect before the user is forced to change\n it.\n\n Passwords need to be changed at specific policy-based intervals as per\n policy. Any password, no matter how complex, can eventually be cracked.\n\n One method of minimizing this risk is to use complex passwords and\n periodically change them. If the application does not limit the lifetime of\n passwords and force users to change their passwords, there is the risk that the\n system and/or application passwords could be compromised.\n\n The storage of passwords in application source or batch job code that is\n compiled, encoded, or encrypted prevents compliance with password expiration\n and other management requirements, as well as provides another means for\n potential discovery.\n\n This requirement applies equally to those accounts managed by Oracle and\n those managed and authenticated by the OS or an enterprise-wide mechanism.\n\n This requirement should not be construed as prohibiting or discouraging the\n encryption of source code, which remains an advisable precaution.\n\n Transport Layer Security (TLS) is the successor protocol to Secure Sockets\n Layer (SSL). Although the Oracle configuration parameters have names including\n 'SSL', such as SSL_VERSION and SSL_CIPHER_SUITES, they refer to TLS.\n\n This calls for inspection of application source code, which will require\n collaboration with the application developers. It is recognized that in many\n cases, the database administrator (DBA) is organizationally separate from the\n application developers and may have limited, if any, access to source code.\n Nevertheless, protections of this type are so important to the secure operation\n of databases that they must not be ignored. At a minimum, the DBA must attempt\n to obtain assurances from the development organization that this issue has been\n addressed and must document what has been discovered." + "default": "Permissions on objects may be granted to the user group PUBLIC.\n Because every database user is a member of the PUBLIC group, granting object\n permissions to PUBLIC gives all users in the database access to that object. In\n a secure environment, granting object permissions to PUBLIC must be restricted\n to those objects that all users are allowed to access. The policy does not\n require object permissions assigned to PUBLIC by the installation of Oracle\n Database server components be revoked." }, "impact": 0, - "refs": [ - { - "ref": [] - } - ], + "refs": [], "tags": { - "gtitle": "SRG-APP-000174-DB-000079", - "gid": "V-61737", - "rid": "SV-76227r3_rule", - "stig_id": "O121-C2-015100", - "fix_id": "F-67653r2_fix", + "gtitle": "SRG-APP-000516-DB-999900", + "gid": "V-61439", + "rid": "SV-75929r3_rule", + "stig_id": "O121-BP-022600", + "fix_id": "F-67355r2_fix", "cci": [ - "CCI-000199" + "CCI-000366" ], "nist": [ - "IA-5 (1) (d)", + "CM-6 b", "Rev_4" ], "false_negatives": null, @@ -5683,39 +5729,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Review application source code required to be encoded or\n encrypted for database accounts used by applications or batch jobs to access\n the database.\n\n Review source batch job code prior to compiling, encoding, or encrypting for\n database accounts used by applications or the batch jobs themselves to access\n the database.\n\n Determine if the compiled, encoded, or encrypted application source code or\n batch jobs contain passwords used for authentication to the database.\n\n If any of the identified compiled, encoded, or encrypted application source\n code or batch job code do contain passwords used for authentication to the\n database, this is a finding.\n\n - - - - -\n The check would depend on the information provided by the DBA. In a default\n Oracle installation, all passwords are stored in an encrypted manner. Ask the\n DBA if they have created an External Password Store for applications, batch\n jobs, and scripts to use.\n\n Secure External Password Store\n\n Can store password credentials for connecting to databases by using a\n client-side Oracle wallet. An Oracle wallet is a secure software container that\n stores authentication and signing credentials.\n\n This wallet usage can simplify large-scale deployments that rely on password\n credentials for connecting to databases. When this feature is configured,\n application code, batch jobs, and scripts no longer need embedded user names\n and passwords. This reduces risk because the passwords are no longer exposed,\n and password management policies are more easily enforced without changing\n application code whenever user names or passwords change.\n\n The external password store of the wallet is separate from the area where\n public key infrastructure (PKI) credentials are stored. Consequently, cannot\n use Oracle Wallet Manager to manage credentials in the external password store\n of the wallet. Instead, use the command-line utility mkstore to manage these\n credentials.\n\n How Does the External Password Store Work?\n\n Typically, users (and as applications, batch jobs, and scripts) connect to\n databases by using a standard CONNECT statement that specifies a database\n connection string. This string can include a user name and password, and an\n Oracle Net service name identifying the database on an Oracle Database network.\n If the password is omitted, the connection prompts the user for the password.\n\n For example, the service name could be the URL that identifies that database,\n or a TNS alias entered in the tnsnames.ora file in the database. Another\n possibility is a host:port:sid string.\n\n The following examples are standard CONNECT statements that could be used for a\n client that is not configured to use the external password store:\n\n CONNECT salesapp@sales_db.us.example.com\n Enter password: password\n\n CONNECT salesapp@orasales\n Enter password: password\n\n CONNECT salesapp@ourhost37:1527:DB17\n Enter password: password\n\n In these examples, salesapp is the user name, with the unique connection string\n for the database shown as specified in three different ways. Could use its URL\n sales_db.us.example.com, or its TNS alias, orasales, from the tnsnames.ora\n file, or its host:port:sid string.\n\n However, when clients are configured to use the secure external password store,\n applications can connect to a database with the following CONNECT statement\n syntax, without specifying database logon credentials:\n\n CONNECT /@db_connect_string\n\n CONNECT /@db_connect_string AS SYSDBA\n\n CONNECT /@db_connect_string AS SYSOPER\n\n In this specification, db_connect_string is a valid connection string to access\n the intended database, such as the service name, URL, or alias as shown in the\n earlier examples. Each user account must have its own unique connection string;\n cannot create one connection string for multiple users.\n\n In this case, the database credentials, user name and password, are securely\n stored in an Oracle wallet created for this purpose. The autologon feature of\n this wallet is turned on, so the system does not need a password to open the\n wallet. From the wallet, it gets the credentials to access the database for the\n user they represent.", - "fix": "Design DBMS application code and batch job code that is compiled,\n encoded or encrypted, to NOT contain passwords.\n\n - - - - -\n Oracle provides the capability to provide for a secure external password\n facility. Use the Oracle mkstore to create a secure storage area for passwords\n for applications, batch jobs, and scripts to use or deploy a site-authorized\n facility to perform this function.\n\n Check to see what has been stored in the Oracle External Password Store\n\n To view all contents of a client wallet external password store, check specific\n credentials by viewing them. Listing the external password store contents\n provides information can use to decide whether to add or delete credentials\n from the store. To list the contents of the external password store, enter the\n following command at the command line:\n\n $ mkstore -wrl wallet_location -listCredential\n\n For example:\n\n $ mkstore -wrl c:\\oracle\\product\\12.1.0\\db_1\\wallets -listCredential\n\n The wallet_location specifies the path to the directory where the wallet, whose\n external password store contents is to be viewed, is located. This command\n lists all of the credential database service names (aliases) and the\n corresponding user name (schema) for that database. Passwords are not listed.\n\n Configuring Clients to Use the External Password Store\n\n If the client is already configured to use external authentication, such as\n Windows native authentication or Transport Layer Security (TLS), then Oracle\n Database uses that authentication method. The same credentials used for this\n type of authentication are typically also used to log on to the database.\n\n For clients not using such authentication methods or wanting to override them\n for database authentication, can set the SQLNET.WALLET_OVERRIDE parameter in\n sqlnet.ora to TRUE. The default value for SQLNET.WALLET_OVERRIDE is FALSE,\n allowing standard use of authentication credentials as before.\n\n If wanting a client to use the secure external password store feature, then\n perform the following configuration task:\n\n 1. Create a wallet on the client by using the following syntax at the command\n line:\n\n mkstore -wrl wallet_location -create\n\n For example:\n\n mkstore -wrl c:\\oracle\\product\\12.1.0\\db_1\\wallets -create\n Enter password: password\n\n The wallet_location is the path to the directory where the wallet is to be\n created and stored. This command creates an Oracle wallet with the autologon\n feature enabled at the location specified. The autologon feature enables the\n client to access the wallet contents without supplying a password.\n\n The mkstore utility -create option uses password complexity verification.\n\n 2. Create database connection credentials in the wallet by using the following\n syntax at the command line:\n\n mkstore -wrl wallet_location -createCredential db_connect_string username\n Enter password: password\n\n For example:\n\n mkstore -wrl c:\\oracle\\product\\12.1.0\\db_1\\wallets -createCredential\n oracle system\n Enter password: password\n\n In this specification:\n\n The wallet_location is the path to the directory where the wallet was created.\n The db_connect_string used in the CONNECT /@db_connect_string statement must be\n identical to the db_connect_string specified in the -createCredential command.\n\n The db_connect_string is the TNS alias used to specify the database in the\n tnsnames.ora file or any service name used to identify the database on an\n Oracle network. By default, tnsnames.ora is located in the\n $ORACLE_HOME/network/admin directory on UNIX systems and in ORACLE_HOME etwork\\admin on Windows.\n\n The username is the database logon credential. When prompted, enter the\n password for this user.\n\n 3. In the client sqlnet.ora file, enter the WALLET_LOCATION parameter and set\n it to the directory location of the wallet created in Step 1. For example, if\n the wallet was created in\n $ORACLE_HOME/network/admin and Oracle home is set to /private/ora12,\n then need to enter the following into your client sqlnet.ora file:\n\n WALLET_LOCATION =\n (SOURCE =\n (METHOD = FILE)\n (METHOD_DATA =\n (DIRECTORY = /private/ora12/network/admin)\n )\n )\n\n 4. In the client sqlnet.ora file, enter the SQLNET.WALLET_OVERRIDE parameter\n and set it to TRUE as follows:\n\n SQLNET.WALLET_OVERRIDE = TRUE\n\n setting causes all CONNECT /@db_connect_string statements to use the\n information in the wallet at the specified location to authenticate to\n databases.\n\n When external authentication is in use, an authenticated user with such a\n wallet can use the CONNECT /@db_connect_string syntax to access the previously\n specified databases without providing a user name and password. However, if a\n user fails that external authentication, then these connect statements also\n fail.\n\n Below is a sample sqlnet.ora file with the WALLET_LOCATION and the\n SQLNET.WALLET_OVERRIDE parameters set as described in Steps 3 and 4.\n\n Below is a sample SQLNET.ORA File with Wallet Parameters Set\n\n WALLET_LOCATION =\n (SOURCE =\n (METHOD = FILE)\n (METHOD_DATA =\n (DIRECTORY = /private/ora12/network/admin)\n )\n )\n\n SQLNET.WALLET_OVERRIDE = TRUE\n SSL_CLIENT_AUTHENTICATION = FALSE\n SSL_VERSION = 1.2 or 1.1\n\n Note: \"SSL_VERSION = 1.2 or 1.1\" is the actual value, not a suggestion to\n use one or the other.\n\n (Note: this assumes that a single sqlnet.ora file, in the default location, is\n in use. Please see the supplemental file, \"Non-default sqlnet.ora\n configurations.pdf\" for how to find multiple and/or differently-located\n sqlnet.ora files.)" + "check": "A default Oracle Database installation provides a set of\n predefined administrative accounts and non-administrative accounts. These are\n accounts that have special privileges required to administer areas of the\n database, such as the “CREATE ANY TABLE” or “ALTER SESSION” privilege, or\n “EXECUTE” privileges on packages owned by the SYS schema. The default\n tablespace for administrative accounts is either “SYSTEM” or “SYSAUX”.\n Non-administrative user accounts only have the minimum privileges needed to\n perform their jobs. Their default tablespace is “USERS”.\n\n To protect these accounts from unauthorized access, the installation process\n expires and locks most of these accounts, except where noted below. The\n database administrator is responsible for unlocking and resetting these\n accounts, as required.\n\n Non-Administrative Accounts - Expired and locked:\n APEX_PUBLIC_USER, DIP, FLOWS_040100*, FLOWS_FILES, MDDATA, ORACLE_OCM,\n SPATIAL_CSW_ADMIN_USR, SPATIAL_WFS_ADMIN_USR, XS$NULL\n\n Administrative Accounts - Expired and Locked:\n ANONYMOUS, CTXSTS, EXFSYS, LBACSYS, MDSYS, OLAPSYS, OEDDATA, OWBSYS,\n ORDPLUGINS, ORDSYS, OUTLN, SI_INFORMTN_SCHEMA, WK_TEST, WK_SYS, WKPROXY, WMSYS,\n XDB\n\n Administrative Accounts - Open:\n DBSNMP, MGMT_VIEW, SYS, SYSMAN, SYSTEM\n\n * Subject to change based on version installed\n\n Run the SQL query:\n\n select owner ||'.'|| table_name ||':'|| privilege from dba_tab_privs\n where grantee = 'PUBLIC';\n and owner not in\n ();\n\n (With respect to the list of special accounts that are excluded from this\n requirement, it is expected that the DBA will maintain the list to suit local\n circumstances, adding special accounts as necessary and removing any that are\n not supposed to be in use in the Oracle deployment that is under review.)\n\n If there are any records returned that are not Oracle product accounts, and are\n not documented and authorized, this is a finding.\n\n Note: This check may return false positives where other Oracle product accounts\n are not included in the exclusion list.", + "fix": "Revoke any privileges granted to PUBLIC for objects that are not\n owned by Oracle product accounts.\n\n From SQL*Plus:\n\n revoke [privilege name] from [user name] on [object name];\n\n Assign permissions to custom application user roles based on job functions:\n\n From SQL*Plus:\n\n grant [privilege name] to [user role] on [object name];" }, - "code": " control 'V-61737' do\n impact 0.0\n describe 'This control is not applicable on oracle within aws rds, as aws manages the operating system in which the oracle database is running on' do\n skip 'This control is not applicable on oracle within aws rds, as aws manages the operating system in which the oracle database is running on'\n end\n end\n", + "code": "control 'V-61439' do\n title 'Object permissions granted to PUBLIC must be restricted.'\n desc \"Permissions on objects may be granted to the user group PUBLIC.\n Because every database user is a member of the PUBLIC group, granting object\n permissions to PUBLIC gives all users in the database access to that object. In\n a secure environment, granting object permissions to PUBLIC must be restricted\n to those objects that all users are allowed to access. The policy does not\n require object permissions assigned to PUBLIC by the installation of Oracle\n Database server components be revoked.\"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000516-DB-999900'\n tag \"gid\": 'V-61439'\n tag \"rid\": 'SV-75929r3_rule'\n tag \"stig_id\": 'O121-BP-022600'\n tag \"fix_id\": 'F-67355r2_fix'\n tag \"cci\": ['CCI-000366']\n tag \"nist\": ['CM-6 b', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"A default Oracle Database installation provides a set of\n predefined administrative accounts and non-administrative accounts. These are\n accounts that have special privileges required to administer areas of the\n database, such as the “CREATE ANY TABLE” or “ALTER SESSION” privilege, or\n “EXECUTE” privileges on packages owned by the SYS schema. The default\n tablespace for administrative accounts is either “SYSTEM” or “SYSAUX”.\n Non-administrative user accounts only have the minimum privileges needed to\n perform their jobs. Their default tablespace is “USERS”.\n\n To protect these accounts from unauthorized access, the installation process\n expires and locks most of these accounts, except where noted below. The\n database administrator is responsible for unlocking and resetting these\n accounts, as required.\n\n Non-Administrative Accounts - Expired and locked:\n APEX_PUBLIC_USER, DIP, FLOWS_040100*, FLOWS_FILES, MDDATA, ORACLE_OCM,\n SPATIAL_CSW_ADMIN_USR, SPATIAL_WFS_ADMIN_USR, XS$NULL\n\n Administrative Accounts - Expired and Locked:\n ANONYMOUS, CTXSTS, EXFSYS, LBACSYS, MDSYS, OLAPSYS, OEDDATA, OWBSYS,\n ORDPLUGINS, ORDSYS, OUTLN, SI_INFORMTN_SCHEMA, WK_TEST, WK_SYS, WKPROXY, WMSYS,\n XDB\n\n Administrative Accounts - Open:\n DBSNMP, MGMT_VIEW, SYS, SYSMAN, SYSTEM\n\n * Subject to change based on version installed\n\n Run the SQL query:\n\n select owner ||'.'|| table_name ||':'|| privilege from dba_tab_privs\n where grantee = 'PUBLIC';\n and owner not in\n ();\n\n (With respect to the list of special accounts that are excluded from this\n requirement, it is expected that the DBA will maintain the list to suit local\n circumstances, adding special accounts as necessary and removing any that are\n not supposed to be in use in the Oracle deployment that is under review.)\n\n If there are any records returned that are not Oracle product accounts, and are\n not documented and authorized, this is a finding.\n\n Note: This check may return false positives where other Oracle product accounts\n are not included in the exclusion list.\"\n tag \"fix\": \"Revoke any privileges granted to PUBLIC for objects that are not\n owned by Oracle product accounts.\n\n From SQL*Plus:\n\n revoke [privilege name] from [user name] on [object name];\n\n Assign permissions to custom application user roles based on job functions:\n\n From SQL*Plus:\n\n grant [privilege name] to [user role] on [object name];\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n users_with_public_access = sql.query(\"select DISTINCT owner from dba_tab_privs where grantee = 'PUBLIC';\").column('owner').uniq\n\n if users_with_public_access.empty?\n impact 0.0\n describe 'There are no oracle users with access to PUBLIC, control N/A' do\n skip 'There are no oracle users with access to PUBLIC'\n end\n else\n users_with_public_access.each do |user|\n describe \"oracle user: #{user} with access to PUBLIC\" do\n subject { user }\n it { should be_in input('users_allowed_access_to_public')}\n end\n end\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61737.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61439.rb", "line": 1 }, - "id": "V-61737" + "id": "V-61439" }, { - "title": "The DBMS must terminate the network connection associated with a\n communications session at the end of the session or 15 minutes of inactivity.", - "desc": "Non-local maintenance and diagnostic activities are those activities\n conducted by individuals communicating through a network, either an external\n network (e.g., the Internet) or an internal network.\n\n The act of managing systems and applications includes the ability to access\n sensitive application information, such as system configuration details,\n diagnostic information, user information, and potentially sensitive application\n data.\n\n When applications provide a remote management capability inherent to the\n application, the application needs to ensure all sessions and network\n connections are terminated when non-local maintenance is completed.\n\n When network connections are left open after the database session has\n closed, the network session is open to session hijacking.\n\n The Oracle Listener inherently meets most of this SRG requirement. When a\n user logs off, or times out, or encounters an unrecoverable network fault, the\n Oracle Listener terminates all sessions and network connections. The remaining\n aspect of the requirement, the timeout because of inactivity, is configurable.", + "title": "The DBMS must provide a mechanism to automatically identify accounts\n designated as temporary or emergency accounts.", + "desc": "Temporary application accounts could be used in the event of a vendor\n support visit where a support representative requires a temporary unique\n account in order to perform diagnostic testing or conduct some other\n support-related activity. When these types of accounts are created, there is a\n risk that the temporary account may remain in place and active after the\n support representative has left.\n\n To address this, in the event temporary application accounts are required,\n the application must ensure accounts designated as temporary in nature shall\n automatically terminate these accounts after an organization-defined time\n period. Such a process and capability greatly reduces the risk that accounts\n will be misused, hijacked, or data compromised.\n\n Note that user authentication and account management should be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP. This requirement applies to cases where it is necessary to\n have accounts directly managed by Oracle.\n\n Temporary database accounts must be identified in order for the system to\n recognize and terminate them after a given time period. The DBMS and any\n administrators must have a means to recognize any temporary accounts for\n special handling.", "descriptions": { - "default": "Non-local maintenance and diagnostic activities are those activities\n conducted by individuals communicating through a network, either an external\n network (e.g., the Internet) or an internal network.\n\n The act of managing systems and applications includes the ability to access\n sensitive application information, such as system configuration details,\n diagnostic information, user information, and potentially sensitive application\n data.\n\n When applications provide a remote management capability inherent to the\n application, the application needs to ensure all sessions and network\n connections are terminated when non-local maintenance is completed.\n\n When network connections are left open after the database session has\n closed, the network session is open to session hijacking.\n\n The Oracle Listener inherently meets most of this SRG requirement. When a\n user logs off, or times out, or encounters an unrecoverable network fault, the\n Oracle Listener terminates all sessions and network connections. The remaining\n aspect of the requirement, the timeout because of inactivity, is configurable." + "default": "Temporary application accounts could be used in the event of a vendor\n support visit where a support representative requires a temporary unique\n account in order to perform diagnostic testing or conduct some other\n support-related activity. When these types of accounts are created, there is a\n risk that the temporary account may remain in place and active after the\n support representative has left.\n\n To address this, in the event temporary application accounts are required,\n the application must ensure accounts designated as temporary in nature shall\n automatically terminate these accounts after an organization-defined time\n period. Such a process and capability greatly reduces the risk that accounts\n will be misused, hijacked, or data compromised.\n\n Note that user authentication and account management should be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP. This requirement applies to cases where it is necessary to\n have accounts directly managed by Oracle.\n\n Temporary database accounts must be identified in order for the system to\n recognize and terminate them after a given time period. The DBMS and any\n administrators must have a means to recognize any temporary accounts for\n special handling." }, "impact": 0.5, - "refs": [ - { - "ref": [] - } - ], + "refs": [], "tags": { - "gtitle": "SRG-APP-000190-DB-000137", - "gid": "V-61757", - "rid": "SV-76247r2_rule", - "stig_id": "O121-C2-016500", - "fix_id": "F-67673r2_fix", + "gtitle": "SRG-APP-000024-DB-000002", + "gid": "V-61559", + "rid": "SV-76049r2_rule", + "stig_id": "O121-C2-001900", + "fix_id": "F-67475r6_fix", "cci": [ - "CCI-001133" + "CCI-000016" ], "nist": [ - "SC-10", + "AC-2 (2)", "Rev_4" ], "false_negatives": null, @@ -5728,35 +5770,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Review DBMS settings, OS settings, and vendor documentation to\n verify network connections are terminated when a database communications\n session is ended or after 15 minutes of inactivity.\n\n If the network connection is not terminated, this is a finding.\n\n The defined duration for these timeouts 15 minutes, except to fulfill\n documented and validated mission requirements.", - "fix": "Configure DBMS and/or OS settings to disconnect network sessions\n when database communication sessions have ended or after the DoD-defined period\n of inactivity.\n\n To configure this in Oracle, modify each relevant profile. The resource name\n is IDLE_TIME, which is expressed in minutes. Using PPPPPP as an example of a\n profile, set the timeout to 15 minutes with:\n ALTER PROFILE PPPPPP LIMIT IDLE_TIME 15;" + "check": "If the organization has a policy, consistently enforced,\n forbidding the creation of emergency or temporary accounts, this is not a\n finding.\n\n If all user accounts are authenticated by the OS or an enterprise-level\n authentication/access mechanism and not by Oracle, this is not a finding.\n\n If using database mechanisms to satisfy this requirement, look for a profile\n for use with temporary accounts. To obtain a list of profiles:\n SELECT PROFILE#, NAME FROM SYS.PROFNAME$;\n\n To obtain a list of users assigned a given profile (TEMPORARY_USERS, in this\n example):\n SELECT USERNAME, PROFILE FROM SYS.DBA_USERS\n WHERE PROFILE = 'TEMPORARY_USERS'\n ORDER BY USERNAME;\n\n If no profile for temporary accounts can be identified, this is not a finding.", + "fix": "Use a profile with a distinctive name (for example,\n TEMPORARY_USERS), so that temporary users can be easily identified. Whenever a\n temporary user account is created, assign it to this profile.\n\n To enable resource limiting via profiles, use the SQL statement:\n ALTER SYSTEM SET RESOURCE_LIMIT = TRUE;\n\n Set values in the profile as needed for temporary users - see below for further\n information. The values here are examples; set them to values appropriate to\n the situation:\n\n CREATE PROFILE TEMPORARY_USERS\n LIMIT\n SESSIONS_PER_USER \n CPU_PER_SESSION \n CPU_PER_CALL \n CONNECT_TIME \n LOGICAL_READS_PER_SESSION DEFAULT\n LOGICAL_READS_PER_CALL \n PRIVATE_SGA \n COMPOSITE_LIMIT \n FAILED_LOGIN_ATTEMPTS 3\n PASSWORD_LIFE_TIME 7\n PASSWORD_REUSE_TIME 60\n PASSWORD_REUSE_MAX 5\n PASSWORD_VERIFY_FUNCTION ORA12c_STRONG_VERIFY_FUNCTION\n PASSWORD_LOCK_TIME UNLIMITED\n PASSWORD_GRACE_TIME 3;\n CREATE USER IDENTIFIED BY PROFILE TEMPORARY_USERS;\n\n Resource Parameters:\n\n COMPOSITE_LIMIT - Specify the total resource cost for a session, expressed in\n service units. Oracle Database calculates the total service units as a weighted\n sum of CPU_PER_SESSION, CONNECT_TIME,\n LOGICAL_READS_PER_SESSION, and PRIVATE_SGA.\n\n SESSIONS_PER_USER - Specify the number of concurrent sessions to limit the user\n to.\n\n CPU_PER_SESSION - Specify the CPU time limit for a session, expressed in\n hundredths of seconds.\n\n CPU_PER_CALL - Specify the CPU time limit for a call (a parse, execute, or\n fetch), expressed in hundredths of seconds.\n\n LOGICAL_READS_PER_SESSION - Specify the permitted number of data blocks read in\n a session, including blocks read from memory and disk.\n\n LOGICAL_READS_PER_CALL - Specify the permitted number of data blocks read for a\n call to process a SQL statement (a parse, execute, or fetch).\n\n PRIVATE_SGA - Specify the amount of private space a session can allocate in the\n shared pool of the system global area (SGA). Refer to size_clause for\n information on that clause.\n\n CONNECT_TIME - Specify the total elapsed time limit for a session, expressed in\n minutes.\n\n IDLE_TIME - Specify the permitted periods of continuous inactive time during a\n session, expressed in minutes. Long-running queries and other operations are\n not subject to this limit.\n\n COMPOSITE_LIMIT - See Oracle documentation for more details.\n\n\n Password Parameters\n\n Use the following clauses to set password parameters. Parameters that set\n lengths of time are interpreted in number of days. For testing purposes,\n specify minutes (n/1440) or even seconds (n/86400).\n\n FAILED_LOGIN_ATTEMPTS - Specify the number of failed attempts to log on to the\n user account before the account is locked. If omitting this clause, then the\n default is 10 times.\n\n PASSWORD_LIFE_TIME - Specify the number of days the same password can be used\n for authentication. If setting a value for PASSWORD_GRACE_TIME, then the\n password expires if it is not changed within the grace period, and further\n connections are rejected. If omitting this clause, then the default is 180 days.\n\n PASSWORD_REUSE_TIME and PASSWORD_REUSE_MAX - These two parameters must be set\n in conjunction with each other. PASSWORD_REUSE_TIME specifies the number of\n days before which a password cannot be reused. PASSWORD_REUSE_MAX specifies the\n number of password changes required before the current password can be reused.\n For these parameters to have any effect, specify an integer for both of them.\n\n If specifying a value for both of these parameters, then the user cannot reuse\n a password until the password has been changed the number of times specified\n for PASSWORD_REUSE_MAX during the number of days specified for\n PASSWORD_REUSE_TIME.\n\n For example, if specifying PASSWORD_REUSE_TIME to 30 and PASSWORD_REUSE_MAX to\n 10, then the user can reuse the password after 30 days if the password has\n already been changed 10 times.\n\n If specifying a value for either of these parameters and specify UNLIMITED for\n the other, then the user can never reuse a password.\n\n If specifying DEFAULT for either parameter, then Oracle Database uses the value\n defined in the DEFAULT profile. By default, all parameters are set to UNLIMITED\n in the DEFAULT profile. If the default setting of UNLIMITED in the DEFAULT\n profile has not changed, then the database treats the value for that parameter\n as UNLIMITED.\n\n If setting both of these parameters to UNLIMITED, then the database ignores\n both of them. This is the default if omitting both parameters.\n\n PASSWORD_LOCK_TIME - Specify the number of days an account will be locked after\n the specified number of consecutive failed logon attempts. If omitting this\n clause, then the default is 1 day.\n\n PASSWORD_GRACE_TIME - Specify the number of days after the grace period begins\n during which a warning is issued and logon is allowed. If omitting this clause,\n then the default is 7 days.\n\n PASSWORD_VERIFY_FUNCTION - The PASSWORD_VERIFY_FUNCTION clause lets a PL/SQL\n password complexity verification script be passed as an argument to the CREATE\n PROFILE statement. Oracle Database provides a default script, but can create\n your own routine or use third-party software instead." }, - "code": "control 'V-61757' do\n title \"The DBMS must terminate the network connection associated with a\n communications session at the end of the session or 15 minutes of inactivity.\"\n desc \"Non-local maintenance and diagnostic activities are those activities\n conducted by individuals communicating through a network, either an external\n network (e.g., the Internet) or an internal network.\n\n The act of managing systems and applications includes the ability to access\n sensitive application information, such as system configuration details,\n diagnostic information, user information, and potentially sensitive application\n data.\n\n When applications provide a remote management capability inherent to the\n application, the application needs to ensure all sessions and network\n connections are terminated when non-local maintenance is completed.\n\n When network connections are left open after the database session has\n closed, the network session is open to session hijacking.\n\n The Oracle Listener inherently meets most of this SRG requirement. When a\n user logs off, or times out, or encounters an unrecoverable network fault, the\n Oracle Listener terminates all sessions and network connections. The remaining\n aspect of the requirement, the timeout because of inactivity, is configurable.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000190-DB-000137'\n tag \"gid\": 'V-61757'\n tag \"rid\": 'SV-76247r2_rule'\n tag \"stig_id\": 'O121-C2-016500'\n tag \"fix_id\": 'F-67673r2_fix'\n tag \"cci\": ['CCI-001133']\n tag \"nist\": ['SC-10', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Review DBMS settings, OS settings, and vendor documentation to\n verify network connections are terminated when a database communications\n session is ended or after 15 minutes of inactivity.\n\n If the network connection is not terminated, this is a finding.\n\n The defined duration for these timeouts 15 minutes, except to fulfill\n documented and validated mission requirements.\"\n tag \"fix\": \"Configure DBMS and/or OS settings to disconnect network sessions\n when database communication sessions have ended or after the DoD-defined period\n of inactivity.\n\n To configure this in Oracle, modify each relevant profile. The resource name\n is IDLE_TIME, which is expressed in minutes. Using PPPPPP as an example of a\n profile, set the timeout to 15 minutes with:\n ALTER PROFILE PPPPPP LIMIT IDLE_TIME 15;\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n query = %{\n SELECT PROFILE, RESOURCE_NAME, LIMIT FROM DBA_PROFILES WHERE PROFILE =\n '%s' AND RESOURCE_NAME = 'IDLE_TIME'\n }\n\n user_profiles = sql.query('SELECT profile FROM dba_users;').column('profile').uniq\n\n user_profiles.each do |profile|\n next if profile == \"RDSADMIN\"\n idle_time = sql.query(format(query, profile: profile)).column('limit')\n\n describe \"The oracle database idele time for profile: #{profile}\" do\n subject { idle_time }\n it { should cmp <= 15 }\n end\n end\n if user_profiles.empty?\n describe 'There are no user profiles, therefore this control is NA' do\n skip 'There are no user profiles, therefore this control is NA'\n end\n end\nend\n", + "code": "control 'V-61559' do\n title \"The DBMS must provide a mechanism to automatically identify accounts\n designated as temporary or emergency accounts.\"\n desc \"Temporary application accounts could be used in the event of a vendor\n support visit where a support representative requires a temporary unique\n account in order to perform diagnostic testing or conduct some other\n support-related activity. When these types of accounts are created, there is a\n risk that the temporary account may remain in place and active after the\n support representative has left.\n\n To address this, in the event temporary application accounts are required,\n the application must ensure accounts designated as temporary in nature shall\n automatically terminate these accounts after an organization-defined time\n period. Such a process and capability greatly reduces the risk that accounts\n will be misused, hijacked, or data compromised.\n\n Note that user authentication and account management should be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP. This requirement applies to cases where it is necessary to\n have accounts directly managed by Oracle.\n\n Temporary database accounts must be identified in order for the system to\n recognize and terminate them after a given time period. The DBMS and any\n administrators must have a means to recognize any temporary accounts for\n special handling.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000024-DB-000002'\n tag \"gid\": 'V-61559'\n tag \"rid\": 'SV-76049r2_rule'\n tag \"stig_id\": 'O121-C2-001900'\n tag \"fix_id\": 'F-67475r6_fix'\n tag \"cci\": ['CCI-000016']\n tag \"nist\": ['AC-2 (2)', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"If the organization has a policy, consistently enforced,\n forbidding the creation of emergency or temporary accounts, this is not a\n finding.\n\n If all user accounts are authenticated by the OS or an enterprise-level\n authentication/access mechanism and not by Oracle, this is not a finding.\n\n If using database mechanisms to satisfy this requirement, look for a profile\n for use with temporary accounts. To obtain a list of profiles:\n SELECT PROFILE#, NAME FROM SYS.PROFNAME$;\n\n To obtain a list of users assigned a given profile (TEMPORARY_USERS, in this\n example):\n SELECT USERNAME, PROFILE FROM SYS.DBA_USERS\n WHERE PROFILE = 'TEMPORARY_USERS'\n ORDER BY USERNAME;\n\n If no profile for temporary accounts can be identified, this is not a finding.\"\n tag \"fix\": \"Use a profile with a distinctive name (for example,\n TEMPORARY_USERS), so that temporary users can be easily identified. Whenever a\n temporary user account is created, assign it to this profile.\n\n To enable resource limiting via profiles, use the SQL statement:\n ALTER SYSTEM SET RESOURCE_LIMIT = TRUE;\n\n Set values in the profile as needed for temporary users - see below for further\n information. The values here are examples; set them to values appropriate to\n the situation:\n\n CREATE PROFILE TEMPORARY_USERS\n LIMIT\n SESSIONS_PER_USER \n CPU_PER_SESSION \n CPU_PER_CALL \n CONNECT_TIME \n LOGICAL_READS_PER_SESSION DEFAULT\n LOGICAL_READS_PER_CALL \n PRIVATE_SGA \n COMPOSITE_LIMIT \n FAILED_LOGIN_ATTEMPTS 3\n PASSWORD_LIFE_TIME 7\n PASSWORD_REUSE_TIME 60\n PASSWORD_REUSE_MAX 5\n PASSWORD_VERIFY_FUNCTION ORA12c_STRONG_VERIFY_FUNCTION\n PASSWORD_LOCK_TIME UNLIMITED\n PASSWORD_GRACE_TIME 3;\n CREATE USER IDENTIFIED BY PROFILE TEMPORARY_USERS;\n\n Resource Parameters:\n\n COMPOSITE_LIMIT - Specify the total resource cost for a session, expressed in\n service units. Oracle Database calculates the total service units as a weighted\n sum of CPU_PER_SESSION, CONNECT_TIME,\n LOGICAL_READS_PER_SESSION, and PRIVATE_SGA.\n\n SESSIONS_PER_USER - Specify the number of concurrent sessions to limit the user\n to.\n\n CPU_PER_SESSION - Specify the CPU time limit for a session, expressed in\n hundredths of seconds.\n\n CPU_PER_CALL - Specify the CPU time limit for a call (a parse, execute, or\n fetch), expressed in hundredths of seconds.\n\n LOGICAL_READS_PER_SESSION - Specify the permitted number of data blocks read in\n a session, including blocks read from memory and disk.\n\n LOGICAL_READS_PER_CALL - Specify the permitted number of data blocks read for a\n call to process a SQL statement (a parse, execute, or fetch).\n\n PRIVATE_SGA - Specify the amount of private space a session can allocate in the\n shared pool of the system global area (SGA). Refer to size_clause for\n information on that clause.\n\n CONNECT_TIME - Specify the total elapsed time limit for a session, expressed in\n minutes.\n\n IDLE_TIME - Specify the permitted periods of continuous inactive time during a\n session, expressed in minutes. Long-running queries and other operations are\n not subject to this limit.\n\n COMPOSITE_LIMIT - See Oracle documentation for more details.\n\n\n Password Parameters\n\n Use the following clauses to set password parameters. Parameters that set\n lengths of time are interpreted in number of days. For testing purposes,\n specify minutes (n/1440) or even seconds (n/86400).\n\n FAILED_LOGIN_ATTEMPTS - Specify the number of failed attempts to log on to the\n user account before the account is locked. If omitting this clause, then the\n default is 10 times.\n\n PASSWORD_LIFE_TIME - Specify the number of days the same password can be used\n for authentication. If setting a value for PASSWORD_GRACE_TIME, then the\n password expires if it is not changed within the grace period, and further\n connections are rejected. If omitting this clause, then the default is 180 days.\n\n PASSWORD_REUSE_TIME and PASSWORD_REUSE_MAX - These two parameters must be set\n in conjunction with each other. PASSWORD_REUSE_TIME specifies the number of\n days before which a password cannot be reused. PASSWORD_REUSE_MAX specifies the\n number of password changes required before the current password can be reused.\n For these parameters to have any effect, specify an integer for both of them.\n\n If specifying a value for both of these parameters, then the user cannot reuse\n a password until the password has been changed the number of times specified\n for PASSWORD_REUSE_MAX during the number of days specified for\n PASSWORD_REUSE_TIME.\n\n For example, if specifying PASSWORD_REUSE_TIME to 30 and PASSWORD_REUSE_MAX to\n 10, then the user can reuse the password after 30 days if the password has\n already been changed 10 times.\n\n If specifying a value for either of these parameters and specify UNLIMITED for\n the other, then the user can never reuse a password.\n\n If specifying DEFAULT for either parameter, then Oracle Database uses the value\n defined in the DEFAULT profile. By default, all parameters are set to UNLIMITED\n in the DEFAULT profile. If the default setting of UNLIMITED in the DEFAULT\n profile has not changed, then the database treats the value for that parameter\n as UNLIMITED.\n\n If setting both of these parameters to UNLIMITED, then the database ignores\n both of them. This is the default if omitting both parameters.\n\n PASSWORD_LOCK_TIME - Specify the number of days an account will be locked after\n the specified number of consecutive failed logon attempts. If omitting this\n clause, then the default is 1 day.\n\n PASSWORD_GRACE_TIME - Specify the number of days after the grace period begins\n during which a warning is issued and logon is allowed. If omitting this clause,\n then the default is 7 days.\n\n PASSWORD_VERIFY_FUNCTION - The PASSWORD_VERIFY_FUNCTION clause lets a PL/SQL\n password complexity verification script be passed as an argument to the CREATE\n PROFILE statement. Oracle Database provides a default script, but can create\n your own routine or use third-party software instead.\"\n describe 'A manual review is required to ensure the DBMS provides a mechanism to automatically identify accounts\n designated as temporary or emergency accounts' do\n skip 'A manual review is required to ensure the DBMS provides a mechanism to automatically identify accounts\n designated as temporary or emergency accounts'\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61757.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61559.rb", "line": 1 }, - "id": "V-61757" + "id": "V-61559" }, { - "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": "DBA OS accounts must be granted only those host system privileges\n necessary for the administration of the DBMS.", + "desc": "This requirement is intended to limit exposure due to operating from\n within a privileged account or role. The inclusion of role is intended to\n address those situations where an access control policy, such as Role Based\n Access Control (RBAC), is being implemented and where a change of role provides\n the same degree of assurance in the change of access authorizations for both\n the user and all processes acting on behalf of the user as would be provided by\n a change between a privileged and non-privileged account.\n\n DBAs, if assigned excessive OS privileges, could perform actions that could\n endanger the information system or hide evidence of malicious activity.", "descriptions": { - "default": "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": "This requirement is intended to limit exposure due to operating from\n within a privileged account or role. The inclusion of role is intended to\n address those situations where an access control policy, such as Role Based\n Access Control (RBAC), is being implemented and where a change of role provides\n the same degree of assurance in the change of access authorizations for both\n the user and all processes acting on behalf of the user as would be provided by\n a change between a privileged and non-privileged account.\n\n DBAs, if assigned excessive OS privileges, could perform actions that could\n endanger the information system or hide evidence of malicious activity." }, - "impact": 0.5, + "impact": 0.7, "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-000063-DB-000021", + "gid": "V-61537", + "rid": "SV-76027r1_rule", + "stig_id": "O121-C1-004500", + "fix_id": "F-67453r1_fix", "cci": [ - "CCI-000382" + "CCI-000366" ], "nist": [ - "CM-7 b", + "CM-6 b", "Rev_4" ], "false_negatives": null, @@ -5769,30 +5811,30 @@ "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": "Review host system privileges assigned to the Oracle DBA group\n and all individual Oracle DBA accounts.\n\n Note: do not include the Oracle software installation account in any results\n for this check.\n\n For UNIX systems (as root):\n cat /etc/group | grep -i dba\n groups root\n\n If \"root\" is returned in the first list, this is a finding.\n\n If any accounts listed in the first list are also listed in the second list,\n this is a finding.\n\n Investigate any user account group memberships other than DBA or root groups\n that are returned by the following command (also as root):\n\n groups [dba user account]\n\n Replace [dba user account] with the user account name of each DBA account.\n\n If individual DBA accounts are assigned to groups that grant access or\n privileges for purposes other than DBA responsibilities, this is a finding.\n\n For Windows Systems (click or select):\n Start / Settings / Control Panel / Administrative Tools / Computer Management /\n Local Users and Groups / Groups / ORA_DBA\n Start / Settings / Control Panel / Administrative Tools / Computer Management /\n Local Users and Groups / Groups / ORA_[SID]_DBA (if present)\n\n Note: Users assigned DBA privileges on a Windows host are granted membership in\n the ORA_DBA and/or ORA_[SID]_DBA groups. The ORA_DBA group grants DBA\n privileges to any database on the system. The ORA_[SID]_DBA groups grant DBA\n privileges to specific Oracle instances only.\n\n Make a note of each user listed. For each user (click or select):\n Start / Settings / Control Panel / Administrative Tools / Computer Management /\n Local Users and Groups / Users / [DBA user name] / Member of\n\n If DBA users belong to any groups other than DBA groups and the Windows Users\n group, this is a finding.\n\n Examine User Rights assigned to DBA groups or group members:\n Start / Settings / Control Panel / Administrative Tools / Local Security Policy\n / Security Settings / Local Policies / User Rights Assignments\n\n If any User Rights are assigned directly to the DBA group(s) or DBA user\n accounts, this is a finding.", + "fix": "Revoke all host system privileges from the DBA group accounts and\n DBA user accounts not required for DBMS administration.\n\n Revoke all OS group memberships that assign excessive privileges to the DBA\n group accounts and DBA user accounts.\n\n Remove any directly applied permissions or user rights from the DBA group\n accounts and DBA user accounts.\n\n Document all DBA group accounts and individual DBA account-assigned privileges\n in the System Security Plan." }, - "code": "control 'V-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-61537' do\n title \"DBA OS accounts must be granted only those host system privileges\n necessary for the administration of the DBMS.\"\n desc \"This requirement is intended to limit exposure due to operating from\n within a privileged account or role. The inclusion of role is intended to\n address those situations where an access control policy, such as Role Based\n Access Control (RBAC), is being implemented and where a change of role provides\n the same degree of assurance in the change of access authorizations for both\n the user and all processes acting on behalf of the user as would be provided by\n a change between a privileged and non-privileged account.\n\n DBAs, if assigned excessive OS privileges, could perform actions that could\n endanger the information system or hide evidence of malicious activity.\n \"\n impact 0.7\n tag \"gtitle\": 'SRG-APP-000063-DB-000021'\n tag \"gid\": 'V-61537'\n tag \"rid\": 'SV-76027r1_rule'\n tag \"stig_id\": 'O121-C1-004500'\n tag \"fix_id\": 'F-67453r1_fix'\n tag \"cci\": ['CCI-000366']\n tag \"nist\": ['CM-6 b', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Review host system privileges assigned to the Oracle DBA group\n and all individual Oracle DBA accounts.\n\n Note: do not include the Oracle software installation account in any results\n for this check.\n\n For UNIX systems (as root):\n cat /etc/group | grep -i dba\n groups root\n\n If \\\"root\\\" is returned in the first list, this is a finding.\n\n If any accounts listed in the first list are also listed in the second list,\n this is a finding.\n\n Investigate any user account group memberships other than DBA or root groups\n that are returned by the following command (also as root):\n\n groups [dba user account]\n\n Replace [dba user account] with the user account name of each DBA account.\n\n If individual DBA accounts are assigned to groups that grant access or\n privileges for purposes other than DBA responsibilities, this is a finding.\n\n For Windows Systems (click or select):\n Start / Settings / Control Panel / Administrative Tools / Computer Management /\n Local Users and Groups / Groups / ORA_DBA\n Start / Settings / Control Panel / Administrative Tools / Computer Management /\n Local Users and Groups / Groups / ORA_[SID]_DBA (if present)\n\n Note: Users assigned DBA privileges on a Windows host are granted membership in\n the ORA_DBA and/or ORA_[SID]_DBA groups. The ORA_DBA group grants DBA\n privileges to any database on the system. The ORA_[SID]_DBA groups grant DBA\n privileges to specific Oracle instances only.\n\n Make a note of each user listed. For each user (click or select):\n Start / Settings / Control Panel / Administrative Tools / Computer Management /\n Local Users and Groups / Users / [DBA user name] / Member of\n\n If DBA users belong to any groups other than DBA groups and the Windows Users\n group, this is a finding.\n\n Examine User Rights assigned to DBA groups or group members:\n Start / Settings / Control Panel / Administrative Tools / Local Security Policy\n / Security Settings / Local Policies / User Rights Assignments\n\n If any User Rights are assigned directly to the DBA group(s) or DBA user\n accounts, this is a finding.\"\n tag \"fix\": \"Revoke all host system privileges from the DBA group accounts and\n DBA user accounts not required for DBMS administration.\n\n Revoke all OS group memberships that assign excessive privileges to the DBA\n group accounts and DBA user accounts.\n\n Remove any directly applied permissions or user rights from the DBA group\n accounts and DBA user accounts.\n\n Document all DBA group accounts and individual DBA account-assigned privileges\n in the System Security Plan.\"\n\n get_dba_users = command('cat /etc/group | grep -i dba').stdout.strip.split(\"\\n\")\n get_members_root_group = command('groups root').stdout.strip.split(\"\\n\")\n\n get_dba_users.each do |user|\n describe \"The dba user: #{user} in /etc/group\" do\n subject { user }\n it { should_not cmp 'root' }\n end\n\n get_members_root_group.each do |member|\n describe \"The user: #{member} in the root group\" do\n subject { member }\n it { should_not cmp user.to_s }\n end\n end\n end\n if get_dba_users.empty?\n describe 'There are no dba users, therefore this control is NA' do\n skip 'There are no dba users, therefore this control is NA'\n end\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61687.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61537.rb", "line": 1 }, - "id": "V-61687" + "id": "V-61537" }, { - "title": "The DBMS host platform and other dependent applications must be\n configured in compliance with applicable STIG requirements.", - "desc": "The security of the data stored in the DBMS is also vulnerable to\n attacks against the host platform, calling applications, and other application\n or optional components.", + "title": "Credentials stored and used by the DBMS to access remote databases or\n applications must be authorized and restricted to authorized users.", + "desc": "Credentials defined for access to remote databases or applications may\n provide unauthorized access to additional databases and applications to\n unauthorized or malicious users.", "descriptions": { - "default": "The security of the data stored in the DBMS is also vulnerable to\n attacks against the host platform, calling applications, and other application\n or optional components." + "default": "Credentials defined for access to remote databases or applications may\n provide unauthorized access to additional databases and applications to\n unauthorized or malicious users." }, - "impact": 0.5, + "impact": 0, "refs": [], "tags": { "gtitle": "SRG-APP-000516-DB-999900", - "gid": "V-61491", - "rid": "SV-75981r1_rule", - "stig_id": "O121-BP-024300", - "fix_id": "F-67407r1_fix", + "gid": "V-61507", + "rid": "SV-75997r1_rule", + "stig_id": "O121-BP-025200", + "fix_id": "F-67423r1_fix", "cci": [ "CCI-000366" ], @@ -5810,35 +5852,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "If the DBMS host being reviewed is not a production DBMS host,\n this check is not a finding.\n\n Review evidence of security hardening and auditing of the DBMS host platform\n with the ISSO.\n\n If the DBMS host platform has not been hardened and received a security audit,\n this is a finding.\n\n Review evidence of security hardening and auditing for all application(s) that\n store data in the database and all other separately configured components that\n access the database including web servers, application servers, report servers,\n etc.\n\n If any have not been hardened and received a security audit, this is a finding.\n\n Review evidence of security hardening and auditing for all application(s)\n installed on the local DBMS host where security hardening and auditing guidance\n exists.\n\n If any have not been hardened and received a security audit, this is a finding.", - "fix": "Configure all related application components and the DBMS host\n platform in accordance with the applicable DoD STIG.\n\n Regularly audit the security configuration of related applications and the host\n platform to confirm continued compliance with security requirements." + "check": "Review the list of defined database links generated from the\n DBMS.\n\n Compare to the list in the System Security Plan with the DBA.\n\n If no database links are listed in the database and in the System Security\n Plan, this check is not a finding.\n\n If any database links are defined in the DBMS, verify the authorization for the\n definition in the System Security Plan.\n\n If any database links exist that are not authorized or not listed in the System\n Security Plan, this is a finding.", + "fix": "Grant access to database links to authorized users or\n applications only.\n\n Document all database links access authorizations in the System Security Plan." }, - "code": "control 'V-61491' do\n title \"The DBMS host platform and other dependent applications must be\n configured in compliance with applicable STIG requirements.\"\n desc \"The security of the data stored in the DBMS is also vulnerable to\n attacks against the host platform, calling applications, and other application\n or optional components.\"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000516-DB-999900'\n tag \"gid\": 'V-61491'\n tag \"rid\": 'SV-75981r1_rule'\n tag \"stig_id\": 'O121-BP-024300'\n tag \"fix_id\": 'F-67407r1_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 host being reviewed is not a production DBMS host,\n this check is not a finding.\n\n Review evidence of security hardening and auditing of the DBMS host platform\n with the ISSO.\n\n If the DBMS host platform has not been hardened and received a security audit,\n this is a finding.\n\n Review evidence of security hardening and auditing for all application(s) that\n store data in the database and all other separately configured components that\n access the database including web servers, application servers, report servers,\n etc.\n\n If any have not been hardened and received a security audit, this is a finding.\n\n Review evidence of security hardening and auditing for all application(s)\n installed on the local DBMS host where security hardening and auditing guidance\n exists.\n\n If any have not been hardened and received a security audit, this is a finding.\"\n tag \"fix\": \"Configure all related application components and the DBMS host\n platform in accordance with the applicable DoD STIG.\n\n Regularly audit the security configuration of related applications and the host\n platform to confirm continued compliance with security requirements.\"\n describe 'A manual review is required to ensure the DBMS host platform and other dependent applications are\n configured in compliance with applicable STIG requirements' do\n skip 'A manual review is required to ensure the DBMS host platform and other dependent applications are\n configured in compliance with applicable STIG requirements'\n end\nend\n", + "code": "control 'V-61507' do\n title \"Credentials stored and used by the DBMS to access remote databases or\n applications must be authorized and restricted to authorized users.\"\n desc \"Credentials defined for access to remote databases or applications may\n provide unauthorized access to additional databases and applications to\n unauthorized or malicious users.\"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000516-DB-999900'\n tag \"gid\": 'V-61507'\n tag \"rid\": 'SV-75997r1_rule'\n tag \"stig_id\": 'O121-BP-025200'\n tag \"fix_id\": 'F-67423r1_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 list of defined database links generated from the\n DBMS.\n\n Compare to the list in the System Security Plan with the DBA.\n\n If no database links are listed in the database and in the System Security\n Plan, this check is not a finding.\n\n If any database links are defined in the DBMS, verify the authorization for the\n definition in the System Security Plan.\n\n If any database links exist that are not authorized or not listed in the System\n Security Plan, this is a finding.\"\n tag \"fix\": \"Grant access to database links to authorized users or\n applications only.\n\n Document all database links access authorizations in the System Security Plan.\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n db_links = sql.query('SELECT DB_LINK FROM DBA_DB_LINKS;').column('db_link').uniq\n if db_links.empty?\n impact 0.0\n describe 'There are no oracle database links defined, control N/A' do\n skip 'There are no oracle database links defined, control N/A'\n end\n else\n db_links.each do |link|\n describe \"The defined oracle database link: #{link}\" do\n subject { link }\n it { should be_in input('allowed_db_links') }\n end\n end\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61491.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61507.rb", "line": 1 }, - "id": "V-61491" + "id": "V-61507" }, { - "title": "The DBMS itself, or the logging or alerting mechanism the application\n utilizes, must provide a warning when allocated audit record storage volume\n reaches an organization-defined percentage of maximum audit record storage\n capacity.", - "desc": "It is critical for the appropriate personnel to be aware if a system\n is at risk of failing to process audit logs as required. Audit processing\n failures include: software/hardware errors, failures in the audit capturing\n mechanisms, and audit storage capacity being reached or exceeded.\n\n If audit log capacity were to be exceeded, then events subsequently\n occurring would not be recorded. Organizations shall define a maximum allowable\n percentage of storage capacity serving as an alarming threshold (e.g.,\n application has exceeded 80% of log storage capacity allocated) at which time\n the application or the logging mechanism the application utilizes will provide\n a warning to the appropriate personnel.\n\n A failure of database auditing will result in either the database\n continuing to function without auditing or in a complete halt to database\n operations. When audit processing fails, appropriate personnel must be alerted\n immediately to avoid further downtime or unaudited transactions. This can be\n an alert provided by the database, a log repository, or the OS when a\n designated log directory is nearing capacity.", + "title": "The DBMS must restrict error messages so only authorized personnel may\n view them.", + "desc": "If the application provides too much information in error logs and\n administrative messages to the screen, this could lead to compromise. The\n structure and content of error messages need to be carefully considered by the\n organization and development team. The extent to which the information system\n is able to identify and handle error conditions is guided by organizational\n policy and operational requirements.\n\n Some default DBMS error messages can contain information that could aid an\n attacker in, among others things, identifying the database type, host address,\n or state of the database. Custom errors may contain sensitive customer\n information. It is important that error messages are displayed only to those\n who are authorized to view them.\n\n This calls for inspection of application source code, which will require\n collaboration with the application developers. It is recognized that in many\n cases, the database administrator (DBA) is organizationally separate from the\n application developers and may have limited, if any, access to source code.\n Nevertheless, protections of this type are so important to the secure operation\n of databases that they must not be ignored. At a minimum, the DBA must attempt\n to obtain assurances from the development organization that this issue has been\n addressed and must document what has been discovered.", "descriptions": { - "default": "It is critical for the appropriate personnel to be aware if a system\n is at risk of failing to process audit logs as required. Audit processing\n failures include: software/hardware errors, failures in the audit capturing\n mechanisms, and audit storage capacity being reached or exceeded.\n\n If audit log capacity were to be exceeded, then events subsequently\n occurring would not be recorded. Organizations shall define a maximum allowable\n percentage of storage capacity serving as an alarming threshold (e.g.,\n application has exceeded 80% of log storage capacity allocated) at which time\n the application or the logging mechanism the application utilizes will provide\n a warning to the appropriate personnel.\n\n A failure of database auditing will result in either the database\n continuing to function without auditing or in a complete halt to database\n operations. When audit processing fails, appropriate personnel must be alerted\n immediately to avoid further downtime or unaudited transactions. This can be\n an alert provided by the database, a log repository, or the OS when a\n designated log directory is nearing capacity." + "default": "If the application provides too much information in error logs and\n administrative messages to the screen, this could lead to compromise. The\n structure and content of error messages need to be carefully considered by the\n organization and development team. The extent to which the information system\n is able to identify and handle error conditions is guided by organizational\n policy and operational requirements.\n\n Some default DBMS error messages can contain information that could aid an\n attacker in, among others things, identifying the database type, host address,\n or state of the database. Custom errors may contain sensitive customer\n information. It is important that error messages are displayed only to those\n who are authorized to view them.\n\n This calls for inspection of application source code, which will require\n collaboration with the application developers. It is recognized that in many\n cases, the database administrator (DBA) is organizationally separate from the\n application developers and may have limited, if any, access to source code.\n Nevertheless, protections of this type are so important to the secure operation\n of databases that they must not be ignored. At a minimum, the DBA must attempt\n to obtain assurances from the development organization that this issue has been\n addressed and must document what has been discovered." }, "impact": 0.5, "refs": [], "tags": { - "gtitle": "SRG-APP-000103-DB-000050", - "gid": "V-61643", - "rid": "SV-76133r2_rule", - "stig_id": "O121-C2-008200", - "fix_id": "F-67555r1_fix", + "gtitle": "SRG-APP-000267-DB-000163", + "gid": "V-61793", + "rid": "SV-76283r2_rule", + "stig_id": "O121-C2-020000", + "fix_id": "F-67709r2_fix", "cci": [ - "CCI-001855" + "CCI-001314" ], "nist": [ - "AU-5 (1)", + "SI-11 b", "Rev_4" ], "false_negatives": null, @@ -5851,34 +5893,30 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Review DBMS, OS, or third-party logging application settings to\n determine whether a warning will be provided when a specific percentage of log\n storage capacity is reached.\n\n If no warning will be provided, this is a finding.", - "fix": "Modify DBMS, OS, or third-party logging application settings to\n alert appropriate personnel when a specific percentage of log storage capacity\n is reached.\n\n For ease of management, it is recommended that the audit tables be kept in a\n dedicated tablespace.\n\n If Oracle Enterprise Manager is in use, the capability to issue such an alert\n is built in and configurable via the console so an email can be sent to a\n designated administrator.\n\n If Enterprise Manager is unavailable, the following script can be used to\n monitor storage space; this can be combined with additional code to email the\n appropriate administrator so they can take action.\n\n sqlplus connect as sysdba\n\n set pagesize 300\n set linesize 120\n column sumb format 9,999,999,999,999\n column extents format 999999\n column bytes format 9,999,999,999,999\n column largest format 9,999,999,999,999\n column Tot_Size format 9,999,999,999,999\n column Tot_Free format 9,999,999,999,999\n column Pct_Free format 9,999,999,999,999\n column Chunks_Free format 9,999,999,999,999\n column Max_Free format 9,999,999,999,999\n set echo off\n spool TSINFO.txt\n PROMPT SPACE AVAILABLE IN TABLESPACES\n select a.tablespace_name,sum(a.tots) Tot_Size,\n sum(a.sumb) Tot_Free,\n sum(a.sumb)*100/sum(a.tots) Pct_Free,\n sum(a.largest) Max_Free,sum(a.chunks) Chunks_Free\n from\n (\n select tablespace_name,0 tots,sum(bytes) sumb,\n max(bytes) largest,count(*) chunks\n from dba_free_space a\n group by tablespace_name\n union\n select tablespace_name,sum(bytes) tots,0,0,0 from\n dba_data_files\n group by tablespace_name) a\n group by a.tablespace_name;\n\n Sample Output\n\n SPACE AVAILABLE IN TABLESPACES\n\n TABLESPACE_NAME TOT_SIZE TOT_FREE PCT_FREE MAX_FREE\n CHUNKS_FREE\n ------------------------ ------------ ------------ ------------\n ------------ ------------\n DES2 41,943,040 30,935,040 74\n 30,935,040 1\n DES2_I 31,457,280 23,396,352 74\n 23,396,352 1\n RBS 60,817,408 57,085,952 94\n 52,426,752 16\n SYSTEM 94,371,840 5,386,240 6\n 5,013,504 3\n TEMP 563,200 561,152 100\n 133,120 5\n TOOLS 120,586,240 89,407,488 74\n 78,190,592 12\n USERS 1,048,576 26,624 3\n 26,624 1" + "check": "Check DBMS settings and custom database code to determine if\n error messages are ever displayed to unauthorized individuals:\n\n i) Review all end-user-facing applications that use the database, to determine\n whether they display any DBMS-generated error messages to general users. If\n they do, this is a finding.\n\n ii) Review whether the database is accessible to users who are not authorized\n system administrators or database administrators, via the following types of\n software:\n iia) Oracle SQL*Plus\n iib) Reporting and analysis tools\n iic) Database management and/or development tools, such as, but not limited to,\n Toad.\n iid) Application development tools, such as, but not limited to, Oracle\n JDeveloper, Microsoft Visual Studio, PowerBuilder, or Eclipse.\n\n If the answer to the preceding question (iia through iid) is Yes, inquire\n whether, for each role or individual with respect to each tool, this access is\n required to enable the user(s) to perform authorized job duties. If No, this\n is a finding. If Yes, continue:\n\n For each tool in use, determine whether it is capable of suppressing\n DBMS-generated error messages, and if it is, whether it is configured to do so.\n\n Determine whether the role or individual, with respect to each tool, needs to\n see detailed DBMS-generated error messages.\n\n If No, and if the tool is not configured to suppress such messages, this is a\n finding.\n\n If Yes, determine whether the role/user's need to see such messages is\n documented in the System Security Plan. If so, this is not a finding. If not,\n this is a finding.", + "fix": "i) For each end-user-facing application that displays\n DBMS-generated error messages, configure or recode it to suppress these\n messages.\n\n If the application is coded in Oracle PL/SQL, the EXCEPTION block can be used\n to suppress or divert error messages. Most other programming languages provide\n comparable facilities, such as TRY ... CATCH.\n\n ii) For each unauthorized user of each tool, remove the ability to access it.\n For each tool where access to DBMS error messages is not required and can be\n configured, suppress the messages. For each role/user that needs access to the\n error messages, or needs a tool where the messages cannot be suppressed,\n document the need in the system security plan." }, - "code": "control 'V-61643' do\n title \"The DBMS itself, or the logging or alerting mechanism the application\n utilizes, must provide a warning when allocated audit record storage volume\n reaches an organization-defined percentage of maximum audit record storage\n capacity.\"\n desc \"It is critical for the appropriate personnel to be aware if a system\n is at risk of failing to process audit logs as required. Audit processing\n failures include: software/hardware errors, failures in the audit capturing\n mechanisms, and audit storage capacity being reached or exceeded.\n\n If audit log capacity were to be exceeded, then events subsequently\n occurring would not be recorded. Organizations shall define a maximum allowable\n percentage of storage capacity serving as an alarming threshold (e.g.,\n application has exceeded 80% of log storage capacity allocated) at which time\n the application or the logging mechanism the application utilizes will provide\n a warning to the appropriate personnel.\n\n A failure of database auditing will result in either the database\n continuing to function without auditing or in a complete halt to database\n operations. When audit processing fails, appropriate personnel must be alerted\n immediately to avoid further downtime or unaudited transactions. This can be\n an alert provided by the database, a log repository, or the OS when a\n designated log directory is nearing capacity.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000103-DB-000050'\n tag \"gid\": 'V-61643'\n tag \"rid\": 'SV-76133r2_rule'\n tag \"stig_id\": 'O121-C2-008200'\n tag \"fix_id\": 'F-67555r1_fix'\n tag \"cci\": ['CCI-001855']\n tag \"nist\": ['AU-5 (1)', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Review DBMS, OS, or third-party logging application settings to\n determine whether a warning will be provided when a specific percentage of log\n storage capacity is reached.\n\n If no warning will be provided, this is a finding.\"\n tag \"fix\": \"Modify DBMS, OS, or third-party logging application settings to\n alert appropriate personnel when a specific percentage of log storage capacity\n is reached.\n\n For ease of management, it is recommended that the audit tables be kept in a\n dedicated tablespace.\n\n If Oracle Enterprise Manager is in use, the capability to issue such an alert\n is built in and configurable via the console so an email can be sent to a\n designated administrator.\n\n If Enterprise Manager is unavailable, the following script can be used to\n monitor storage space; this can be combined with additional code to email the\n appropriate administrator so they can take action.\n\n sqlplus connect as sysdba\n\n set pagesize 300\n set linesize 120\n column sumb format 9,999,999,999,999\n column extents format 999999\n column bytes format 9,999,999,999,999\n column largest format 9,999,999,999,999\n column Tot_Size format 9,999,999,999,999\n column Tot_Free format 9,999,999,999,999\n column Pct_Free format 9,999,999,999,999\n column Chunks_Free format 9,999,999,999,999\n column Max_Free format 9,999,999,999,999\n set echo off\n spool TSINFO.txt\n PROMPT SPACE AVAILABLE IN TABLESPACES\n select a.tablespace_name,sum(a.tots) Tot_Size,\n sum(a.sumb) Tot_Free,\n sum(a.sumb)*100/sum(a.tots) Pct_Free,\n sum(a.largest) Max_Free,sum(a.chunks) Chunks_Free\n from\n (\n select tablespace_name,0 tots,sum(bytes) sumb,\n max(bytes) largest,count(*) chunks\n from dba_free_space a\n group by tablespace_name\n union\n select tablespace_name,sum(bytes) tots,0,0,0 from\n dba_data_files\n group by tablespace_name) a\n group by a.tablespace_name;\n\n Sample Output\n\n SPACE AVAILABLE IN TABLESPACES\n\n TABLESPACE_NAME TOT_SIZE TOT_FREE PCT_FREE MAX_FREE\n CHUNKS_FREE\n ------------------------ ------------ ------------ ------------\n ------------ ------------\n DES2 41,943,040 30,935,040 74\n 30,935,040 1\n DES2_I 31,457,280 23,396,352 74\n 23,396,352 1\n RBS 60,817,408 57,085,952 94\n 52,426,752 16\n SYSTEM 94,371,840 5,386,240 6\n 5,013,504 3\n TEMP 563,200 561,152 100\n 133,120 5\n TOOLS 120,586,240 89,407,488 74\n 78,190,592 12\n USERS 1,048,576 26,624 3\n 26,624 1\"\n\n describe 'A manual review is required to ensure the DBMS itself, or the logging or alerting mechanism the application\n utilizes, provides a warning when allocated audit record storage volume\n reaches an organization-defined percentage of maximum audit record storage\n capacity.' do\n skip 'A manual review is required to ensure the DBMS itself, or the logging or alerting mechanism the application\n utilizes, provides a warning when allocated audit record storage volume\n reaches an organization-defined percentage of maximum audit record storage\n capacity.'\n end\nend\n", + "code": "control 'V-61793' do\n title \"The DBMS must restrict error messages so only authorized personnel may\n view them.\"\n desc \"If the application provides too much information in error logs and\n administrative messages to the screen, this could lead to compromise. The\n structure and content of error messages need to be carefully considered by the\n organization and development team. The extent to which the information system\n is able to identify and handle error conditions is guided by organizational\n policy and operational requirements.\n\n Some default DBMS error messages can contain information that could aid an\n attacker in, among others things, identifying the database type, host address,\n or state of the database. Custom errors may contain sensitive customer\n information. It is important that error messages are displayed only to those\n who are authorized to view them.\n\n This calls for inspection of application source code, which will require\n collaboration with the application developers. It is recognized that in many\n cases, the database administrator (DBA) is organizationally separate from the\n application developers and may have limited, if any, access to source code.\n Nevertheless, protections of this type are so important to the secure operation\n of databases that they must not be ignored. At a minimum, the DBA must attempt\n to obtain assurances from the development organization that this issue has been\n addressed and must document what has been discovered.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000267-DB-000163'\n tag \"gid\": 'V-61793'\n tag \"rid\": 'SV-76283r2_rule'\n tag \"stig_id\": 'O121-C2-020000'\n tag \"fix_id\": 'F-67709r2_fix'\n tag \"cci\": ['CCI-001314']\n tag \"nist\": ['SI-11 b', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Check DBMS settings and custom database code to determine if\n error messages are ever displayed to unauthorized individuals:\n\n i) Review all end-user-facing applications that use the database, to determine\n whether they display any DBMS-generated error messages to general users. If\n they do, this is a finding.\n\n ii) Review whether the database is accessible to users who are not authorized\n system administrators or database administrators, via the following types of\n software:\n iia) Oracle SQL*Plus\n iib) Reporting and analysis tools\n iic) Database management and/or development tools, such as, but not limited to,\n Toad.\n iid) Application development tools, such as, but not limited to, Oracle\n JDeveloper, Microsoft Visual Studio, PowerBuilder, or Eclipse.\n\n If the answer to the preceding question (iia through iid) is Yes, inquire\n whether, for each role or individual with respect to each tool, this access is\n required to enable the user(s) to perform authorized job duties. If No, this\n is a finding. If Yes, continue:\n\n For each tool in use, determine whether it is capable of suppressing\n DBMS-generated error messages, and if it is, whether it is configured to do so.\n\n Determine whether the role or individual, with respect to each tool, needs to\n see detailed DBMS-generated error messages.\n\n If No, and if the tool is not configured to suppress such messages, this is a\n finding.\n\n If Yes, determine whether the role/user's need to see such messages is\n documented in the System Security Plan. If so, this is not a finding. If not,\n this is a finding.\"\n tag \"fix\": \"i) For each end-user-facing application that displays\n DBMS-generated error messages, configure or recode it to suppress these\n messages.\n\n If the application is coded in Oracle PL/SQL, the EXCEPTION block can be used\n to suppress or divert error messages. Most other programming languages provide\n comparable facilities, such as TRY ... CATCH.\n\n ii) For each unauthorized user of each tool, remove the ability to access it.\n For each tool where access to DBMS error messages is not required and can be\n configured, suppress the messages. For each role/user that needs access to the\n error messages, or needs a tool where the messages cannot be suppressed,\n document the need in the system security plan.\"\n describe 'A manual review is required to ensure the DBMS restricts error messages so only authorized personnel may\n view them' do\n skip 'A manual review is required to ensure the DBMS restricts error messages so only authorized personnel may\n view them'\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61643.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61793.rb", "line": 1 }, - "id": "V-61643" + "id": "V-61793" }, { - "title": "Remote DBMS administration must be documented and authorized or\n disabled.", - "desc": "Remote administration may expose configuration and sensitive data to\n unauthorized viewing during transit across the network or allow unauthorized\n administrative access to the DBMS to remote users.\n\n For the purposes of this STIG, \"Remote\" means \"outside the DoDIN.\"\n However, use of an approved and properly configured VPN counts as inside the\n DoDIN.", + "title": "Fixed user and public database links must be authorized for use.", + "desc": "Database links define connections that may be used by the local\n database to access remote Oracle databases. These links provide a means for a\n compromise to the local database to spread to remote databases in the\n distributed database environment. Limiting or eliminating use of database links\n where they are not required to support the operational system can help isolate\n compromises to the local or a limited number of databases.", "descriptions": { - "default": "Remote administration may expose configuration and sensitive data to\n unauthorized viewing during transit across the network or allow unauthorized\n administrative access to the DBMS to remote users.\n\n For the purposes of this STIG, \"Remote\" means \"outside the DoDIN.\"\n However, use of an approved and properly configured VPN counts as inside the\n DoDIN." + "default": "Database links define connections that may be used by the local\n database to access remote Oracle databases. These links provide a means for a\n compromise to the local database to spread to remote databases in the\n distributed database environment. Limiting or eliminating use of database links\n where they are not required to support the operational system can help isolate\n compromises to the local or a limited number of databases." }, "impact": 0, - "refs": [ - { - "ref": [] - } - ], + "refs": [], "tags": { "gtitle": "SRG-APP-000516-DB-999900", - "gid": "V-61523", - "rid": "SV-76013r3_rule", - "stig_id": "O121-BP-026000", - "fix_id": "F-67439r4_fix", + "gid": "V-61415", + "rid": "SV-75905r2_rule", + "stig_id": "O121-BP-021400", + "fix_id": "F-67331r1_fix", "cci": [ "CCI-000366" ], @@ -5896,35 +5934,39 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Review the System Security Plan for authorization, assignments\n and usage procedures for remote DBMS administration.\n\n If remote administration of the DBMS is not documented or poorly documented,\n this is a finding.\n\n If remote administration of the DBMS is not authorized and not disabled, this\n is a finding.\n\n If remote administration is to be performed from outside the DoDIN, but is not\n done via an approved and properly configured VPN, this is a finding.", - "fix": "Disable remote administration of the DBMS where not required.\n\n Where remote administration of the DBMS is required, develop, document and\n implement policy and procedures on its use.\n\n Assign remote administration privileges to ISSO-authorized personnel only.\n\n Document assignments in the System Security Plan.\n\n Where remote administration is to be performed from outside the DoDIN,\n configure an approved VPN client for this purpose." + "check": "From SQL*Plus:\n\n select owner||': '||db_link from dba_db_links;\n\n If no records are returned from the first SQL statement, this check is not a\n finding.\n\n Confirm the public and fixed user database links listed are documented in the\n System Security Plan, are authorized by the ISSO, and are used for replication\n or operational system requirements.\n\n If any are not, this is a finding.\n ", + "fix": "Document all authorized connections from the database to remote\n databases in the System Security Plan.\n\n Remove all unauthorized remote database connection definitions from the\n database.\n\n From SQL*Plus:\n\n drop database link [link name];\n OR\n drop public database link [link name];\n\n Review remote database connection definitions periodically and confirm their\n use is still required and authorized." }, - "code": " control 'V-61523' 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-61415' do\n title 'Fixed user and public database links must be authorized for use.'\n desc \"Database links define connections that may be used by the local\n database to access remote Oracle databases. These links provide a means for a\n compromise to the local database to spread to remote databases in the\n distributed database environment. Limiting or eliminating use of database links\n where they are not required to support the operational system can help isolate\n compromises to the local or a limited number of databases.\"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000516-DB-999900'\n tag \"gid\": 'V-61415'\n tag \"rid\": 'SV-75905r2_rule'\n tag \"stig_id\": 'O121-BP-021400'\n tag \"fix_id\": 'F-67331r1_fix'\n tag \"cci\": ['CCI-000366']\n tag \"nist\": ['CM-6 b', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"From SQL*Plus:\n\n select owner||': '||db_link from dba_db_links;\n\n If no records are returned from the first SQL statement, this check is not a\n finding.\n\n Confirm the public and fixed user database links listed are documented in the\n System Security Plan, are authorized by the ISSO, and are used for replication\n or operational system requirements.\n\n If any are not, this is a finding.\n \"\n tag \"fix\": \"Document all authorized connections from the database to remote\n databases in the System Security Plan.\n\n Remove all unauthorized remote database connection definitions from the\n database.\n\n From SQL*Plus:\n\n drop database link [link name];\n OR\n drop public database link [link name];\n\n Review remote database connection definitions periodically and confirm their\n use is still required and authorized.\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n db_links = sql.query('SELECT DB_LINK FROM DBA_DB_LINKS;').column('db_link').uniq\n if db_links.empty?\n impact 0.0\n describe 'There are no oracle database links defined, control N/A' do\n skip 'There are no oracle database links defined, control N/A'\n end\n else\n db_links.each do |link|\n describe \"The defined oracle database link: #{link}\" do\n subject { link }\n it { should be_in input('allowed_db_links') }\n end\n end\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61523.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61415.rb", "line": 1 }, - "id": "V-61523" + "id": "V-61415" }, { - "title": "The system must protect audit information from unauthorized\n modification.", - "desc": "If audit data were to become compromised, then competent forensic\n analysis and discovery of the true source of potentially malicious system\n activity is impossible to achieve.\n\n To ensure the veracity of audit data, the information system and/or the\n application must protect audit information from unauthorized modification.\n\n This requirement can be achieved through multiple methods which will depend\n upon system architecture and design. Some commonly employed methods include\n ensuring log files enjoy the proper file system permissions and limiting log\n data locations.\n\n Applications providing a user interface to audit data will leverage user\n permissions and roles identifying the user accessing the data and the\n corresponding rights that the user enjoys in order to make access decisions\n regarding the modification of audit data.\n\n Audit information includes all information (e.g., audit records, audit\n settings, and audit reports) needed to successfully audit information system\n activity.\n\n Modification of database audit data could mask the theft of, or the\n unauthorized modification of, sensitive data stored in the database.", + "title": "The DBMS, when utilizing PKI-based authentication, must validate\n certificates by constructing a certification path with status information to an\n accepted trust anchor.", + "desc": "A trust anchor is an authoritative entity represented via a public key\n and associated data. It is used in the context of public key infrastructures,\n X.509 digital certificates, and DNSSEC.\n\n When there is a chain of trust, usually the top entity to be trusted\n becomes the trust anchor; it can be for example a Certification Authority (CA).\n A certification path starts with the Subject certificate and proceeds through a\n number of intermediate certificates up to a trusted root certificate, typically\n issued by a trusted CA.\n\n Path validation is necessary for a relying party to make an informed trust\n decision when presented with any certificate not already explicitly trusted.\n\n Status information for certification paths includes certificate revocation\n lists or online certificate status protocol responses.\n\n Database Management Systems that do not validate certificates to a trust\n anchor are in danger of accepting certificates that are invalid and/or\n counterfeit. This could allow unauthorized access to the database.\n\n Transport Layer Security (TLS) is the successor protocol to Secure Sockets\n Layer (SSL). Although the Oracle configuration parameters have names including\n 'SSL', such as SSL_VERSION and SSL_CIPHER_SUITES, they refer to TLS.", "descriptions": { - "default": "If audit data were to become compromised, then competent forensic\n analysis and discovery of the true source of potentially malicious system\n activity is impossible to achieve.\n\n To ensure the veracity of audit data, the information system and/or the\n application must protect audit information from unauthorized modification.\n\n This requirement can be achieved through multiple methods which will depend\n upon system architecture and design. Some commonly employed methods include\n ensuring log files enjoy the proper file system permissions and limiting log\n data locations.\n\n Applications providing a user interface to audit data will leverage user\n permissions and roles identifying the user accessing the data and the\n corresponding rights that the user enjoys in order to make access decisions\n regarding the modification of audit data.\n\n Audit information includes all information (e.g., audit records, audit\n settings, and audit reports) needed to successfully audit information system\n activity.\n\n Modification of database audit data could mask the theft of, or the\n unauthorized modification of, sensitive data stored in the database." + "default": "A trust anchor is an authoritative entity represented via a public key\n and associated data. It is used in the context of public key infrastructures,\n X.509 digital certificates, and DNSSEC.\n\n When there is a chain of trust, usually the top entity to be trusted\n becomes the trust anchor; it can be for example a Certification Authority (CA).\n A certification path starts with the Subject certificate and proceeds through a\n number of intermediate certificates up to a trusted root certificate, typically\n issued by a trusted CA.\n\n Path validation is necessary for a relying party to make an informed trust\n decision when presented with any certificate not already explicitly trusted.\n\n Status information for certification paths includes certificate revocation\n lists or online certificate status protocol responses.\n\n Database Management Systems that do not validate certificates to a trust\n anchor are in danger of accepting certificates that are invalid and/or\n counterfeit. This could allow unauthorized access to the database.\n\n Transport Layer Security (TLS) is the successor protocol to Secure Sockets\n Layer (SSL). Although the Oracle configuration parameters have names including\n 'SSL', such as SSL_VERSION and SSL_CIPHER_SUITES, they refer to TLS." }, "impact": 0, - "refs": [], + "refs": [ + { + "ref": [] + } + ], "tags": { - "gtitle": "SRG-APP-000119-DB-000060", - "gid": "V-61655", - "rid": "SV-76145r1_rule", - "stig_id": "O121-C2-009400", - "fix_id": "F-67569r2_fix", + "gtitle": "SRG-APP-000175-DB-000067", + "gid": "V-61741", + "rid": "SV-76231r3_rule", + "stig_id": "O121-C2-015300", + "fix_id": "F-67657r1_fix", "cci": [ - "CCI-000163" + "CCI-000185" ], "nist": [ - "AU-9", + "IA-5 (2) (a)", "Rev_4" ], "false_negatives": null, @@ -5937,35 +5979,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Review locations of audit logs, both internal to the database\n and database audit logs located at the operating system-level. Verify there are\n appropriate controls and permissions to protect the audit information from\n unauthorized modification.\n\n If appropriate controls and permissions do not exist, this is a finding.\n\n - - - - -\n If Standard Auditing is used:\n DBA_TAB_PRIVS describes all object grants in the database. Check to see who\n has permissions on the AUD$ table.\n\n Related View\n\n DBA_TAB_PRIVS describes the object grants for which the current user is the\n object owner, grantor, or grantee.\n Column Datatype NULL Description\n GRANTEE VARCHAR2(30) NOT NULL Name of the user to whom access was granted\n VARCHAR2(30) NOT NULL Owner of the object\n TABLE_NA VARCHAR2(30) NOT NULL Name of the object\n GRANTOR VARCHAR2(30) NOT NULL Name of the user who performed the grant\n PRIVILEGE VARCHAR2(40) NOT NULL Privilege on the object\n GRANTABLE VARCHAR2(3) Indicates whether the privilege was granted\n with the GRANT OPTION (YES) or not (NO)\n HIERARCHY VARCHAR2(3) Indicates whether the privilege was granted\n with the HIERARCHY OPTION (YES) or not (NO)\n COMMON VARCHAR2(3)\n TYPE VARCHAR2(24)\n\n sqlplus connect as sysdba;\n\n SQL> SELECT GRANTEE, TABLE_NAME, PRIVILEGE\n FROM DBA_TAB_PRIVS where table_name = 'AUD$';\n\n If Unified Auditing is used:\n DBA_TAB_PRIVS describes all object grants in the database. Check to see who\n has permissions on the AUDSYS tables.\n\n Related View\n\n DBA_TAB_PRIVS describes the object grants for which the current user is the\n object owner, grantor, or grantee.\n Column Datatype NULL Description\n GRANTEE VARCHAR2(30) NOT NULL Name of the user to whom access was granted\n OWNER VARCHAR2(30) NOT NULL Owner of the object\n TABLE_NAME VARCHAR2(30) NOT NULL Name of the object\n GRANTOR VARCHAR2(30) NOT NULL Name of the user who performed the grant\n PRIVILEGE VARCHAR2(40) NOT NULL Privilege on the object\n GRANTABLE VARCHAR2(3) Indicates whether the privilege was granted\n with the GRANT OPTION (YES) or not (NO)\n HIERARCHY VARCHAR2(3) Indicates whether the privilege was granted\n with the HIERARCHY OPTION (YES) or not (NO)\n COMMON VARCHAR2(3)\n TYPE VARCHAR2(24)\n\n sqlplus connect as sysdba;\n\n SQL> SELECT GRANTEE, TABLE_NAME, PRIVILEGE\n FROM DBA_TAB_PRIVS where owner='AUDSYS';", - "fix": "Add controls and modify permissions to protect database audit log\n data from unauthorized modification, whether stored in the database itself or\n at the OS level.\n\n - - - - -\n If Standard Auditing is used:\n Revoke access to the AUD$ table to anyone who should not have access to it.\n\n In the check we looked for all users who had access to the AUD$ table. To fix\n this, use the REVOKE command to revoke access to users who should not have\n access to the audit data.\n\n REVOKE statement\n\n Use the REVOKE statement to remove permissions from a specific user or from all\n users to perform actions on database objects.\n The following types of permissions can be revoked:\n\n Delete data from a specific table.\n Insert data into a specific table.\n Create a foreign key reference to the named table or to a subset of columns\n from a table.\n Select data from a table, view, or a subset of columns in a table.\n Create a trigger on a table.\n Update data in a table or in a subset of columns in a table.\n Run a specified routine (function or procedure).\n\n If a user named FRED had access to the AUD$ table and wanting to revoke that\n access, use the following command. The syntax that would be used for the REVOKE\n statement for tables is as follows:\n\n REVOKE privilege-type ON [ TABLE ] { table-Name | view-Name } FROM grantees\n\n SQL>REVOKE SELECT ON TABLE AUD$ FROM FRED;\n\n Revoking a privilege without specifying a column list revokes the privilege for\n all of the columns in the table.\n Syntax for routines\n\n table-privileges include\n\n DELETE |\n INSERT |\n REFERENCES [column list] |\n SELECT [column list] |\n TRIGGER |\n UPDATE [column list]\n\n column list\n\n ( column-identifier {, column-identifier}* )\n\n Use the ALL PRIVILEGES privilege type to revoke all of the permissions from the\n user for the specified table. Can also revoke one or more table privileges by\n specifying a privilege-list.\n\n Use the DELETE privilege type to revoke permission to delete rows from the\n specified table.\n\n Use the INSERT privilege type to revoke permission to insert rows into the\n specified table.\n\n Use the REFERENCES privilege type to revoke permission to create a foreign key\n reference to the specified table. If a column list is specified with the\n REFERENCES privilege, the permission is revoked on only the foreign key\n reference to the specified columns.\n\n Use the SELECT privilege type to revoke permission to perform SELECT statements\n on a table or view. If a column list is specified with the SELECT privilege,\n the permission is revoked on only those columns. If no column list is\n specified, then the privilege is valid on all of the columns in the table.\n\n Use the TRIGGER privilege type to revoke permission to create a trigger on the\n specified table.\n\n Use the UPDATE privilege type to revoke permission to use the UPDATE statement\n on the specified table. If a column list is specified, the permission is\n revoked only on the specified columns.\n grantees\n\n { authorization ID | PUBLIC } [,{ authorization ID | PUBLIC } ] *\n\n Can revoke the privileges from specific users or from all users. Use the\n keyword PUBLIC to specify all users. The privileges revoked from PUBLIC and\n from individual users are independent privileges. For example, a SELECT\n privilege on table t is granted to both PUBLIC and to the authorization ID\n harry. The SELECT privilege is later revoked from the authorization ID 'Harry',\n but the authorization ID 'Harry' can access the table through the PUBLIC\n privilege.\n\n Restriction: Cannot revoke the privileges of the owner of an object.\n routine-designator\n\n {\n qualified-name [ signature ]\n }\n\n Cascading object dependencies\n\n For views, triggers, and constraints, if the privilege on which the object\n depends is revoked, the object is automatically dropped. Derby does not try to\n determine if there are other privileges that can replace the privileges that\n are being revoked. For more information, see \"SQL standard authorization\" in\n the Java DB Developer's Guide.\n Limitations\n\n The following limitations apply to the REVOKE statement:\n\n Table-level privileges:\n\n All of the table-level privilege types for a specified grantee and table ID are\n stored in one row in the SYSTABLEPERMS system table. For example, when user2 is\n granted the SELECT and DELETE privileges on table user1.t1, a row is added to\n the SYSTABLEPERMS table. The GRANTEE field contains user2 and the TABLEID\n contains user1.t1. The SELECTPRIV and DELETEPRIV fields are set to Y. The\n remaining privilege type fields are set to N.\n\n When a grantee creates an object that relies on one of the privilege types, the\n Derby engine tracks the dependency of the object on the specific row in the\n SYSTABLEPERMS table. For example, user2 creates the view v1 by using the\n statement SELECT * FROM user1.t1; the dependency manager tracks the dependency\n of view v1 on the row in SYSTABLEPERMS for GRANTEE(user2), TABLEID(user1.t1).\n The dependency manager knows only that the view is dependent on a privilege\n type in that specific row but does not track exactly which privilege type the\n view is dependent on.\n\n When a REVOKE statement for a table-level privilege is issued for a grantee and\n table ID, all of the objects that are dependent on the grantee and table ID are\n dropped. For example, if user1 revokes the DELETE privilege on table t1 from\n user2, the row in SYSTABLEPERMS for GRANTEE(user2), TABLEID(user1.t1) is\n modified by the REVOKE statement. The dependency manager sends a revoke\n invalidation message to the view user2.v1, and the view is dropped, even though\n the view is not dependent on the DELETE privilege for GRANTEE(user2),\n TABLEID(user1.t1).\n\n Column-level privileges:\n\n Only one type of privilege for a specified grantee and table ID are stored in\n one row in the SYSCOLPERMS system table. For example, when user2 is granted the\n SELECT privilege on table user1.t1 for columns c12 and c13, a row is added to\n the SYSCOLPERMS. The GRANTEE field contains user2, the TABLEID contains\n user1.t1, the TYPE field contains S, and the COLUMNS field contains c12, c13.\n\n When a grantee creates an object that relies on the privilege type and the\n subset of columns in a table ID, the Derby engine tracks the dependency of the\n object on the specific row in the SYSCOLPERMS table. For example, user2 creates\n the view v1 by using the statement SELECT c11 FROM user1.t1; the dependency\n manager tracks the dependency of view v1 on the row in SYSCOLPERMS for\n GRANTEE(user2), TABLEID(user1.t1), TYPE(S). The dependency manager knows that\n the view is dependent on the SELECT privilege type but does not track exactly\n which columns the view is dependent on.\n\n When a REVOKE statement for a column-level privilege is issued for a grantee,\n table ID, and type, all of the objects that are dependent on the grantee, table\n ID, and type are dropped. For example, if user1 revokes the SELECT privilege on\n column c12 on table user1.t1 from user2, the row in SYSCOLPERMS for\n GRANTEE(user2), TABLEID(user1.t1), TYPE(S) is modified by the REVOKE statement.\n The dependency manager sends a revoke invalidation message to the view\n user2.v1, and the view is dropped, even though the view is not dependent on the\n column c12 for GRANTEE(user2), TABLEID(user1.t1), TYPE(S).\n\n If Unified Auditing is used:\n\n Apply the same process used in standard auditing to the tables with AUDSYS as\n the owner." + "check": "If PKI is not enabled in the Oracle Database, this is not a\n finding.\n\n If all accounts are authenticated by the OS or an enterprise-level\n authentication/access mechanism and not by Oracle, this is not a finding.\n\n Review DBMS configuration to verify the certificates being accepted by the DBMS\n have a valid certification path with status information to an accepted trust\n anchor.\n\n If certification paths are not being validated back to a trust anchor, this is\n a finding.\n\n - - - - -\n The database supports PKI-based authentication by using digital certificates\n over TLS in addition to the native encryption and data integrity capabilities\n of these protocols.\n\n Oracle provides a complete PKI that is based on RSA Security, Inc., Public-Key\n Cryptography Standards, and which interoperates with Oracle servers and\n clients. The database uses a wallet that is a container that is used to store\n authentication and signing credentials, including private keys, certificates,\n and trusted certificates needed by TLS. In an Oracle environment, every entity\n that communicates over TLS must have a wallet containing an X.509 version 3\n certificate, private key, and list of trusted certificates.\n\n If the $ORACLE_HOME/network/admin/sqlnet.ora contains the following entries,\n TLS is installed.\n\n WALLET_LOCATION = (SOURCE= (METHOD = FILE) (METHOD_DATA = DIRECTORY=/wallet)\n\n SSL_CIPHER_SUITES=(SSL_cipher_suiteExample)\n SSL_VERSION = 1.2 or 1.1\n SSL_CLIENT_AUTHENTICATION=TRUE\n\n (Note: This assumes that a single sqlnet.ora file, in the default location, is\n in use. Please see the supplemental file \"Non-default sqlnet.ora\n configurations.pdf\" for how to find multiple and/or differently located\n sqlnet.ora files.)\n\n Note: \"SSL_VERSION = 1.2 or 1.1\" is the actual value, not a suggestion to use\n one or the other.", + "fix": "Configure the DBMS to validate certificates by constructing a\n certification path with status information to an accepted trust anchor.\n\n Configure the database to support Transport Layer Security (TLS) protocols and\n the Oracle Wallet to store authentication and signing credentials, including\n private keys." }, - "code": "control 'V-61655' do\n title \"The system must protect audit information from unauthorized\n modification.\"\n desc \"If audit data were to become compromised, then competent forensic\n analysis and discovery of the true source of potentially malicious system\n activity is impossible to achieve.\n\n To ensure the veracity of audit data, the information system and/or the\n application must protect audit information from unauthorized modification.\n\n This requirement can be achieved through multiple methods which will depend\n upon system architecture and design. Some commonly employed methods include\n ensuring log files enjoy the proper file system permissions and limiting log\n data locations.\n\n Applications providing a user interface to audit data will leverage user\n permissions and roles identifying the user accessing the data and the\n corresponding rights that the user enjoys in order to make access decisions\n regarding the modification of audit data.\n\n Audit information includes all information (e.g., audit records, audit\n settings, and audit reports) needed to successfully audit information system\n activity.\n\n Modification of database audit data could mask the theft of, or the\n unauthorized modification of, sensitive data stored in the database.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000119-DB-000060'\n tag \"gid\": 'V-61655'\n tag \"rid\": 'SV-76145r1_rule'\n tag \"stig_id\": 'O121-C2-009400'\n tag \"fix_id\": 'F-67569r2_fix'\n tag \"cci\": ['CCI-000163']\n tag \"nist\": ['AU-9', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Review locations of audit logs, both internal to the database\n and database audit logs located at the operating system-level. Verify there are\n appropriate controls and permissions to protect the audit information from\n unauthorized modification.\n\n If appropriate controls and permissions do not exist, this is a finding.\n\n - - - - -\n If Standard Auditing is used:\n DBA_TAB_PRIVS describes all object grants in the database. Check to see who\n has permissions on the AUD$ table.\n\n Related View\n\n DBA_TAB_PRIVS describes the object grants for which the current user is the\n object owner, grantor, or grantee.\n Column Datatype NULL Description\n GRANTEE VARCHAR2(30) NOT NULL Name of the user to whom access was granted\n VARCHAR2(30) NOT NULL Owner of the object\n TABLE_NA VARCHAR2(30) NOT NULL Name of the object\n GRANTOR VARCHAR2(30) NOT NULL Name of the user who performed the grant\n PRIVILEGE VARCHAR2(40) NOT NULL Privilege on the object\n GRANTABLE VARCHAR2(3) Indicates whether the privilege was granted\n with the GRANT OPTION (YES) or not (NO)\n HIERARCHY VARCHAR2(3) Indicates whether the privilege was granted\n with the HIERARCHY OPTION (YES) or not (NO)\n COMMON VARCHAR2(3)\n TYPE VARCHAR2(24)\n\n sqlplus connect as sysdba;\n\n SQL> SELECT GRANTEE, TABLE_NAME, PRIVILEGE\n FROM DBA_TAB_PRIVS where table_name = 'AUD$';\n\n If Unified Auditing is used:\n DBA_TAB_PRIVS describes all object grants in the database. Check to see who\n has permissions on the AUDSYS tables.\n\n Related View\n\n DBA_TAB_PRIVS describes the object grants for which the current user is the\n object owner, grantor, or grantee.\n Column Datatype NULL Description\n GRANTEE VARCHAR2(30) NOT NULL Name of the user to whom access was granted\n OWNER VARCHAR2(30) NOT NULL Owner of the object\n TABLE_NAME VARCHAR2(30) NOT NULL Name of the object\n GRANTOR VARCHAR2(30) NOT NULL Name of the user who performed the grant\n PRIVILEGE VARCHAR2(40) NOT NULL Privilege on the object\n GRANTABLE VARCHAR2(3) Indicates whether the privilege was granted\n with the GRANT OPTION (YES) or not (NO)\n HIERARCHY VARCHAR2(3) Indicates whether the privilege was granted\n with the HIERARCHY OPTION (YES) or not (NO)\n COMMON VARCHAR2(3)\n TYPE VARCHAR2(24)\n\n sqlplus connect as sysdba;\n\n SQL> SELECT GRANTEE, TABLE_NAME, PRIVILEGE\n FROM DBA_TAB_PRIVS where owner='AUDSYS';\"\n tag \"fix\": \"Add controls and modify permissions to protect database audit log\n data from unauthorized modification, whether stored in the database itself or\n at the OS level.\n\n - - - - -\n If Standard Auditing is used:\n Revoke access to the AUD$ table to anyone who should not have access to it.\n\n In the check we looked for all users who had access to the AUD$ table. To fix\n this, use the REVOKE command to revoke access to users who should not have\n access to the audit data.\n\n REVOKE statement\n\n Use the REVOKE statement to remove permissions from a specific user or from all\n users to perform actions on database objects.\n The following types of permissions can be revoked:\n\n Delete data from a specific table.\n Insert data into a specific table.\n Create a foreign key reference to the named table or to a subset of columns\n from a table.\n Select data from a table, view, or a subset of columns in a table.\n Create a trigger on a table.\n Update data in a table or in a subset of columns in a table.\n Run a specified routine (function or procedure).\n\n If a user named FRED had access to the AUD$ table and wanting to revoke that\n access, use the following command. The syntax that would be used for the REVOKE\n statement for tables is as follows:\n\n REVOKE privilege-type ON [ TABLE ] { table-Name | view-Name } FROM grantees\n\n SQL>REVOKE SELECT ON TABLE AUD$ FROM FRED;\n\n Revoking a privilege without specifying a column list revokes the privilege for\n all of the columns in the table.\n Syntax for routines\n\n table-privileges include\n\n DELETE |\n INSERT |\n REFERENCES [column list] |\n SELECT [column list] |\n TRIGGER |\n UPDATE [column list]\n\n column list\n\n ( column-identifier {, column-identifier}* )\n\n Use the ALL PRIVILEGES privilege type to revoke all of the permissions from the\n user for the specified table. Can also revoke one or more table privileges by\n specifying a privilege-list.\n\n Use the DELETE privilege type to revoke permission to delete rows from the\n specified table.\n\n Use the INSERT privilege type to revoke permission to insert rows into the\n specified table.\n\n Use the REFERENCES privilege type to revoke permission to create a foreign key\n reference to the specified table. If a column list is specified with the\n REFERENCES privilege, the permission is revoked on only the foreign key\n reference to the specified columns.\n\n Use the SELECT privilege type to revoke permission to perform SELECT statements\n on a table or view. If a column list is specified with the SELECT privilege,\n the permission is revoked on only those columns. If no column list is\n specified, then the privilege is valid on all of the columns in the table.\n\n Use the TRIGGER privilege type to revoke permission to create a trigger on the\n specified table.\n\n Use the UPDATE privilege type to revoke permission to use the UPDATE statement\n on the specified table. If a column list is specified, the permission is\n revoked only on the specified columns.\n grantees\n\n { authorization ID | PUBLIC } [,{ authorization ID | PUBLIC } ] *\n\n Can revoke the privileges from specific users or from all users. Use the\n keyword PUBLIC to specify all users. The privileges revoked from PUBLIC and\n from individual users are independent privileges. For example, a SELECT\n privilege on table t is granted to both PUBLIC and to the authorization ID\n harry. The SELECT privilege is later revoked from the authorization ID 'Harry',\n but the authorization ID 'Harry' can access the table through the PUBLIC\n privilege.\n\n Restriction: Cannot revoke the privileges of the owner of an object.\n routine-designator\n\n {\n qualified-name [ signature ]\n }\n\n Cascading object dependencies\n\n For views, triggers, and constraints, if the privilege on which the object\n depends is revoked, the object is automatically dropped. Derby does not try to\n determine if there are other privileges that can replace the privileges that\n are being revoked. For more information, see \\\"SQL standard authorization\\\" in\n the Java DB Developer's Guide.\n Limitations\n\n The following limitations apply to the REVOKE statement:\n\n Table-level privileges:\n\n All of the table-level privilege types for a specified grantee and table ID are\n stored in one row in the SYSTABLEPERMS system table. For example, when user2 is\n granted the SELECT and DELETE privileges on table user1.t1, a row is added to\n the SYSTABLEPERMS table. The GRANTEE field contains user2 and the TABLEID\n contains user1.t1. The SELECTPRIV and DELETEPRIV fields are set to Y. The\n remaining privilege type fields are set to N.\n\n When a grantee creates an object that relies on one of the privilege types, the\n Derby engine tracks the dependency of the object on the specific row in the\n SYSTABLEPERMS table. For example, user2 creates the view v1 by using the\n statement SELECT * FROM user1.t1; the dependency manager tracks the dependency\n of view v1 on the row in SYSTABLEPERMS for GRANTEE(user2), TABLEID(user1.t1).\n The dependency manager knows only that the view is dependent on a privilege\n type in that specific row but does not track exactly which privilege type the\n view is dependent on.\n\n When a REVOKE statement for a table-level privilege is issued for a grantee and\n table ID, all of the objects that are dependent on the grantee and table ID are\n dropped. For example, if user1 revokes the DELETE privilege on table t1 from\n user2, the row in SYSTABLEPERMS for GRANTEE(user2), TABLEID(user1.t1) is\n modified by the REVOKE statement. The dependency manager sends a revoke\n invalidation message to the view user2.v1, and the view is dropped, even though\n the view is not dependent on the DELETE privilege for GRANTEE(user2),\n TABLEID(user1.t1).\n\n Column-level privileges:\n\n Only one type of privilege for a specified grantee and table ID are stored in\n one row in the SYSCOLPERMS system table. For example, when user2 is granted the\n SELECT privilege on table user1.t1 for columns c12 and c13, a row is added to\n the SYSCOLPERMS. The GRANTEE field contains user2, the TABLEID contains\n user1.t1, the TYPE field contains S, and the COLUMNS field contains c12, c13.\n\n When a grantee creates an object that relies on the privilege type and the\n subset of columns in a table ID, the Derby engine tracks the dependency of the\n object on the specific row in the SYSCOLPERMS table. For example, user2 creates\n the view v1 by using the statement SELECT c11 FROM user1.t1; the dependency\n manager tracks the dependency of view v1 on the row in SYSCOLPERMS for\n GRANTEE(user2), TABLEID(user1.t1), TYPE(S). The dependency manager knows that\n the view is dependent on the SELECT privilege type but does not track exactly\n which columns the view is dependent on.\n\n When a REVOKE statement for a column-level privilege is issued for a grantee,\n table ID, and type, all of the objects that are dependent on the grantee, table\n ID, and type are dropped. For example, if user1 revokes the SELECT privilege on\n column c12 on table user1.t1 from user2, the row in SYSCOLPERMS for\n GRANTEE(user2), TABLEID(user1.t1), TYPE(S) is modified by the REVOKE statement.\n The dependency manager sends a revoke invalidation message to the view\n user2.v1, and the view is dropped, even though the view is not dependent on the\n column c12 for GRANTEE(user2), TABLEID(user1.t1), TYPE(S).\n\n If Unified Auditing is used:\n\n Apply the same process used in standard auditing to the tables with AUDSYS as\n the owner.\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n users_allowed_access_to_audit_info = sql.query(\"SELECT GRANTEE, TABLE_NAME, PRIVILEGE\n FROM DBA_TAB_PRIVS where owner='AUDSYS';\").column('grantee').uniq\n if users_allowed_access_to_audit_info.empty?\n impact 0.0\n describe 'There are no oracle users allowed access to audit information, control N/A' do\n skip 'There are no oracle users allowed access to audit information'\n end\n else\n users_allowed_access_to_audit_info.each do |user|\n describe \"oracle users: #{user} allowed access to audit information\" do\n subject { user }\n it { should be_in input('allowed_audit_users') }\n end\n end\n end\nend\n", + "code": " control 'V-61741' do\n impact 0.0\n describe 'This control is not applicable on oracle within aws rds, as aws manages the operating system in which the oracle database is running on' do\n skip 'This control is not applicable on oracle within aws rds, as aws manages the operating system in which the oracle database is running on'\n end\n end\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61655.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61741.rb", "line": 1 }, - "id": "V-61655" + "id": "V-61741" }, { - "title": "The DBMS must notify appropriate individuals when accounts are\n modified.", - "desc": "Once an attacker establishes initial access to a system, they often\n attempt to create a persistent method of re-establishing access. One way to\n accomplish this is for the attacker to modify an existing account for later use.\n\n Notification of account creation is one method and best practice for\n mitigating this risk. A comprehensive account management process will ensure an\n audit trail which documents the creation of application user accounts and\n notifies administrators and/or application owners that they exist. Such a\n process greatly reduces the risk that accounts will be surreptitiously created\n and provides logging that can be used for forensic purposes.\n\n Note that user authentication and account management must be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP. This requirement applies to cases where accounts are\n directly managed by Oracle.\n\n Notwithstanding how accounts are normally managed, the DBMS must support\n the requirement to notify appropriate individuals upon account modification\n within Oracle. Indeed, in a configuration where accounts are managed\n externally, the manipulation of an account within Oracle may indicate hostile\n activity.", + "title": "Oracle roles granted using the WITH ADMIN OPTION must not be granted\n to unauthorized accounts.", + "desc": "The WITH ADMIN OPTION allows the grantee to grant a role to another\n database account. Best security practice restricts the privilege of assigning\n privileges to authorized personnel. Authorized personnel include DBAs, object\n owners, and, where designed and included in the application's functions,\n application administrators. Restricting privilege-granting functions to\n authorized accounts can help decrease mismanagement of privileges and wrongful\n assignments to unauthorized accounts.", "descriptions": { - "default": "Once an attacker establishes initial access to a system, they often\n attempt to create a persistent method of re-establishing access. One way to\n accomplish this is for the attacker to modify an existing account for later use.\n\n Notification of account creation is one method and best practice for\n mitigating this risk. A comprehensive account management process will ensure an\n audit trail which documents the creation of application user accounts and\n notifies administrators and/or application owners that they exist. Such a\n process greatly reduces the risk that accounts will be surreptitiously created\n and provides logging that can be used for forensic purposes.\n\n Note that user authentication and account management must be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP. This requirement applies to cases where accounts are\n directly managed by Oracle.\n\n Notwithstanding how accounts are normally managed, the DBMS must support\n the requirement to notify appropriate individuals upon account modification\n within Oracle. Indeed, in a configuration where accounts are managed\n externally, the manipulation of an account within Oracle may indicate hostile\n activity." + "default": "The WITH ADMIN OPTION allows the grantee to grant a role to another\n database account. Best security practice restricts the privilege of assigning\n privileges to authorized personnel. Authorized personnel include DBAs, object\n owners, and, where designed and included in the application's functions,\n application administrators. Restricting privilege-granting functions to\n authorized accounts can help decrease mismanagement of privileges and wrongful\n assignments to unauthorized accounts." }, - "impact": 0.5, + "impact": 0, "refs": [], "tags": { - "gtitle": "SRG-APP-000292-DB-000138", - "gid": "V-61799", - "rid": "SV-76289r2_rule", - "stig_id": "O121-C2-020500", - "fix_id": "F-67715r1_fix", + "gtitle": "SRG-APP-000516-DB-999900", + "gid": "V-61437", + "rid": "SV-75927r3_rule", + "stig_id": "O121-BP-022500", + "fix_id": "F-67353r2_fix", "cci": [ - "CCI-001684" + "CCI-000366" ], "nist": [ - "AC-2 (4)", + "CM-6 b", "Rev_4" ], "false_negatives": null, @@ -5978,35 +6020,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Check DBMS settings to determine whether it will notify\n appropriate individuals when accounts are modified.\n\n If the DBMS does not notify appropriate individuals when accounts are modified,\n this is a finding.", - "fix": "Working with the DBA and site management, determine the\n appropriate individuals (by job role) to be notified.\n\n If Oracle Audit Vault is available, configure it to notify the appropriate\n individuals when accounts are modified.\n\n If Oracle Audit Vault is not available, configure the Oracle DBMS's auditing\n feature to record account-modification activity.\n\n If Standard Auditing is used:\n Create and deploy a mechanism, such as a frequently-run job, to monitor the\n SYS.AUD$ table for these records and notify the appropriate individuals.\n\n If unified Auditing is used:\n Create and deploy a mechanism, such as a frequently-run job, to monitor the\n SYS.UNIFIED_AUDIT_TRAIL view for these records and notify the appropriate\n individuals." + "check": "A default Oracle Database installation provides a set of\n predefined administrative accounts and non-administrative accounts. These are\n accounts that have special privileges required to administer areas of the\n database, such as the CREATE ANY TABLE or ALTER SESSION privilege, or EXECUTE\n privileges on packages owned by the SYS schema. The default tablespace for\n administrative accounts is either SYSTEM or SYSAUX. Non-administrative user\n accounts only have the minimum privileges needed to perform their jobs. Their\n default tablespace is USERS.\n\n To protect these accounts from unauthorized access, the installation process\n expires and locks most of these accounts, except where noted below. The\n database administrator is responsible for unlocking and resetting these\n accounts, as required.\n\n Non-Administrative Accounts - Expired and locked:\n APEX_PUBLIC_USER, DIP, FLOWS_040100*, FLOWS_FILES, MDDATA, ORACLE_OCM,\n SPATIAL_CSW_ADMIN_USR, SPATIAL_WFS_ADMIN_USR, XS$NULL\n\n Administrative Accounts - Expired and Locked:\n ANONYMOUS, CTXSTS, EXFSYS, LBACSYS, MDSYS, OLAPSYS, OEDDATA, OWBSYS,\n ORDPLUGINS, ORDSYS, OUTLN, SI_INFORMTN_SCHEMA, WK_TEST, WK_SYS, WKPROXY, WMSYS,\n XDB\n\n Administrative Accounts - Open:\n DBSNMP, MGMT_VIEW, SYS, SYSMAN, SYSTEM\n\n * Subject to change based on version installed\n\n Run the SQL statement:\n\n select grantee||': '||granted_role from dba_role_privs\n where admin_option = 'YES' and grantee not in\n (select distinct owner from dba_objects)\n and grantee not in\n (select grantee from dba_role_privs\n where granted_role = 'DBA')\n order by grantee;\n\n (With respect to the list of special accounts that are excluded from this\n requirement, it is expected that the DBA will maintain the list to suit local\n circumstances, adding special accounts as necessary and removing any that are\n not supposed to be in use in the Oracle deployment that is under review.)\n\n Review the System Security Plan to confirm any grantees listed are\n ISSO-authorized DBA accounts or application administration roles.\n\n If any grantees listed are not authorized and documented, this is a finding.", + "fix": "Revoke assignment of roles with the WITH ADMIN OPTION from\n unauthorized grantees and re-grant them without the option if required.\n\n SQL statements to remove the admin option from an unauthorized grantee:\n revoke from ;\n grant to ;\n\n Restrict use of the WITH ADMIN OPTION to authorized administrators.\n\n Document authorized role assignments with the WITH ADMIN OPTION in the System\n Security Plan." }, - "code": "control 'V-61799' do\n title \"The DBMS must notify appropriate individuals when accounts are\n modified.\"\n desc \"Once an attacker establishes initial access to a system, they often\n attempt to create a persistent method of re-establishing access. One way to\n accomplish this is for the attacker to modify an existing account for later use.\n\n Notification of account creation is one method and best practice for\n mitigating this risk. A comprehensive account management process will ensure an\n audit trail which documents the creation of application user accounts and\n notifies administrators and/or application owners that they exist. Such a\n process greatly reduces the risk that accounts will be surreptitiously created\n and provides logging that can be used for forensic purposes.\n\n Note that user authentication and account management must be done via an\n enterprise-wide mechanism whenever possible. Examples of enterprise-level\n authentication/access mechanisms include, but are not limited to, Active\n Directory and LDAP. This requirement applies to cases where accounts are\n directly managed by Oracle.\n\n Notwithstanding how accounts are normally managed, the DBMS must support\n the requirement to notify appropriate individuals upon account modification\n within Oracle. Indeed, in a configuration where accounts are managed\n externally, the manipulation of an account within Oracle may indicate hostile\n activity.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000292-DB-000138'\n tag \"gid\": 'V-61799'\n tag \"rid\": 'SV-76289r2_rule'\n tag \"stig_id\": 'O121-C2-020500'\n tag \"fix_id\": 'F-67715r1_fix'\n tag \"cci\": ['CCI-001684']\n tag \"nist\": ['AC-2 (4)', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Check DBMS settings to determine whether it will notify\n appropriate individuals when accounts are modified.\n\n If the DBMS does not notify appropriate individuals when accounts are modified,\n this is a finding.\"\n tag \"fix\": \"Working with the DBA and site management, determine the\n appropriate individuals (by job role) to be notified.\n\n If Oracle Audit Vault is available, configure it to notify the appropriate\n individuals when accounts are modified.\n\n If Oracle Audit Vault is not available, configure the Oracle DBMS's auditing\n feature to record account-modification activity.\n\n If Standard Auditing is used:\n Create and deploy a mechanism, such as a frequently-run job, to monitor the\n SYS.AUD$ table for these records and notify the appropriate individuals.\n\n If unified Auditing is used:\n Create and deploy a mechanism, such as a frequently-run job, to monitor the\n SYS.UNIFIED_AUDIT_TRAIL view for these records and notify the appropriate\n individuals.\"\n describe 'A manual review is required to ensure the DBMS notifies the appropriate individuals when accounts are\n modified' do\n skip 'A manual review is required to ensure the DBMS notifies the appropriate individuals when accounts are\n modified'\n end\nend\n", + "code": "control 'V-61437' do\n title \"Oracle roles granted using the WITH ADMIN OPTION must not be granted\n to unauthorized accounts.\"\n desc \"The WITH ADMIN OPTION allows the grantee to grant a role to another\n database account. Best security practice restricts the privilege of assigning\n privileges to authorized personnel. Authorized personnel include DBAs, object\n owners, and, where designed and included in the application's functions,\n application administrators. Restricting privilege-granting functions to\n authorized accounts can help decrease mismanagement of privileges and wrongful\n assignments to unauthorized accounts.\"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000516-DB-999900'\n tag \"gid\": 'V-61437'\n tag \"rid\": 'SV-75927r3_rule'\n tag \"stig_id\": 'O121-BP-022500'\n tag \"fix_id\": 'F-67353r2_fix'\n tag \"cci\": ['CCI-000366']\n tag \"nist\": ['CM-6 b', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"A default Oracle Database installation provides a set of\n predefined administrative accounts and non-administrative accounts. These are\n accounts that have special privileges required to administer areas of the\n database, such as the CREATE ANY TABLE or ALTER SESSION privilege, or EXECUTE\n privileges on packages owned by the SYS schema. The default tablespace for\n administrative accounts is either SYSTEM or SYSAUX. Non-administrative user\n accounts only have the minimum privileges needed to perform their jobs. Their\n default tablespace is USERS.\n\n To protect these accounts from unauthorized access, the installation process\n expires and locks most of these accounts, except where noted below. The\n database administrator is responsible for unlocking and resetting these\n accounts, as required.\n\n Non-Administrative Accounts - Expired and locked:\n APEX_PUBLIC_USER, DIP, FLOWS_040100*, FLOWS_FILES, MDDATA, ORACLE_OCM,\n SPATIAL_CSW_ADMIN_USR, SPATIAL_WFS_ADMIN_USR, XS$NULL\n\n Administrative Accounts - Expired and Locked:\n ANONYMOUS, CTXSTS, EXFSYS, LBACSYS, MDSYS, OLAPSYS, OEDDATA, OWBSYS,\n ORDPLUGINS, ORDSYS, OUTLN, SI_INFORMTN_SCHEMA, WK_TEST, WK_SYS, WKPROXY, WMSYS,\n XDB\n\n Administrative Accounts - Open:\n DBSNMP, MGMT_VIEW, SYS, SYSMAN, SYSTEM\n\n * Subject to change based on version installed\n\n Run the SQL statement:\n\n select grantee||': '||granted_role from dba_role_privs\n where admin_option = 'YES' and grantee not in\n (select distinct owner from dba_objects)\n and grantee not in\n (select grantee from dba_role_privs\n where granted_role = 'DBA')\n order by grantee;\n\n (With respect to the list of special accounts that are excluded from this\n requirement, it is expected that the DBA will maintain the list to suit local\n circumstances, adding special accounts as necessary and removing any that are\n not supposed to be in use in the Oracle deployment that is under review.)\n\n Review the System Security Plan to confirm any grantees listed are\n ISSO-authorized DBA accounts or application administration roles.\n\n If any grantees listed are not authorized and documented, this is a finding.\"\n tag \"fix\": \"Revoke assignment of roles with the WITH ADMIN OPTION from\n unauthorized grantees and re-grant them without the option if required.\n\n SQL statements to remove the admin option from an unauthorized grantee:\n revoke from ;\n grant to ;\n\n Restrict use of the WITH ADMIN OPTION to authorized administrators.\n\n Document authorized role assignments with the WITH ADMIN OPTION in the System\n Security Plan.\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n users_with_admin_option = sql.query(\"select grantee from dba_role_privs\n where admin_option = 'YES' and grantee not in\n (select distinct owner from dba_objects)\n and grantee not in\n (select grantee from dba_role_privs\n where granted_role = 'DBA')\n order by grantee;\").column('grantee').uniq\n if users_with_admin_option.empty?\n impact 0.0\n describe 'There are no oracle users with the admin option, therefore control N/A' do\n skip 'There are no oracle users with the admin option, therefore control N/A'\n end\n else\n users_with_admin_option.each do |user|\n describe \"oracle users with admin option: #{user}\" do\n subject { user }\n it { should be_in input('allowed_dbadmin_users') }\n end\n end\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61799.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61437.rb", "line": 1 }, - "id": "V-61799" + "id": "V-61437" }, { - "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": "The DBA role must not be assigned excessive or unauthorized\n privileges.", + "desc": "This requirement is intended to limit exposure due to operating from\n within a privileged account or role. The inclusion of role is intended to\n address those situations where an access control policy, such as Role Based\n Access Control (RBAC), is being implemented and where a change of role provides\n the same degree of assurance in the change of access authorizations for both\n the user and all processes acting on behalf of the user as would be provided by\n a change between a privileged and non-privileged account.\n\n Audit of privileged activity may require physical separation employing\n information systems on which the user does not have privileged access.\n\n To limit exposure and provide forensic history of activity when operating\n from within a privileged account or role, the application must support\n organizational requirements that users of information system accounts, or\n roles, with access to organization-defined lists of security functions or\n security-relevant information, use non-privileged accounts, or roles, when\n accessing other (non-security) system functions.\n\n If feasible, applications must provide access logging that ensures users\n who are granted a privileged role (or roles) have their privileged activity\n logged.\n\n DBAs, if assigned excessive privileges, could perform actions that endanger\n the information system or hide evidence of malicious activity.", "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 Audit of privileged activity may require physical separation employing\n information systems on which the user does not have privileged access.\n\n To limit exposure and provide forensic history of activity when operating\n from within a privileged account or role, the application must support\n organizational requirements that users of information system accounts, or\n roles, with access to organization-defined lists of security functions or\n security-relevant information, use non-privileged accounts, or roles, when\n accessing other (non-security) system functions.\n\n If feasible, applications must provide access logging that ensures users\n who are granted a privileged role (or roles) have their privileged activity\n logged.\n\n DBAs, if assigned excessive privileges, could perform actions that endanger\n the information system or hide evidence of malicious activity." }, - "impact": 0.3, + "impact": 0, "refs": [], "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-000019", + "gid": "V-61599", + "rid": "SV-76089r2_rule", + "stig_id": "O121-C2-004300", + "fix_id": "F-67515r1_fix", "cci": [ - "CCI-001878" + "CCI-000366" ], "nist": [ - "AU-7 a", + "CM-6 b", "Rev_4" ], "false_negatives": null, @@ -6019,30 +6061,30 @@ "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": "Review access permissions for objects owned by application\n owners or other non-administrative users.\n\n If DBA or administrative accounts have unauthorized application roles or\n permissions beyond those needed for administration, this is a finding.\n\n To obtain a list of privileges assigned to the DBMS user accounts, run the\n query:\n SELECT * from dba_sys_privs where grantee='DBA' order by privilege;\n\n To check to see what roles are assigned to a user, run the query:\n SELECT * from dba_role_privs where grantee = '';\n\n To check to see what privileges are assigned to a role, run the query:\n SELECT * from role_sys_privs;\n\n To show privileges by object, run the query:\n SELECT table_name, grantee,\n MAX(DECODE(privilege, 'SELECT', 'SELECT')) AS select_priv,\n MAX(DECODE(privilege, 'DELETE', 'DELETE')) AS delete_priv,\n MAX(DECODE(privilege, 'UPDATE', 'UPDATE')) AS update_priv,\n MAX(DECODE(privilege, 'INSERT', 'INSERT')) AS insert_priv\n FROM dba_tab_privs\n WHERE grantee IN (SELECT role FROM dba_roles)\n GROUP BY table_name, grantee\n ORDER BY table_name, grantee;\n\n This query will list the system privileges assigned to a specific user:\n SELECT LPAD(' ', 2*level) || granted_role \"USER PRIVS\"\n FROM\n (\n SELECT NULL grantee, username granted_role\n FROM dba_users\n WHERE username LIKE UPPER('%&uname%')\n UNION\n SELECT grantee, granted_role\n FROM dba_role_privs\n UNION\n SELECT grantee, privilege\n FROM dba_sys_privs\n )\n START WITH grantee IS NULL\n CONNECT BY grantee = prior granted_role;\n\n To list all administrative privileges granted to users via roles, run the query:\n SELECT\n username,\n rp.granted_role,\n privilege\n FROM\n dba_users u,\n dba_role_privs rp,\n dba_sys_privs sp\n WHERE username = rp.grantee\n AND rp.granted_role = sp.grantee\n AND privilege NOT IN\n (\n 'CREATE SEQUENCE', 'CREATE TRIGGER',\n 'SET CONTAINER', 'CREATE CLUSTER',\n 'CREATE PROCEDURE', 'CREATE TYPE',\n 'CREATE SESSION', 'CREATE OPERATOR',\n 'CREATE TABLE', 'CREATE INDEXTYPE'\n )\n AND username NOT IN\n (\n 'XDB', 'SYSTEM', 'SYS', 'LBACSYS',\n 'DVSYS', 'DVF', 'SYSMAN_RO', 'SYSMAN_BIPLATFORM',\n 'SYSMAN_MDS', 'SYSMAN_OPSS', 'SYSMAN_STB', 'DBSNMP',\n 'SYSMAN', 'APEX_040200', 'WMSYS', 'SYSDG',\n 'SYSBACKUP', 'SPATIAL_WFS_ADMIN_USR',\n 'SPATIAL_CSW_ADMIN_US','GSMCATUSER',\n 'OLAPSYS', 'SI_INFORMTN_SCHEMA', 'OUTLN', 'ORDSYS',\n 'ORDDATA', 'OJVMSYS', 'ORACLE_OCM', 'MDSYS',\n 'ORDPLUGINS', 'GSMADMIN_INTERNAL', 'MDDATA',\n 'FLOWS_FILES', 'DIP', 'CTXSYS', 'AUDSYS', 'APPQOSSYS',\n 'APEX_PUBLIC_USER', 'ANONYMOUS',\n 'SPATIAL_CSW_ADMIN_USR', 'SYSKM',\n 'SYSMAN_TYPES', 'MGMT_VIEW', 'EUS_ENGINE_USER',\n 'EXFSYS', 'SYSMAN_APM','IX','OWBSYS'\n )\n ORDER by 1, 2, 3;\n\n (The list of special accounts that are excluded from this requirement may not\n be complete. It is expected that the DBA will edit the list to suit local\n circumstances, adding other special accounts as necessary, and removing any\n that are not supposed to be in use in the Oracle deployment that is under\n review. Similarly, the list of privileges excluded from the list may be\n modified according to circumstances.)\n\n Data Dictionary Objects Related To System Privileges:\n all_sys_privs\n session_privs\n user_sys_privs\n dba_sys_privs\n system_privilege_map", + "fix": "Remove permissions from DBAs and other administrative users\n beyond those required for administrative functions." }, - "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-61599' do\n title \"The DBA role must not be assigned excessive or unauthorized\n privileges.\"\n desc \"This requirement is intended to limit exposure due to operating from\n within a privileged account or role. The inclusion of role is intended to\n address those situations where an access control policy, such as Role Based\n Access Control (RBAC), is being implemented and where a change of role provides\n the same degree of assurance in the change of access authorizations for both\n the user and all processes acting on behalf of the user as would be provided by\n a change between a privileged and non-privileged account.\n\n Audit of privileged activity may require physical separation employing\n information systems on which the user does not have privileged access.\n\n To limit exposure and provide forensic history of activity when operating\n from within a privileged account or role, the application must support\n organizational requirements that users of information system accounts, or\n roles, with access to organization-defined lists of security functions or\n security-relevant information, use non-privileged accounts, or roles, when\n accessing other (non-security) system functions.\n\n If feasible, applications must provide access logging that ensures users\n who are granted a privileged role (or roles) have their privileged activity\n logged.\n\n DBAs, if assigned excessive privileges, could perform actions that endanger\n the information system or hide evidence of malicious activity.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000063-DB-000019'\n tag \"gid\": 'V-61599'\n tag \"rid\": 'SV-76089r2_rule'\n tag \"stig_id\": 'O121-C2-004300'\n tag \"fix_id\": 'F-67515r1_fix'\n tag \"cci\": ['CCI-000366']\n tag \"nist\": ['CM-6 b', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Review access permissions for objects owned by application\n owners or other non-administrative users.\n\n If DBA or administrative accounts have unauthorized application roles or\n permissions beyond those needed for administration, this is a finding.\n\n To obtain a list of privileges assigned to the DBMS user accounts, run the\n query:\n SELECT * from dba_sys_privs where grantee='DBA' order by privilege;\n\n To check to see what roles are assigned to a user, run the query:\n SELECT * from dba_role_privs where grantee = '';\n\n To check to see what privileges are assigned to a role, run the query:\n SELECT * from role_sys_privs;\n\n To show privileges by object, run the query:\n SELECT table_name, grantee,\n MAX(DECODE(privilege, 'SELECT', 'SELECT')) AS select_priv,\n MAX(DECODE(privilege, 'DELETE', 'DELETE')) AS delete_priv,\n MAX(DECODE(privilege, 'UPDATE', 'UPDATE')) AS update_priv,\n MAX(DECODE(privilege, 'INSERT', 'INSERT')) AS insert_priv\n FROM dba_tab_privs\n WHERE grantee IN (SELECT role FROM dba_roles)\n GROUP BY table_name, grantee\n ORDER BY table_name, grantee;\n\n This query will list the system privileges assigned to a specific user:\n SELECT LPAD(' ', 2*level) || granted_role \\\"USER PRIVS\\\"\n FROM\n (\n SELECT NULL grantee, username granted_role\n FROM dba_users\n WHERE username LIKE UPPER('%&uname%')\n UNION\n SELECT grantee, granted_role\n FROM dba_role_privs\n UNION\n SELECT grantee, privilege\n FROM dba_sys_privs\n )\n START WITH grantee IS NULL\n CONNECT BY grantee = prior granted_role;\n\n To list all administrative privileges granted to users via roles, run the query:\n SELECT\n username,\n rp.granted_role,\n privilege\n FROM\n dba_users u,\n dba_role_privs rp,\n dba_sys_privs sp\n WHERE username = rp.grantee\n AND rp.granted_role = sp.grantee\n AND privilege NOT IN\n (\n 'CREATE SEQUENCE', 'CREATE TRIGGER',\n 'SET CONTAINER', 'CREATE CLUSTER',\n 'CREATE PROCEDURE', 'CREATE TYPE',\n 'CREATE SESSION', 'CREATE OPERATOR',\n 'CREATE TABLE', 'CREATE INDEXTYPE'\n )\n AND username NOT IN\n (\n 'XDB', 'SYSTEM', 'SYS', 'LBACSYS',\n 'DVSYS', 'DVF', 'SYSMAN_RO', 'SYSMAN_BIPLATFORM',\n 'SYSMAN_MDS', 'SYSMAN_OPSS', 'SYSMAN_STB', 'DBSNMP',\n 'SYSMAN', 'APEX_040200', 'WMSYS', 'SYSDG',\n 'SYSBACKUP', 'SPATIAL_WFS_ADMIN_USR',\n 'SPATIAL_CSW_ADMIN_US','GSMCATUSER',\n 'OLAPSYS', 'SI_INFORMTN_SCHEMA', 'OUTLN', 'ORDSYS',\n 'ORDDATA', 'OJVMSYS', 'ORACLE_OCM', 'MDSYS',\n 'ORDPLUGINS', 'GSMADMIN_INTERNAL', 'MDDATA',\n 'FLOWS_FILES', 'DIP', 'CTXSYS', 'AUDSYS', 'APPQOSSYS',\n 'APEX_PUBLIC_USER', 'ANONYMOUS',\n 'SPATIAL_CSW_ADMIN_USR', 'SYSKM',\n 'SYSMAN_TYPES', 'MGMT_VIEW', 'EUS_ENGINE_USER',\n 'EXFSYS', 'SYSMAN_APM','IX','OWBSYS'\n )\n ORDER by 1, 2, 3;\n\n (The list of special accounts that are excluded from this requirement may not\n be complete. It is expected that the DBA will edit the list to suit local\n circumstances, adding other special accounts as necessary, and removing any\n that are not supposed to be in use in the Oracle deployment that is under\n review. Similarly, the list of privileges excluded from the list may be\n modified according to circumstances.)\n\n Data Dictionary Objects Related To System Privileges:\n all_sys_privs\n session_privs\n user_sys_privs\n dba_sys_privs\n system_privilege_map\"\n tag \"fix\": \"Remove permissions from DBAs and other administrative users\n beyond those required for administrative functions.\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n users_with_admin_privs = sql.query(\"SELECT\n username,\n rp.granted_role,\n privilege\n FROM\n dba_users u,\n dba_role_privs rp,\n dba_sys_privs sp\n WHERE username = rp.grantee\n AND rp.granted_role = sp.grantee\n AND privilege NOT IN\n (\n 'CREATE SEQUENCE', 'CREATE TRIGGER',\n 'SET CONTAINER', 'CREATE CLUSTER',\n 'CREATE PROCEDURE', 'CREATE TYPE',\n 'CREATE SESSION', 'CREATE OPERATOR',\n 'CREATE TABLE', 'CREATE INDEXTYPE'\n )\n AND username NOT IN\n (\n 'XDB', 'SYSTEM', 'SYS', 'LBACSYS',\n 'DVSYS', 'DVF', 'SYSMAN_RO', 'SYSMAN_BIPLATFORM',\n 'SYSMAN_MDS', 'SYSMAN_OPSS', 'SYSMAN_STB', 'DBSNMP',\n 'SYSMAN', 'APEX_040200', 'WMSYS', 'SYSDG',\n 'SYSBACKUP', 'SPATIAL_WFS_ADMIN_USR',\n 'SPATIAL_CSW_ADMIN_US','GSMCATUSER',\n 'OLAPSYS', 'SI_INFORMTN_SCHEMA', 'OUTLN', 'ORDSYS',\n 'ORDDATA', 'OJVMSYS', 'ORACLE_OCM', 'MDSYS',\n 'ORDPLUGINS', 'GSMADMIN_INTERNAL', 'MDDATA',\n 'FLOWS_FILES', 'DIP', 'CTXSYS', 'AUDSYS', 'APPQOSSYS',\n 'APEX_PUBLIC_USER', 'ANONYMOUS',\n 'SPATIAL_CSW_ADMIN_USR', 'SYSKM',\n 'SYSMAN_TYPES', 'MGMT_VIEW', 'EUS_ENGINE_USER',\n 'EXFSYS', 'SYSMAN_APM','IX','OWBSYS'\n )\n ORDER by 1, 2, 3;\").column('username').uniq\n if users_with_admin_privs.empty?\n impact 0.0\n describe 'There are no oracle database users with administative privileges, control N/A' do\n skip 'There are no oracle database users with administative privileges, control N/A'\n end\n else\n users_with_admin_privs.each do |user|\n describe \"oracle database users: #{user} with administative privileges\" do\n subject { user }\n it { should be_in input('allowed_users_with_admin_privs')}\n end\n end\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61969.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61599.rb", "line": 1 }, - "id": "V-61969" + "id": "V-61599" }, { - "title": "Sensitive data stored in the database must be identified in the System\n Security Plan and AIS Functional Architecture documentation.", - "desc": "A DBMS that does not have the correct confidentiality level identified\n or any confidentiality level assigned is not being secured at a level\n appropriate to the risk it poses.", + "title": "Application owner accounts must have a dedicated application\n tablespace.", + "desc": "Separation of tablespaces by application helps to protect the\n application from resource contention and unauthorized access that could result\n from storage space reuses or host system access controls. Application data must\n be stored separately from system and custom user-defined objects to facilitate\n administration and management of its data storage. The SYSTEM tablespace must\n never be used for application data storage in order to prevent resource\n contention and performance degradation.", "descriptions": { - "default": "A DBMS that does not have the correct confidentiality level identified\n or any confidentiality level assigned is not being secured at a level\n appropriate to the risk it poses." + "default": "Separation of tablespaces by application helps to protect the\n application from resource contention and unauthorized access that could result\n from storage space reuses or host system access controls. Application data must\n be stored separately from system and custom user-defined objects to facilitate\n administration and management of its data storage. The SYSTEM tablespace must\n never be used for application data storage in order to prevent resource\n contention and performance degradation." }, - "impact": 0.5, + "impact": 0, "refs": [], "tags": { "gtitle": "SRG-APP-000516-DB-999900", - "gid": "V-61503", - "rid": "SV-75993r1_rule", - "stig_id": "O121-BP-024900", - "fix_id": "F-67419r1_fix", + "gid": "V-61461", + "rid": "SV-75951r3_rule", + "stig_id": "O121-BP-023700", + "fix_id": "F-67377r1_fix", "cci": [ "CCI-000366" ], @@ -6060,35 +6102,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "If no sensitive or classified data is stored in the database,\n listed in the System Security Plan and listed in the AIS Functional\n Architecture documentation, this check is not a finding.\n\n Review AIS Functional Architecture documentation for the DBMS and note any\n sensitive data that is identified.\n\n Review database table column data or descriptions that indicate sensitive data.\n\n For example, a data column labeled \"SSN\" could indicate social security\n numbers are stored in the column.\n\n Question the ISSO or DBA where any questions arise.\n\n General categories of sensitive data requiring identification include any\n personal data (health, financial, social security number and date of birth),\n proprietary or financially sensitive business data or data that might be\n classified.\n\n If any data is considered sensitive and is not documented in the AISFA, this is\n a finding.", - "fix": "Include identification of any sensitive data in the AIS\n Functional Architecture and the System Security Plan.\n\n Include data that appear to be sensitive with a discussion as to why it is not\n marked as such." + "check": "Run the SQL query:\n\n select distinct owner, tablespace_name\n from dba_SEGMENTS\n where owner not in\n ()\n order by tablespace_name;\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 returned table owners with the tablespace used.\n\n If any of the owners listed are not default Oracle accounts and use the SYSTEM\n or any other tablespace not dedicated for the application’s use, this is a\n finding.\n\n Look for multiple applications that may share a tablespace.\n\n If no records were returned, ask the DBA if any applications use this database.\n\n If no applications use the database, this is not a finding.\n\n If there are applications that do use the database or if the application uses\n the SYS or other default account and SYSTEM tablespace to store its objects,\n this is a finding.", + "fix": "Create and assign dedicated tablespaces for the storage of data\n by each application using the CREATE TABLESPACE command." }, - "code": "control 'V-61503' do\n title \"Sensitive data stored in the database must be identified in the System\n Security Plan and AIS Functional Architecture documentation.\"\n desc \"A DBMS that does not have the correct confidentiality level identified\n or any confidentiality level assigned is not being secured at a level\n appropriate to the risk it poses.\"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000516-DB-999900'\n tag \"gid\": 'V-61503'\n tag \"rid\": 'SV-75993r1_rule'\n tag \"stig_id\": 'O121-BP-024900'\n tag \"fix_id\": 'F-67419r1_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 sensitive or classified data is stored in the database,\n listed in the System Security Plan and listed in the AIS Functional\n Architecture documentation, this check is not a finding.\n\n Review AIS Functional Architecture documentation for the DBMS and note any\n sensitive data that is identified.\n\n Review database table column data or descriptions that indicate sensitive data.\n\n For example, a data column labeled \\\"SSN\\\" could indicate social security\n numbers are stored in the column.\n\n Question the ISSO or DBA where any questions arise.\n\n General categories of sensitive data requiring identification include any\n personal data (health, financial, social security number and date of birth),\n proprietary or financially sensitive business data or data that might be\n classified.\n\n If any data is considered sensitive and is not documented in the AISFA, this is\n a finding.\"\n tag \"fix\": \"Include identification of any sensitive data in the AIS\n Functional Architecture and the System Security Plan.\n\n Include data that appear to be sensitive with a discussion as to why it is not\n marked as such.\"\n describe 'A manual review is required to ensure sensitive data stored in the database is identified in the System\n Security Plan and AIS Functional Architecture documentation' do\n skip 'A manual review is required to ensure sensitive data stored in the database is identified in the System\n Security Plan and AIS Functional Architecture documentation'\n end\nend\n", + "code": "control 'V-61461' do\n title \"Application owner accounts must have a dedicated application\n tablespace.\"\n desc \"Separation of tablespaces by application helps to protect the\n application from resource contention and unauthorized access that could result\n from storage space reuses or host system access controls. Application data must\n be stored separately from system and custom user-defined objects to facilitate\n administration and management of its data storage. The SYSTEM tablespace must\n never be used for application data storage in order to prevent resource\n contention and performance degradation.\"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000516-DB-999900'\n tag \"gid\": 'V-61461'\n tag \"rid\": 'SV-75951r3_rule'\n tag \"stig_id\": 'O121-BP-023700'\n tag \"fix_id\": 'F-67377r1_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 distinct owner, tablespace_name\n from dba_SEGMENTS\n where owner not in\n ()\n order by tablespace_name;\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 returned table owners with the tablespace used.\n\n If any of the owners listed are not default Oracle accounts and use the SYSTEM\n or any other tablespace not dedicated for the application’s use, this is a\n finding.\n\n Look for multiple applications that may share a tablespace.\n\n If no records were returned, ask the DBA if any applications use this database.\n\n If no applications use the database, this is not a finding.\n\n If there are applications that do use the database or if the application uses\n the SYS or other default account and SYSTEM tablespace to store its objects,\n this is a finding.\"\n tag \"fix\": \"Create and assign dedicated tablespaces for the storage of data\n by each application using the CREATE TABLESPACE command.\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n application_owners = sql.query(\"select distinct owner\n from dba_SEGMENTS;\").column('owner').uniq\n if application_owners.empty?\n impact 0.0\n describe 'There are no oracle db application owners, therefore control N/A' do\n skip 'There are no oracle db application owners, therefore control N/A'\n end\n else\n application_owners.each do |user|\n describe \"oracle db application owners: #{user}\" do\n subject { user }\n it { should be_in input('allowed_application_owners') }\n end\n end\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61503.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61461.rb", "line": 1 }, - "id": "V-61503" + "id": "V-61461" }, { - "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, @@ -6101,30 +6143,30 @@ "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": "The DBMS data files, transaction logs and audit files must be stored\n in dedicated directories or disk partitions separate from software or other\n application files.", - "desc": "Protection of DBMS data, transaction and audit data files stored by\n the host operating system is dependent on OS controls. When different\n applications share the same database process, resource contention and differing\n security controls may be required to isolate and protect one application's data\n and audit logs from another. DBMS software libraries and configuration files\n also require differing access control lists.", + "title": "The Oracle _TRACE_FILES_PUBLIC parameter if present must be set to\n FALSE.", + "desc": "The _TRACE_FILES_PUBLIC parameter is used to make trace files used for\n debugging database applications and events available to all database users. Use\n of this capability precludes the discrete assignment of privileges based on job\n function. Additionally, its use may provide access to external files and data\n to unauthorized users.", "descriptions": { - "default": "Protection of DBMS data, transaction and audit data files stored by\n the host operating system is dependent on OS controls. When different\n applications share the same database process, resource contention and differing\n security controls may be required to isolate and protect one application's data\n and audit logs from another. DBMS software libraries and configuration files\n also require differing access control lists." + "default": "The _TRACE_FILES_PUBLIC parameter is used to make trace files used for\n debugging database applications and events available to all database users. Use\n of this capability precludes the discrete assignment of privileges based on job\n function. Additionally, its use may provide access to external files and data\n to unauthorized users." }, "impact": 0.5, "refs": [], "tags": { "gtitle": "SRG-APP-000516-DB-999900", - "gid": "V-61963", - "rid": "SV-76453r1_rule", - "stig_id": "O121-BP-025100", - "fix_id": "F-67883r1_fix", + "gid": "V-61465", + "rid": "SV-75955r1_rule", + "stig_id": "O121-BP-023900", + "fix_id": "F-67381r1_fix", "cci": [ "CCI-000366" ], @@ -6142,30 +6184,30 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Review the disk/directory specification where database data,\n transaction log and audit files are stored.\n\n If DBMS data, transaction or audit data files are stored in the same directory,\n this is a finding.\n\n If separation of data, transaction and audit data is not supported by the DBMS,\n this check is not a finding.\n\n If stored separately and access permissions for each directory is the same,\n this is a finding.", - "fix": "Product-specific fix pending development. Use Generic Fix listed\n below:\n\n Specify dedicated host system disk directories to store database data,\n transaction and audit files.\n\n Configure DBMS default file storage locations to use dedicated disk directories\n where supported by the DBMS." + "check": "From SQL*Plus:\n\n select value from v$parameter where name = '_trace_files_public';\n\n If the value returned is TRUE, this is a finding.\n\n If the parameter does not exist or is set to FALSE, this is not a finding.", + "fix": "From SQL*Plus (shutdown database instance):\n\n shutdown immediate\n\n From SQL*Plus (create a pfile from spfile):\n\n create pfile='[PATH]init[SID].ora' from spfile;\n\n Edit the init[SID].ora file and remove the following line:\n\n *._trace_files_public=TRUE\n\n From SQL*Plus (update the spfile using the pfile):\n\n create spfile from pfile='[PATH]init[SID].ora';\n\n From SQL*Plus (start the database instance):\n\n startup\n\n Note: [PATH] depends on the platform (Windows or UNIX).\n\n Ensure the file is directed to a writable location.\n\n [SID] is equal to the oracle SID or database instance ID." }, - "code": "control 'V-61963' do\n title \"The DBMS data files, transaction logs and audit files must be stored\n in dedicated directories or disk partitions separate from software or other\n application files.\"\n desc \"Protection of DBMS data, transaction and audit data files stored by\n the host operating system is dependent on OS controls. When different\n applications share the same database process, resource contention and differing\n security controls may be required to isolate and protect one application's data\n and audit logs from another. DBMS software libraries and configuration files\n also require differing access control lists.\"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000516-DB-999900'\n tag \"gid\": 'V-61963'\n tag \"rid\": 'SV-76453r1_rule'\n tag \"stig_id\": 'O121-BP-025100'\n tag \"fix_id\": 'F-67883r1_fix'\n tag \"cci\": ['CCI-000366']\n tag \"nist\": ['CM-6 b', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Review the disk/directory specification where database data,\n transaction log and audit files are stored.\n\n If DBMS data, transaction or audit data files are stored in the same directory,\n this is a finding.\n\n If separation of data, transaction and audit data is not supported by the DBMS,\n this check is not a finding.\n\n If stored separately and access permissions for each directory is the same,\n this is a finding.\"\n tag \"fix\": \"Product-specific fix pending development. Use Generic Fix listed\n below:\n\n Specify dedicated host system disk directories to store database data,\n transaction and audit files.\n\n Configure DBMS default file storage locations to use dedicated disk directories\n where supported by the DBMS.\"\n describe 'A manual review is required to ensure the DBMS data files, transaction logs and audit files are stored\n in dedicated directories or disk partitions separate from software or other\n application files' do\n skip 'A manual review is required to ensure the DBMS data files, transaction logs and audit files are stored\n in dedicated directories or disk partitions separate from software or other\n application files'\n end\nend\n", + "code": "control 'V-61465' do\n title \"The Oracle _TRACE_FILES_PUBLIC parameter if present must be set to\n FALSE.\"\n desc \"The _TRACE_FILES_PUBLIC parameter is used to make trace files used for\n debugging database applications and events available to all database users. Use\n of this capability precludes the discrete assignment of privileges based on job\n function. Additionally, its use may provide access to external files and data\n to unauthorized users.\"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000516-DB-999900'\n tag \"gid\": 'V-61465'\n tag \"rid\": 'SV-75955r1_rule'\n tag \"stig_id\": 'O121-BP-023900'\n tag \"fix_id\": 'F-67381r1_fix'\n tag \"cci\": ['CCI-000366']\n tag \"nist\": ['CM-6 b', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"From SQL*Plus:\n\n select value from v$parameter where name = '_trace_files_public';\n\n If the value returned is TRUE, this is a finding.\n\n If the parameter does not exist or is set to FALSE, this is not a finding.\"\n tag \"fix\": \"From SQL*Plus (shutdown database instance):\n\n shutdown immediate\n\n From SQL*Plus (create a pfile from spfile):\n\n create pfile='[PATH]init[SID].ora' from spfile;\n\n Edit the init[SID].ora file and remove the following line:\n\n *._trace_files_public=TRUE\n\n From SQL*Plus (update the spfile using the pfile):\n\n create spfile from pfile='[PATH]init[SID].ora';\n\n From SQL*Plus (start the database instance):\n\n startup\n\n Note: [PATH] depends on the platform (Windows or UNIX).\n\n Ensure the file is directed to a writable location.\n\n [SID] is equal to the oracle SID or database instance ID.\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n parameter = sql.query(\"select value from v$parameter where name = '_trace_files_public';\").column('value')\n\n describe 'The oracle database _TRACE_FILES_PUBLIC parameter' do\n subject { parameter }\n it { should_not cmp 'TRUE' }\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61963.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61465.rb", "line": 1 }, - "id": "V-61963" + "id": "V-61465" }, { - "title": "Credentials stored and used by the DBMS to access remote databases or\n applications must be authorized and restricted to authorized users.", - "desc": "Credentials defined for access to remote databases or applications may\n provide unauthorized access to additional databases and applications to\n unauthorized or malicious users.", + "title": "Audit trail data must be reviewed daily or more frequently.", + "desc": "Review of audit trail data provides a means for detection of\n unauthorized access or attempted access. Frequent and regularly scheduled\n reviews ensure that such access is discovered in a timely manner.", "descriptions": { - "default": "Credentials defined for access to remote databases or applications may\n provide unauthorized access to additional databases and applications to\n unauthorized or malicious users." + "default": "Review of audit trail data provides a means for detection of\n unauthorized access or attempted access. Frequent and regularly scheduled\n reviews ensure that such access is discovered in a timely manner." }, - "impact": 0, + "impact": 0.5, "refs": [], "tags": { "gtitle": "SRG-APP-000516-DB-999900", - "gid": "V-61507", - "rid": "SV-75997r1_rule", - "stig_id": "O121-BP-025200", - "fix_id": "F-67423r1_fix", + "gid": "V-61457", + "rid": "SV-75947r1_rule", + "stig_id": "O121-BP-023500", + "fix_id": "F-67373r2_fix", "cci": [ "CCI-000366" ], @@ -6183,39 +6225,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Review the list of defined database links generated from the\n DBMS.\n\n Compare to the list in the System Security Plan with the DBA.\n\n If no database links are listed in the database and in the System Security\n Plan, this check is not a finding.\n\n If any database links are defined in the DBMS, verify the authorization for the\n definition in the System Security Plan.\n\n If any database links exist that are not authorized or not listed in the System\n Security Plan, this is a finding.", - "fix": "Grant access to database links to authorized users or\n applications only.\n\n Document all database links access authorizations in the System Security Plan." + "check": "If the database being reviewed is not a production database,\n this check is not a finding.\n\n Review policy and procedures documented or noted in the System Security plan as\n well as evidence of implementation for daily audit trail monitoring.\n\n If policy and procedures are not documented or evidence of implementation is\n not available, this is a finding.", + "fix": "Develop, document and implement policy and procedures to monitor\n audit trail data daily." }, - "code": "control 'V-61507' do\n title \"Credentials stored and used by the DBMS to access remote databases or\n applications must be authorized and restricted to authorized users.\"\n desc \"Credentials defined for access to remote databases or applications may\n provide unauthorized access to additional databases and applications to\n unauthorized or malicious users.\"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000516-DB-999900'\n tag \"gid\": 'V-61507'\n tag \"rid\": 'SV-75997r1_rule'\n tag \"stig_id\": 'O121-BP-025200'\n tag \"fix_id\": 'F-67423r1_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 list of defined database links generated from the\n DBMS.\n\n Compare to the list in the System Security Plan with the DBA.\n\n If no database links are listed in the database and in the System Security\n Plan, this check is not a finding.\n\n If any database links are defined in the DBMS, verify the authorization for the\n definition in the System Security Plan.\n\n If any database links exist that are not authorized or not listed in the System\n Security Plan, this is a finding.\"\n tag \"fix\": \"Grant access to database links to authorized users or\n applications only.\n\n Document all database links access authorizations in the System Security Plan.\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n db_links = sql.query('SELECT DB_LINK FROM DBA_DB_LINKS;').column('db_link').uniq\n if db_links.empty?\n impact 0.0\n describe 'There are no oracle database links defined, control N/A' do\n skip 'There are no oracle database links defined, control N/A'\n end\n else\n db_links.each do |link|\n describe \"The defined oracle database link: #{link}\" do\n subject { link }\n it { should be_in input('allowed_db_links') }\n end\n end\n end\nend\n", + "code": "control 'V-61457' do\n title 'Audit trail data must be reviewed daily or more frequently.'\n desc \"Review of audit trail data provides a means for detection of\n unauthorized access or attempted access. Frequent and regularly scheduled\n reviews ensure that such access is discovered in a timely manner.\"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000516-DB-999900'\n tag \"gid\": 'V-61457'\n tag \"rid\": 'SV-75947r1_rule'\n tag \"stig_id\": 'O121-BP-023500'\n tag \"fix_id\": 'F-67373r2_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 database being reviewed is not a production database,\n this check is not a finding.\n\n Review policy and procedures documented or noted in the System Security plan as\n well as evidence of implementation for daily audit trail monitoring.\n\n If policy and procedures are not documented or evidence of implementation is\n not available, this is a finding.\"\n tag \"fix\": \"Develop, document and implement policy and procedures to monitor\n audit trail data daily.\"\n describe 'A manual review is required to ensure audit trail data is reviewed daily or more frequently' do\n skip 'A manual review is required to ensure audit trail data is reviewed daily or more frequently'\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61507.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61457.rb", "line": 1 }, - "id": "V-61507" + "id": "V-61457" }, { - "title": "The DBMS must support organizational requirements to enforce password\n complexity by the number of lower-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": "The DBMS must identify potentially security-relevant error conditions.", + "desc": "The structure and content of error messages need to be carefully\n considered by the organization and development team. The extent to which the\n application is able to identify and handle error conditions is guided by\n organizational policy and operational requirements.\n\n Database logs can be monitored for specific security-related errors. Any\n error that can have a negative effect on database security should be quickly\n identified and forwarded to the appropriate personnel. If security-relevant\n error conditions are not identified by the DBMS, they may be overlooked by the\n personnel responsible for addressing them.", "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 structure and content of error messages need to be carefully\n considered by the organization and development team. The extent to which the\n application is able to identify and handle error conditions is guided by\n organizational policy and operational requirements.\n\n Database logs can be monitored for specific security-related errors. Any\n error that can have a negative effect on database security should be quickly\n identified and forwarded to the appropriate personnel. If security-relevant\n error conditions are not identified by the DBMS, they may be overlooked by the\n personnel responsible for addressing them." }, "impact": 0.5, - "refs": [ - { - "ref": [] - } - ], + "refs": [], "tags": { - "gtitle": "SRG-APP-000167-DB-000071", - "gid": "V-61725", - "rid": "SV-76215r1_rule", - "stig_id": "O121-C2-014200", - "fix_id": "F-67641r1_fix", + "gtitle": "SRG-APP-000265-DB-000161", + "gid": "V-61789", + "rid": "SV-76279r1_rule", + "stig_id": "O121-C2-019800", + "fix_id": "F-67705r1_fix", "cci": [ - "CCI-000193" + "CCI-000366" ], "nist": [ - "IA-5 (1) (a)", + "CM-6 b", "Rev_4" ], "false_negatives": null, @@ -6228,35 +6266,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\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 lower-case\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": "Check DBMS settings to determine whether security-related error\n conditions are monitored for, and whether appropriate personnel are notified.\n\n If security-related error conditions are not being monitored for, this is a\n finding.\n\n If appropriate personnel are not alerted when a security-related error\n condition is found, this is a finding.", + "fix": "Configure DBMS to monitor for security-related error conditions.\n\n Configure DBMS to alert appropriate personnel when security-related error\n conditions are found.\n\n This can be accomplished by using Oracle Audit Vault and/or Oracle Enterprise\n Manager. If neither of these products is deployed, then develop a site-specific\n solution.\n\n - - - - -\n Notes to assist in developing a site-specific solution:\n\n The AUD$ table has a column called RETURNCODE. That column provides the return\n code; so, for example, if the security-related condition is someone trying to\n select data from a table that is not there, it would show up in the AUD$ table\n as an ORA-00942 - table or view does not exist. Since the RETURNCODE column is\n only numeric, only the 00942 would be stored. If the query for the information\n returned a row, the process would then need to form and send an email message.\n\n Oracle recommends the use of Oracle Audit Vault to fill this requirement\n without creating a custom solution. It is possible to set up notifications\n and alerts in Enterprise Manager as well, and if either of these alternatives\n is not available, a custom solution will be necessary." }, - "code": "control 'V-61725' do\n title \"The DBMS must support organizational requirements to enforce password\n complexity by the number of lower-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-000167-DB-000071'\n tag \"gid\": 'V-61725'\n tag \"rid\": 'SV-76215r1_rule'\n tag \"stig_id\": 'O121-C2-014200'\n tag \"fix_id\": 'F-67641r1_fix'\n tag \"cci\": ['CCI-000193']\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\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 lower-case\n characters (1 unless otherwise specified), this is a finding.\"\n tag \"fix\": \"If all user accounts are authenticated by the OS or an\n enterprise-level authentication/access mechanism, and not by Oracle, no fix to\n the DBMS is required.\n\n If any user accounts are managed by Oracle: Develop, test and implement a\n password verification function that enforces DoD requirements.\n\n (Oracle supplies a sample function called ORA12C_STRONG_VERIFY_FUNCTION, in the\n script file\n /RDBMS/ADMIN/utlpwdmg.sql. This can be used as the starting point\n for a customized function.)\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n query = %{\n SELECT PROFILE, RESOURCE_NAME, LIMIT FROM DBA_PROFILES WHERE PROFILE =\n '%s' AND RESOURCE_NAME = 'PASSWORD_VERIFY_FUNCTION'\n }\n\n user_profiles = sql.query('SELECT profile FROM dba_users;').column('profile').uniq\n\n user_profiles.each do |profile|\n next if profile == \"RDSADMIN\"\n password_verify_function = sql.query(format(query, profile: profile)).column('limit')\n\n describe \"The oracle database account password verify function for profile: #{profile}\" do\n subject { password_verify_function }\n it { should_not eq ['NULL'] }\n end\n end\n if user_profiles.empty?\n describe 'There are no user profiles, therefore this control is NA' do\n skip 'There are no user profiles, therefore this control is NA'\n end\n end\nend\n", + "code": "control 'V-61789' do\n title 'The DBMS must identify potentially security-relevant error conditions.'\n desc \"The structure and content of error messages need to be carefully\n considered by the organization and development team. The extent to which the\n application is able to identify and handle error conditions is guided by\n organizational policy and operational requirements.\n\n Database logs can be monitored for specific security-related errors. Any\n error that can have a negative effect on database security should be quickly\n identified and forwarded to the appropriate personnel. If security-relevant\n error conditions are not identified by the DBMS, they may be overlooked by the\n personnel responsible for addressing them.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000265-DB-000161'\n tag \"gid\": 'V-61789'\n tag \"rid\": 'SV-76279r1_rule'\n tag \"stig_id\": 'O121-C2-019800'\n tag \"fix_id\": 'F-67705r1_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\": \"Check DBMS settings to determine whether security-related error\n conditions are monitored for, and whether appropriate personnel are notified.\n\n If security-related error conditions are not being monitored for, this is a\n finding.\n\n If appropriate personnel are not alerted when a security-related error\n condition is found, this is a finding.\"\n tag \"fix\": \"Configure DBMS to monitor for security-related error conditions.\n\n Configure DBMS to alert appropriate personnel when security-related error\n conditions are found.\n\n This can be accomplished by using Oracle Audit Vault and/or Oracle Enterprise\n Manager. If neither of these products is deployed, then develop a site-specific\n solution.\n\n - - - - -\n Notes to assist in developing a site-specific solution:\n\n The AUD$ table has a column called RETURNCODE. That column provides the return\n code; so, for example, if the security-related condition is someone trying to\n select data from a table that is not there, it would show up in the AUD$ table\n as an ORA-00942 - table or view does not exist. Since the RETURNCODE column is\n only numeric, only the 00942 would be stored. If the query for the information\n returned a row, the process would then need to form and send an email message.\n\n Oracle recommends the use of Oracle Audit Vault to fill this requirement\n without creating a custom solution. It is possible to set up notifications\n and alerts in Enterprise Manager as well, and if either of these alternatives\n is not available, a custom solution will be necessary.\"\n describe 'A manual review is required to ensure the DBMS must identifies potentially security-relevant error conditions' do\n skip 'A manual review is required to ensure the DBMS must identifies potentially security-relevant error conditions'\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61725.rb", + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61789.rb", "line": 1 }, - "id": "V-61725" + "id": "V-61789" }, { - "title": "The DBMS must enforce approved authorizations for logical access to\n the system in accordance with applicable policy.", - "desc": "Strong access controls are critical to securing application data.\n Access control policies (e.g., identity-based policies, role-based policies,\n attribute-based policies) and access enforcement mechanisms (e.g., access\n control lists, access control matrices, cryptography) must be employed by\n applications, when applicable, to control access between users (or processes\n acting on behalf of users) and objects (e.g., devices, files, records,\n processes, programs, domains) in the information system.\n\n Consideration should be given to the implementation of an audited, explicit\n override of automated mechanisms in the event of emergencies or other serious\n events.\n\n If the DBMS does not follow applicable policy when approving access it may\n be in conflict with networks or other applications in the information system.\n This may result in users either gaining or being denied access inappropriately\n and may be in conflict with applicable policy.", + "title": "Database objects must be owned by accounts authorized for ownership.", + "desc": "Within the database, object ownership implies full privileges to the\n owned object including the privilege to assign access to the owned objects to\n other subjects. Unmanaged or uncontrolled ownership of objects can lead to\n unauthorized object grants and alterations, and unauthorized modifications to\n data.\n\n If critical tables or other objects rely on unauthorized owner accounts,\n these objects can be lost when an account is removed.\n\n It may be the case that there are accounts that are authorized to own\n synonyms, but no other objects. If this is so, it should be documented.", "descriptions": { - "default": "Strong access controls are critical to securing application data.\n Access control policies (e.g., identity-based policies, role-based policies,\n attribute-based policies) and access enforcement mechanisms (e.g., access\n control lists, access control matrices, cryptography) must be employed by\n applications, when applicable, to control access between users (or processes\n acting on behalf of users) and objects (e.g., devices, files, records,\n processes, programs, domains) in the information system.\n\n Consideration should be given to the implementation of an audited, explicit\n override of automated mechanisms in the event of emergencies or other serious\n events.\n\n If the DBMS does not follow applicable policy when approving access it may\n be in conflict with networks or other applications in the information system.\n This may result in users either gaining or being denied access inappropriately\n and may be in conflict with applicable policy." + "default": "Within the database, object ownership implies full privileges to the\n owned object including the privilege to assign access to the owned objects to\n other subjects. Unmanaged or uncontrolled ownership of objects can lead to\n unauthorized object grants and alterations, and unauthorized modifications to\n data.\n\n If critical tables or other objects rely on unauthorized owner accounts,\n these objects can be lost when an account is removed.\n\n It may be the case that there are accounts that are authorized to own\n synonyms, but no other objects. If this is so, it should be documented." }, - "impact": 0.5, + "impact": 0, "refs": [], "tags": { - "gtitle": "SRG-APP-000033-DB-000084", - "gid": "V-61575", - "rid": "SV-76065r1_rule", - "stig_id": "O121-C2-002700", - "fix_id": "F-67491r1_fix", + "gtitle": "SRG-APP-000133-DB-000200", + "gid": "V-61673", + "rid": "SV-76163r2_rule", + "stig_id": "O121-C2-011000", + "fix_id": "F-67587r1_fix", "cci": [ - "CCI-000213" + "CCI-001499" ], "nist": [ - "AC-3", + "CM-5 (6)", "Rev_4" ], "false_negatives": null, @@ -6269,35 +6307,39 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "check": "Check DBMS settings to determine whether users are restricted\n from accessing objects and data they are not authorized to access. If\n appropriate access controls are not implemented to restrict access to\n authorized users and to restrict the access of those users to objects and data\n they are authorized to see, this is a finding.\n\n The easiest way to isolate access is by using the Oracle Database Vault. To\n check to see if the Oracle Database Vault is installed, issue the following\n query:\n\n SQL> SELECT * FROM V$OPTION WHERE PARAMETER = 'Oracle Database Vault';\n\n If Oracle Database Vault is installed, review its settings for appropriateness\n and completeness of the access it permits and denies to each type of user. If\n appropriate and complete, this is not a finding.\n\n If Oracle Database Vault is not installed, review the roles and profiles in the\n database and the assignment of users to these for appropriateness and\n completeness of the access permitted and denied each type of user. If\n appropriate and complete, this is not a finding.\n\n If the access permitted and denied each type of user is inappropriate or\n incomplete, this is a finding.\n\n Following are code examples for reviewing roles, profiles, etc.\n\n Find out what role the users have:\n select * from dba_role_privs where granted_role = ''\n\n List all roles given to a user:\n select * from dba_role_privs where grantee = '';\n\n List all roles for all users:\n column grantee format a32\n column granted_role format a32\n break on grantee\n select grantee, granted_role from dba_role_privs;\n\n Use the following query to list all privileges given to a user:\n select\n lpad(' ', 2*level) || granted_role \"User roles and privileges\"\n from\n (\n /* THE USERS */\n select\n null grantee,\n username granted_role\n from\n dba_users\n where\n username like upper('')\n /* THE ROLES TO ROLES RELATIONS */\n union\n select\n grantee,\n granted_role\n from\n dba_role_privs\n /* THE ROLES TO PRIVILEGE RELATIONS */\n union\n select\n grantee,\n privilege\n from\n dba_sys_privs\n )\n start with grantee is null\n connect by grantee = prior granted_role;\n\n List which tables a certain role gives SELECT access to using the query:\n select * from role_tab_privs where role='' and privilege = 'SELECT';\n\n List all tables a user can SELECT from using the query:\n select * from dba_tab_privs where GRANTEE ='' and privilege =\n 'SELECT';\n\n List all users who can SELECT on a particular table (either through being given\n a relevant role or through a direct grant - e.g., grant select on a table to\n Joe). The result of this query should also show through which role the user has\n this access or whether it was a direct grant.\n\n select\n Grantee,'Granted Through Role' as Grant_Type,\n role,\n table_name\n from role_tab_privs rtp, dba_role_privs drp\n where rtp.role = drp.granted_role\n and table_name = ''\n union\n select\n Grantee,\n 'Direct Grant' as Grant_type,\n null as role,\n table_name\n from dba_tab_privs\n where table_name = '';", - "fix": "If Oracle Database Vault is in use, use it to configure the\n correct access privileges for each type of user.\n\n If Oracle Database Vault is not in use, configure the correct access privileges\n for each type of user using Roles and Profiles.\n\n For more information on the configuration of Database Vault, refer to the\n following documents:\n Database Vault Administrator's Guide:\n https://docs.oracle.com/database/121/DVADM/toc.htm" + "check": "Review system documentation to identify accounts authorized to\n own database objects. Review accounts in DBMS that own objects.\n\n If any database objects are found to be owned by users not authorized to own\n database objects, this is a finding.\n\n - - - - -\n Query the object DBA_OBJECTS to show the users who own objects in the database.\n The query below will return all of the users who own objects.\n\n sqlplus connect as sysdba\n\n SQL>select owner, object_type, count(*) from dba_objects\n group by owner, object_type\n order by owner, object_type;\n\n If these owners are not authorized owners, select all of the objects these\n owners have generated and decide who they should belong to. To make a list of\n all of the objects, the unauthorized owner has to perform the following query.\n\n SQL>select * from dba_objects where owner =&unauthorized_owner;", + "fix": "Update system documentation to include list of accounts\n authorized for object ownership.\n\n Re-assign ownership of authorized objects to authorized object owner accounts." }, - "code": "control 'V-61575' do\n title \"The DBMS must enforce approved authorizations for logical access to\n the system in accordance with applicable policy.\"\n desc \"Strong access controls are critical to securing application data.\n Access control policies (e.g., identity-based policies, role-based policies,\n attribute-based policies) and access enforcement mechanisms (e.g., access\n control lists, access control matrices, cryptography) must be employed by\n applications, when applicable, to control access between users (or processes\n acting on behalf of users) and objects (e.g., devices, files, records,\n processes, programs, domains) in the information system.\n\n Consideration should be given to the implementation of an audited, explicit\n override of automated mechanisms in the event of emergencies or other serious\n events.\n\n If the DBMS does not follow applicable policy when approving access it may\n be in conflict with networks or other applications in the information system.\n This may result in users either gaining or being denied access inappropriately\n and may be in conflict with applicable policy.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000033-DB-000084'\n tag \"gid\": 'V-61575'\n tag \"rid\": 'SV-76065r1_rule'\n tag \"stig_id\": 'O121-C2-002700'\n tag \"fix_id\": 'F-67491r1_fix'\n tag \"cci\": ['CCI-000213']\n tag \"nist\": ['AC-3', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Check DBMS settings to determine whether users are restricted\n from accessing objects and data they are not authorized to access. If\n appropriate access controls are not implemented to restrict access to\n authorized users and to restrict the access of those users to objects and data\n they are authorized to see, this is a finding.\n\n The easiest way to isolate access is by using the Oracle Database Vault. To\n check to see if the Oracle Database Vault is installed, issue the following\n query:\n\n SQL> SELECT * FROM V$OPTION WHERE PARAMETER = 'Oracle Database Vault';\n\n If Oracle Database Vault is installed, review its settings for appropriateness\n and completeness of the access it permits and denies to each type of user. If\n appropriate and complete, this is not a finding.\n\n If Oracle Database Vault is not installed, review the roles and profiles in the\n database and the assignment of users to these for appropriateness and\n completeness of the access permitted and denied each type of user. If\n appropriate and complete, this is not a finding.\n\n If the access permitted and denied each type of user is inappropriate or\n incomplete, this is a finding.\n\n Following are code examples for reviewing roles, profiles, etc.\n\n Find out what role the users have:\n select * from dba_role_privs where granted_role = ''\n\n List all roles given to a user:\n select * from dba_role_privs where grantee = '';\n\n List all roles for all users:\n column grantee format a32\n column granted_role format a32\n break on grantee\n select grantee, granted_role from dba_role_privs;\n\n Use the following query to list all privileges given to a user:\n select\n lpad(' ', 2*level) || granted_role \\\"User roles and privileges\\\"\n from\n (\n /* THE USERS */\n select\n null grantee,\n username granted_role\n from\n dba_users\n where\n username like upper('')\n /* THE ROLES TO ROLES RELATIONS */\n union\n select\n grantee,\n granted_role\n from\n dba_role_privs\n /* THE ROLES TO PRIVILEGE RELATIONS */\n union\n select\n grantee,\n privilege\n from\n dba_sys_privs\n )\n start with grantee is null\n connect by grantee = prior granted_role;\n\n List which tables a certain role gives SELECT access to using the query:\n select * from role_tab_privs where role='' and privilege = 'SELECT';\n\n List all tables a user can SELECT from using the query:\n select * from dba_tab_privs where GRANTEE ='' and privilege =\n 'SELECT';\n\n List all users who can SELECT on a particular table (either through being given\n a relevant role or through a direct grant - e.g., grant select on a table to\n Joe). The result of this query should also show through which role the user has\n this access or whether it was a direct grant.\n\n select\n Grantee,'Granted Through Role' as Grant_Type,\n role,\n table_name\n from role_tab_privs rtp, dba_role_privs drp\n where rtp.role = drp.granted_role\n and table_name = ''\n union\n select\n Grantee,\n 'Direct Grant' as Grant_type,\n null as role,\n table_name\n from dba_tab_privs\n where table_name = '';\"\n tag \"fix\": \"If Oracle Database Vault is in use, use it to configure the\n correct access privileges for each type of user.\n\n If Oracle Database Vault is not in use, configure the correct access privileges\n for each type of user using Roles and Profiles.\n\n For more information on the configuration of Database Vault, refer to the\n following documents:\n Database Vault Administrator's Guide:\n https://docs.oracle.com/database/121/DVADM/toc.htm\"\n describe 'A manual review is required to ensure the DBMS enforces approved authorizations for logical access to\n the system in accordance with applicable policy' do\n skip 'A manual review is required to ensure the DBMS enforces approved authorizations for logical access to\n the system in accordance with applicable policy'\n end\nend\n", + "code": "control 'V-61673' do\n title 'Database objects must be owned by accounts authorized for ownership.'\n desc \"Within the database, object ownership implies full privileges to the\n owned object including the privilege to assign access to the owned objects to\n other subjects. Unmanaged or uncontrolled ownership of objects can lead to\n unauthorized object grants and alterations, and unauthorized modifications to\n data.\n\n If critical tables or other objects rely on unauthorized owner accounts,\n these objects can be lost when an account is removed.\n\n It may be the case that there are accounts that are authorized to own\n synonyms, but no other objects. If this is so, it should be documented.\n \"\n impact 0.5\n tag \"gtitle\": 'SRG-APP-000133-DB-000200'\n tag \"gid\": 'V-61673'\n tag \"rid\": 'SV-76163r2_rule'\n tag \"stig_id\": 'O121-C2-011000'\n tag \"fix_id\": 'F-67587r1_fix'\n tag \"cci\": ['CCI-001499']\n tag \"nist\": ['CM-5 (6)', 'Rev_4']\n tag \"false_negatives\": nil\n tag \"false_positives\": nil\n tag \"documentable\": false\n tag \"mitigations\": nil\n tag \"severity_override_guidance\": false\n tag \"potential_impacts\": nil\n tag \"third_party_tools\": nil\n tag \"mitigation_controls\": nil\n tag \"responsibility\": nil\n tag \"ia_controls\": nil\n tag \"check\": \"Review system documentation to identify accounts authorized to\n own database objects. Review accounts in DBMS that own objects.\n\n If any database objects are found to be owned by users not authorized to own\n database objects, this is a finding.\n\n - - - - -\n Query the object DBA_OBJECTS to show the users who own objects in the database.\n The query below will return all of the users who own objects.\n\n sqlplus connect as sysdba\n\n SQL>select owner, object_type, count(*) from dba_objects\n group by owner, object_type\n order by owner, object_type;\n\n If these owners are not authorized owners, select all of the objects these\n owners have generated and decide who they should belong to. To make a list of\n all of the objects, the unauthorized owner has to perform the following query.\n\n SQL>select * from dba_objects where owner =&unauthorized_owner;\"\n tag \"fix\": \"Update system documentation to include list of accounts\n authorized for object ownership.\n\n Re-assign ownership of authorized objects to authorized object owner accounts.\"\n\n sql = oracledb_session(user: input('user'), password: input('password'), host: input('host'), service: input('service'), sqlplus_bin: input('sqlplus_bin'))\n\n dba_object_owners = sql.query('select DISTINCT owner from dba_objects;').column('owner').uniq\n if dba_object_owners .empty?\n impact 0.0\n describe 'There are no oracle dba object owners, control N/A' do\n skip 'There are no oracle dba object owners, control N/A'\n end\n else\n dba_object_owners .each do |owner|\n describe \"oracle datbase object owner: #{owner}\" do\n subject { owner }\n it { should be_in input('allowed_dbaobject_owners') }\n end\n end\n end\nend\n", "source_location": { - "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61575.rb", - "line": 1 + "ref": "/github/home/.inspec/cache/36f5c955872642c88d8c0b6017a096a137ceb67a/controls/V-61673.rb", + "line": 2 }, - "id": "V-61575" + "id": "V-61673" }, { - "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.", + "title": "The DBMS must enforce requirements for remote connections to the\n information system.", + "desc": "Applications that provide remote access to information systems must be\n able to enforce remote access policy requirements or work in conjunction with\n enterprise tools designed to enforce policy requirements. Examples of policy\n requirements include, but are not limited to, authorizing remote access to the\n information system, limiting access based on authentication credentials, and\n monitoring for unauthorized access.\n\n If databases allowing remote connections do not enforce requirements for\n remote access, an attacker may gain access to the database and may, through the\n database, gain access to other components of the information system.", "descriptions": { - "default": "Information systems are capable of providing a wide variety of\n functions and services. Some of the functions and services, provided by\n default, may not be necessary to support essential organizational operations\n (e.g., key missions, functions).\n\n It is detrimental for applications to provide, or install by default,\n functionality exceeding requirements or mission objectives. Examples include,\n but are not limited to, installing advertising software, demonstrations, or\n browser 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." + "default": "Applications that provide remote access to information systems must be\n able to enforce remote access policy requirements or work in conjunction with\n enterprise tools designed to enforce policy requirements. Examples of policy\n requirements include, but are not limited to, authorizing remote access to the\n information system, limiting access based on authentication credentials, and\n monitoring for unauthorized access.\n\n If databases allowing remote connections do not enforce requirements for\n remote access, an attacker may gain access to the database and may, through the\n database, gain access to other components of the information system." }, "impact": 0, - "refs": [], + "refs": [ + { + "ref": [] + } + ], "tags": { - "gtitle": "SRG-APP-000141-DB-000092", - "gid": "V-61681", - "rid": "SV-76171r2_rule", - "stig_id": "O121-C2-011700", - "fix_id": "F-67595r3_fix", + "gtitle": "SRG-APP-000140-DB-000033", + "gid": "V-61675", + "rid": "SV-76165r1_rule", + "stig_id": "O121-C2-011400", + "fix_id": "F-67589r1_fix", "cci": [ - "CCI-000381" + "CCI-000366" ], "nist": [ - "CM-7 a", + "CM-6 b", "Rev_4" ], "false_negatives": null, @@ -6310,35 +6352,35 @@ "mitigation_controls": null, "responsibility": null, "ia_controls": null, - "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