1. Using Advanced Controls
  2. Eliminate False Positives

Eliminate False Positives

As you review access model results, you may determine that some records are false positives: although they meet the model's risk definition, they don't pose actual separation-of-duties risk. This may be true, for example, in either of these cases:

  • A model defines a conflict between two access points, but a user's access to one of them is read-only. In particular, the conflict may involve a privilege whose path includes an aggregate privilege that grants read-only access.

    An aggregate privilege is a predefined role that combines one function security privilege with related data security policies. In some cases, the policies stipulate read-only access to data. For example, users may have access to a Manage Work Terms and Assignment privilege. That access would be read-only if granted through an aggregate privilege called View Work Terms and Assignment, but write-enabled if granted through a duty role called Manage Work Terms and Assignment.

  • A model defines a conflict between two access points, and one of them exists in the hierarchy of a role with "stripes." Modifications to striped roles may cause an access point to exist within a hierarchy but not actually grant access.

    Role stripes are versions of a role that apply to specific modules of Oracle Fusion Cloud. For example, there's a predefined Payables Invoice Creation duty role: ORA_AP_PAYABLES_INVOICE_CREATION_DUTY. There are also stripes of this role: ORA_AP_PAYABLES_INVOICE_CREATION_DUTY_OBI and ORA_AP_PAYABLES_INVOICE_CREATION_DUTY_CRM. They're used with Oracle Business Intelligence and Customer Resource Management, respectively.

    Note that you can no longer modify role stripes, so these false positives would be of concern only for modified stripes inherited from R12 or earlier.

To eliminate false positive results, create conditions to exclude them. Path conditions, for example, work well with false positives generated when users gain access to privileges through read-only aggregate privileges. The process involves these steps:

  1. Having run an access model, review its results to identify false-positive records. For example, look for paths that include aggregate privileges you know to be read-only. Or, look for paths including roles with stripes.

  2. Confirm that a given record is a false positive. Then create a condition to exclude it. For example, you might:

    • Create a user-defined access point that specifies the exact path of a false positive involving a read-only aggregate privilege. Then create a path condition to exclude that user-defined access point.

    • Create a conventional condition that uses the Access Point attribute, the Does not equal condition, and the name of a role that you know grants read-only access. For example, that role might be the View Work Terms and Assignment aggregate privilege. This would exclude records in which the role occurs anywhere in a path.

  3. Consider including related condition filters as elements of a global condition. For example, a global condition might contain all the path-condition filters that identify false positives involving read-only aggregate privileges. That way, each condition filter applies whenever any model would return the false positive it excludes.

  4. Rerun the model. You should find that it returns fewer records, and all of them pertain to genuine conflicts.

Read-only aggregate privileges and role stripes are only two examples of what may cause false-positive results. Ask questions about your setup whose answers suggest condition filters that can eliminate other false-positive results. Here are some samples.

If you answer yes to either of the following, you may want to add a Within Same equals Yes condition:

  • Do you consider it a risk if someone can both create and pay an AP invoice, but only in the same business unit?

  • Do you consider it a risk if someone can create and post to a journal, but only in one data access set?

If you answer yes to any of the following, you may want to create a user-defined access point, and then create a path condition to exclude it:

  • Have you disabled the ability to quick pay for a particular role?

  • Have you hidden the bank accounts tab on the supplier site?

  • Have you modified data security policies associated to a role, so that the role doesn't have certain access? Possibly even through use of custom SQL?

If you answer yes to either of the following, you may want to create a condition that excludes a role:

  • Are you in a development instance, and want to exclude users with super-user roles?

  • Do you want to exclude the supplier portal role because it returns only external users who are expected to create their own suppliers and invoices?

Related Topics