30 oracle e-business suite (ebs) security tips and tricks

30 Oracle E-Business Suite (EBS) Security Tips and Tricks

© 2020 Fastpath Solutions, LLC. | 4093 NW Urbandale Drive | Des Moines, IA 50322 | 515-276-1779 gofastpath.com

30 Oracle E-Business Suite (EBS) Security Tips and Tricks

Securing your Oracle E-Business Suite (EBS) application is an ongoing and evolving task. Once implemented, like a new car, Oracle EBS security must be maintained and checked periodically. Users and responsibilities come and go, new company workflows are introduced via mergers and acquisitions, and governments adopt new data protection and privacy regulations.

As the application gains more ‘wear and tear’ via these events, it can be a daunting challenge to properly secure and maintain it, especially when the maintenance includes removing excessive user access as well as properly designing responsibilities, menus and concurrent programs among other items.

However, while it is a difficult and often thankless task, it is important to remain vigilant over your Oracle EBS application security and achieve sound governance as well as continuously address key business and IT risks for your organization.

Fortunately, the excellent news is that there are a multitude of tips and tricks that, if performed correctly, will help you to not only maintain, but also optimize Oracle EBS application security leading to this task’s achievement!

http://www.gofastpath.com


This eBook takes you through 30 of these tips and tricks for securing Oracle EBS across three areas: System Administration, Automated Application Controls, and IT General Controls (ITGC).

Implementing these 30 tips and tricks will help control user access to critical areas of the application and prevent key segregation of duties (SoD) conflicts among other items. They won’t address all of your security issues, but they will go a long way toward addressing many of them.

The primary goal of this eBook is to equip you with deep Oracle EBS Security ‘Power User’ knowledge to do the following:

1. Quickly detect and prevent high-risk, anomalous security issues

2. Achieve optimal and robust Oracle EBS application security3. Invest your time in more value-added business activities after

addressing your organization’s major Oracle EBS application security issues

We hope you find this eBook valuable, practical, and detailed enough for you to understand what took us years working with numerous Oracle EBS organizations to discover.

Ok, let’s get to work!



System Administration

TIP #1: Disable Access to the Diagnostics Menu for All UsersAvailable from the Help screen, the Diagnostics menu lets users directly edit data and configurations not visible or updatable in the typical forms, potentially bypassing controls (see Figure 1). Two profile options control whether users can access the Diagnostics menu: Hide Diagnostics menu entry and Utilities: Diagnostics:

Profile options in Oracle EBS can be set at multiple levels: Site, Application, Responsibility, or User. Therefore, you must look at all levels to verify access is properly restricted. It is best practice to hide the Diagnostics menu for all users of the EBS environment. To accomplish this, set Hide Diagnostics menu entry to Yes and Utilities: Diagnostics to No at the Site level.

Once disabled for all users, the Diagnostics menu can then be enabled for specific users, as needed. For more information on the Diagnostics menu, refer to the Oracle EBS System Administrator’s Guide.

Figure 1 – Examine field values using the Diagnostics menu

User Profile Option Name Value Meaning

Hide Diagnostics Menu Entry Yes* Diagnostics menu (Help > Diagnostics) is hidden

Hide Diagnostics Menu Entry No

Diagnostics menu (Help > Diagnostics) is accessible.Users can directly edit data not visible or updatable in the typical forms

Utilities: Diagnostics Yes

If the Diagnostics menu is accessible, users can access the Diagnostics submenu items: Examine, Trace, Debug, Properties, and Custom Code

Utilities: Diagnostics No*

If the Diagnostics menu is accessible, users must enter the password for the APPS schema to use these Diagnostics features. Not applicable if the Diagnostics menu is hidden

*Recommended Setting




TIP #2: No Prompt does not mean No Access!Many responsibilities provide prompts in the Navigator (specifically, the ‘Functions’ tab) that users can click to access submenus or functions, which allow them to process transactions and adjust configuration settings or master data. These prompts are configured and maintained via the ‘Prompt’ column in the Menus form. Many people have the mistaken impression that if the prompt values are blank (i.e. null), it means that users cannot access the respective submenus or functions for which there are null prompt values.

However, users can still access some submenus or functions even without a value populated in the Prompt column. Figure 2 on the next page provides an example of this.

Therefore, configuring a No Prompt (a submenu or function without a value defined in the Prompt column of the Menus form) does not necessarily prevent users from accessing the submenu or function associated with that No Prompt.

Before navigating to Figure 2, here is a quick overview of the major fields in the Menus form, which allows users to define new menus or modify existing menus:

MenuA name that is intended by Oracle to “describe the purpose of the menu”; however many times this is not the case. This is what we would call the “Technical Menu Name” since it is not what the user sees but more what Oracle sees after being configured. When designing custom security, most Oracle EBS implementers or organizations will start this field with “XX” to declare it is a custom vs. seeded menu.

User Menu NameThis is what we would call the “Functional Menu Name” because it is what the user sees in the UI. In Oracle’s words, “Used when a responsibility calls a menu or when one menu calls another.”

SequenceSequence number that specifies where a submenu entry appears relative to other submenu entries in a menu. Translation = A submenu or function with a lower sequence number will appear before submenus or functions with a higher sequence number in the Navigator window. • Ex: In Figure 2, this means that the Journals prompt to access the GL_SU_JOURNAL

submenu (Seq 1) will simply appear first followed by the Budget prompt to access the GL_SU_BUDGET (Seq 2) submenu and so on until the last Sequence Number is reached.

PromptAs explained above, this represents what the user will see in the hierarchy list of the Navigator window in order to click and access the related submenu or function.




Figure 2 shows the seeded top-level menu (GL_SUPERUSER) which is assigned to the General Ledger Super User responsibility. Note the “Prompt” column.

While all the submenus in Seq #1-8 have values populated in the Prompt column, there is no value for Seq #9, AZN_PR_GL (the GL Process Navigator menu). Therefore, in theory, there should not be a Prompt for a user to click in order to access the GL Process Navigator menu from this top-level menu (GL_SUPERUSER).

However, when assigned the General Ledger Super User responsibility, we find out that this is not the case. This user just needs to click on the ‘Processes’ tab to open the GL Process Navigator menu. From there, the user can click on any of the graphical icons to perform many sensitive record to report activities including entering, posting and importing journals.

More on this and AZN Menus in Tip #9.

Additionally, configuring and applying a ‘No Prompt’ automatic mitigation, a condition that excludes all SoD results where there is not a prompt to the conflicting function or submenu, in your GRC tool will exclude this legitimate access from reporting. Further, this will lead to:• False negative sensitive access/segregation of duties (SoD) results• Increased risk of occupational fraud caused by not detecting and remediating unauthorized

Oracle EBS access

TIP #3: Periodically test No PromptsBecause of this potential for unauthorized or ‘hidden’ access to submenus or functions, it is a good practice to establish a process for identifying and, periodically, evaluating your EBS security for these No Prompts, testing them for access and remediating them in the Menus form as necessary. Ideally, you want to use a non-production environment that has been recently refreshed from production to perform this process.

Pay special attention to Responsibility, Menu, and other security settings, such as Form Personalizations, as they will impact if a No Prompt leads to true or false positive access.

Figure 2 – Example showing the GL_SUPERUSER Menu with No Prompt to the AZN GL Process Navigator submenu; users can still access this submenu and its resulting functions




TIP #4: Maintain and Remediate No Prompt Testing ResultsIn terms of a manageable step-by-step process to periodically evaluate and test No Prompts for access once you have identified and evaluated them in Tips #2 and #3 above, here is just one possible step-by-step approach that you can use: 1. Build and run a SQL query to identify which responsibilities, menus, and functions have

changed in a given timeframe (e.g., month, quarter, year) using the Last Update Date field.2. Create a test username and assign to it a sample of responsibilities which represent all the

security changes noted above. 3. Validate if you can access the submenu or function by any means necessary only from the

front-end (i.e., no database access. This process applies only to the application layer.). 4. For each responsibility tested, track your results and perform the following actions as needed:

• Yes = True Access – Perform one of the following actions:a. Keep the submenu or function in the menu if needed for valid business purposes.b. Remove the submenu or function from the menu if not needed for valid business

purposes via the Menus form• No = False Positive Access – Perform one of the following actions:

a. Remove the No Prompt submenu or function from the menu in the Menus formb. Exclude the No Prompt submenu or function from the menu via a Function/Menu

exclusion in the Responsibilities formc. ONLY if needed for valid business purposes: Keep the No Prompt submenu or function

and add a mitigating control, rule, or condition in your GRC tool to exclude this No Prompt from future sensitive access and SoD conflict reporting

TIP #5: Minimize System Administrator and Application Developer AccessThe System Administrator and Application Developer responsibilities (see Figure 3) provide full access to key administrative functionality in Oracle EBS. Make sure you are only assigning these responsibilities to the users who genuinely need them and that you are periodically reviewing which users have this type of access.

Figure 3 – System Administrator and Application Developer responsibilities provide full access to key administrative functionality in Oracle EBS




TIP #6: Design and Use Custom Responsibilities for User Access (Seeded Responsibilities NOT Recommended)Oracle EBS comes with pre-defined (or “seeded”) responsibilities upon installation. Most of these seeded responsibilities provide “keys to the kingdom” access to many parts of the system and create inherent SoD conflicts across all major business processes.

As such, it is best practice to use seeded responsibilities only as a starting point for designing and building custom responsibilities. If you must use the seeded responsibilities, it is recommended they are only for the following reasons:• Emergency account access• Service accounts that need to process jobs in the background• Other truly valid business purposesBe sure to end-date all seeded responsibilities not required for valid business purposes after designing, implementing and assigning custom responsibilities!

TIP #7: Beware of Cross-Module Access!Some seeded responsibilities in Oracle EBS have interdependent access across multiple applications.

For example, the Order Management Super User responsibility can access Customer Master Data via the Actions button (Add Customer option) in the standard Sales Orders form. Additionally, several responsibilities allow the creation of manual journal entries via the subledger modules (i.e. Receivables, Payables, etc.). Among them are: Cash Management, Payables Manager, Receivables Inquiry. More on subledger manual journals in Tip #20.

Figure 4 shows that users assigned the Receivables Inquiry responsibility can create manual journal entries within one of the subledger modules.

The risk here is that users you thought had none or limited access to functions within certain business processes can make changes to other parts of the system, potentially circumventing internal controls.

Figure 4 – Users with Receivables Inquiry responsibility can create manual journal entries within one of the Subledger modules.




TIP #8: Just Because it Says Inquiry Does Not Mean it is ONLY Inquiry!Some seeded responsibilities and menus with “Inquiry” in the name have full access to critical functionality. For example, the Payables Inquiry responsibility allows users to create or edit Supplier Master Data.

In addition, as illustrated in the prior Tip, the Receivables Inquiry responsibility allows users to create manual journal entries via the Subledger module.

Recommendation for ALL ERP systems (not just Oracle EBS): NEVER assume that seeded roles or responsibilities with Inquiry (or View Only, etc.) in the name do not have access to process transactional data or create/modify master data within the application.

TIP #9: Remove AZN Menus from All ResponsibilitiesAZN menus were introduced by Oracle to help provide for more rapid implementations. These menus offer users a graphical depiction of a process flow in the Processes tab, and the users can access functions directly from the graphical navigation rather than using the standard Functions tab.

As shown in Figure 5, if a user clicks on one of the icons from the graphical navigation, EBS will launch the form associated with that icon as if the user clicked on the prompt for that menu or function in the Functions tab. For example, clicking on the “Enter Journals” icon will launch the Enter Journals form and allow users to create journal entries.

Since this can create severe security risks, it is best practice to remove all AZN menus from all responsibilities utilizing menu exclusions and other means to eliminate this backdoor access.

Figure 5 – Example of a user accessing journal entry using AZN menus




TIP #10: Continuously Monitor Users and Responsibilities for AZN Menu AccessSince access to AZN Menus (Figure 6) can be re-introduced via upgrades, it is a good practice to continuously monitor active users and responsibilities for unintended AZN Menu access.

Oracle’s Preventive Controls Governor (PCG) product, part of the Oracle Advanced Controls Suite, can be leveraged to build Form and Flow rules which, when configured appropriately, can quickly detect and exclude all AZN menus from all responsibilities on an ad-hoc or periodic basis.

Figure 6 – User access to AZN menus can lead to unintended consequences

Automated Application Controls

TIP #11: Check Your Credit Before You Wreck Your Credit!To enforce credit checking in Oracle EBS, multiple configurations, at different levels, must be set appropriately to:

9 Perform a credit check on sales orders at the time the orders are booked

9 Place orders by customers with insufficient credit on hold

9 Prevent the release of orders on hold until the hold(s) is removed




While there may be others specific to your organization, correctly setting the following configurations at these 4 levels will greatly help your organization properly enforce credit checking:

1. System

• AR Payment Terms

• Customer Profile Classes

• Holds

2. Operating Unit

• Credit Check Rules

• Credit Profiles

• ONT Transaction Types

3. Customer

• Credit Limit

• Order Amount Limit

4. Customer Site

• Credit and Collection

• Profile Amounts

NOTE: Don’t try to set everything right all at once! Instead, take a structured, practical approach to address/test/validate one configuration setting at a time before moving on to the next one.

We recommend this for any application control that requires setting and synchronizing multiple configurations in order for the control to address the applicable risks.




TIP #12: Age Those BucketsIf your organization uses and relies on AR Aging Reports, make sure your Aging Buckets (Figure 7) are configured appropriately for overdue invoices to appear in the correct AR Aging Reports used by the business.

For example, in the Collections aging bucket below, someone could delete Sequence Number 3, then change the Days To setting from “60” to “90” but leave the Column Heading as “31-60 Days” in Sequence Number 2. This would provide someone like an AR Manager reading the report a false impression that some overdue AR invoices are not delinquent debt when in fact they are. Under this scenario, an AR invoice overdue by 70 days would appear to the AR Manager end user as being only 31-60 days overdue. This can lead to problems with collections and cash flow.

TIP #13: Don’t Delegate Your Delegation of Authority!Having an appropriate delegation of authority to approve purchase requisitions and purchase orders is of paramount importance for many organizations.

Multiple configurations at the Operating Unit level must be set appropriately in order for Oracle EBS to enforce this approval hierarchy for purchase requisitions & purchase orders based on the total requisition & PO value, respectively, as well as disallow them to be approved by the same user who entered them.

Three of these configurations that will help you enforce this approval hierarchy are: • Approval Groups• Approval Assignments• Document Types

Figure 7 – Example of setting Collections Aging Bucket tiers




TIP #14: Match, match, match!3-Way Matching helps ensure that purchase orders, invoices, and receipts are validated from both a pricing and quantity perspective as you go through the procurement process. Like Credit Checking (See Tip #11), multiple configurations at different levels must be set appropriately in order for Oracle EBS to:

9 Require matching on all AP invoices 9 Place any AP Invoices that don’t comply with these configurations on hold

Appropriately setting these configurations will help to achieve these and other purchasing and payables control objectives:• Tolerances• Payables Options• Invoice Release Holds

TIP #15: Carefully Review and Lockdown Supplier AccessSince Supplier and Customer Master Data is, primarily, maintained through the web-based HTML vs. Java forms in Oracle EBS, configuring and locking down which responsibilities have full vs. inquiry supplier master data access has, traditionally, been a challenge for most organizations. While organizations think their responsibilities have inquiry supplier access, many end up actually having full supplier access.

Oracle has published many MoS (My Oracle Support) Documents on how to detect and secure this supplier access, however, actually securing it can still be a challenge.

Review MoS Documents, build Forms Personalizations, or talk to consultants with Oracle EBS technical expertise to help you design, build and validate custom supplier inquiry responsibilities.




TIP #16: Identify Supplier Creation/Inquiry AccessOracle provides a diagnostic script to help detect supplier creation and inquiry access in your EBS environment (see Figure 8).

You can download this diagnostic script here:

TIP #17: Oracle EBS Does NOT Prevent All Duplicate Invoice PaymentsWhile Oracle EBS will prevent certain duplicate invoice payments, it will not stop all of them. For example, the payments of two invoices with the same invoice number & amount within two different operating units would be allowed to process without an error or warning message. Oracle EBS does not look across operating units and as such, will not flag these as duplicate invoices.The solution is to design and deploy technology that seamlessly interrogates invoices across operating units for duplicate invoice numbers as well as other variables that can lead to erroneous or fraudulent duplicate invoice payments.

TIP #18: Depreciate Those AssetsMultiple configurations at different levels must be set appropriately for Oracle EBS to calculate and record depreciation for fixed assets in accordance with corporate policy. Configurations that, when properly set, will help achieve these and other fixed asset control objectives are Asset Books, Asset Categories, and Depreciation Methods.

TIP #19: Freeze Journals!Journal Sources identify the origin of a journal entry. For each source, the Freeze Journals setting (Figure 9) in the Journal Sources form controls whether journals can be modified or not prior to posting.When the Freeze Journals setting of the Journal Sources form is set to Yes (Enabled), journals created with this source cannot be modified in the correction or standard Enter Journals form.When Freeze Journals is set to No (Disabled), users with access to create journals can open unfrozen journals before posting and perform any of the following actions:• Modify the GL accounts• Modify debit/credit amounts• Add manual journal lines to system journal entries

Figure 8 – Diagnostic script to detect supplier access in your EBS environment



https://support.oracle.com/epmos/faces/DocumentDisplay?_afrLoop=301621976072216&id=1385028.1&_adf.ctrl-state=makq0c62l_52


Disabling Freeze Journals on journal sources will allow users to change GL accounts or debit/credit amounts on journals created from these sources. This could lead to financial statement fraud such as net income overstatements or understatements. Best practice is to freeze all systematic journal sources (Receivables, Assets, etc.) and unfreeze all manual journal sources.

Figure 9 – Using Journal Sources to Freeze Journals

Figure 10 – Users with access to the Subledger Journal Entries screen can create manual journal entries and make them look like system-generated journals

TIP #20: Don’t Sublet Subledger Manual JournalsOracle EBS Release 12 (R12) introduced a new capability that allows users to create manual journal entries within the subledger modules (see Figure 10). However, a high-risk result of this was that users also gained the ability make these manual journals look like system journals via equating the Journal Source to “Payables”, “Receivables” or others, depending on subledger used to get to the screen, instead of the usual “Manual” source for manual journal entries.

Therefore, no user should be able to create manual journal entries within the subledgers unless management has designed controls to detect and identify these manual subledger journals. Enabling journal approval will also help mitigate this risk.




IT General Controls (ITGC)

TIP #21: Establish a Formal User Provisioning ProcessPerforming informal user provisioning practices, such as copying existing responsibilities from one user to another or not specifying the specific responsibilities to be assigned in access requests (e.g. “Give Jack the same access as Diane”), typically leads to over-provisioning security and SOX ITGC exceptions.

Instead, you should establish and implement a formal user provisioning process which contains the following high-level steps for your organization:

1. Document the user access request: • Have a process to add and modify user access to all key/in-scope applications• Document all user access requests via a ticketing system and state precisely which

responsibilities (or roles, if using RBAC) are being requested for each user.2. Approve the user access request

• Verify that all access requests are approved by the appropriate IT or Business Owners prior to assignment and that evidence of this approval exists in the user access request.

3. Validate the provisioned access• Verify that the access requested matches the access granted• Verify that the responsibilities or roles requested for each user match the responsibilities

or roles assigned to each user




TIP #22: Establish a Formal User Termination ProcessLikewise, there should be a formal process for terminating users:

1. Document the user termination• Have a process to end-date user access• Document all user termination requests via a ticketing system and set up integrations

with Active Directory and other systems so that IT is promptly notified when users leave the company

2. Terminate ALL user access• Terminate network access immediately• End-date the Oracle EBS username record NO LATER than two weeks of the user’s last

day of employment (Depending on your external auditor, this threshold may be less than two weeks. Please consult with your external or internal auditors for specific guidance to your organization and implement as appropriate.)

• Terminate the user’s access to all other applications as soon as possible3. Validate the user’s terminated access

• Verify that terminated users no longer appear on user access reports

NOTE: Make sure Oracle EBS and all key/in-scope systems are integrated appropriately with Active Directory (network access). Integration with Active Directory ensures IT will know when an employee has been terminated and not have to wait for HR to inform them.

There may be a legitimate reason why IT was not told about an employee’s termination, but SOX auditors are generally not interested in the explanation.




TIP #23: Plan For And Remove Emergency AccessThere are times when access privileges must be temporarily granted to some individuals in emergency or temporary situations (vacation, sick, troubleshooting, etc.). Make sure you have a plan in place for approving, assigning, and removing emergency access privileges when the need arises.

TIP #24: Automate Your User Access ReviewMany user access reviews are still performed manually, which is adequate for small companies but can lead to problems and SoD conflicts in larger organizations. Automating user access reviews provides greater auditability, consistency, and efficiency via reducing the time it takes to generate, review, and organize the reports to be reviewed. GRC tools will help you automate the user access review process.

The following illustrates Fastpath’s Access Certification automated user access review process:1. Fastpath generates a report of users and their access privileges based on the configured Review

Type. In the case of Oracle EBS, the most commonly used report type is user-responsibility assignments.

2. Managers review these reports and accept or reject each item (e.g. user-responsibility assignment) as follows:• If accepted, the user access is authorized, and no further action is required.• If rejected, the user access is unauthorized and remediation or corrective action must

be taken to remove the user’s access. Fastpath has a workflow option available where reviewers can send the results of their reviews to their organization’s IT Security Team responsible for adding or removing user access in Oracle EBS. From there, the IT Security Team can use the results to perform the remedial or corrective actions.

TIP #25: Take a Risk-Based Approach to SecurityIdentify your organization’s highest risks and address these first. Use a Top Down approach to address security via assessing your responsibilities and user-responsibility assignments first, then look at the specific menus, functions and other elements contained within the responsibilities. When reviewing users and responsibilities, look at individuals who have the most critical access, System Administrator and Application Developer responsibilities (see Tip #5), first.

TIP #26: More Responsibility = Less AccessManagement jobs are not transactional jobs and, thus, should not have transactional access. Therefore, even though some managers may be involved in transactions, they should not be performing them. As a rule of thumb, transactional access should decrease with responsibility.




TIP #27: Redesign Business Processes for SoDUsers should not have access to multiple parts of a process. Whenever you are performing a business process walkthrough, make sure you identify vulnerabilities in your business processes, an essential requirement for SOX compliance. This can be hard to do without a GRC tool.

TIP #28: Establish a Process to Track All Configuration Changes You Make to the SystemAuditors might ask you for a list of all configuration changes over the past year, and Oracle EBS does not provide this for you. One common misperception about ITGC-Change Management testing is that viewing the last update will show all previous updates.

Unfortunately, this is not correct and there is no easy or reliable way to obtain a report of all Oracle EBS application configuration changes out of the box. The Last Update Date (see Figure 11) will not tell you how many times a field has been updated, simply when it was last updated.

Custom reports from GRC tools such as Fastpath’s Audit Trail solution are much better alternatives that can help provide this information and allow you to maintain reporting to ensure you track all key configuration changes to the system.

TIP #29: Perform Security Changes in PhasesSecurity changes don’t and shouldn’t be all done at once. Performing your security changes, such as responsibility or menu changes, in phases will let you isolate issues and give you a much more reliable approach to security. Remember, completing each phase will still help improve the overall system security.

TIP #30: Security is More Than Just Oracle EBS – Look Beyond the Application ItselfThere are multiple layers to the Oracle EBS architecture other than the application layer, and each layer has unique security issues and mitigating actions. These layers, or Rings of Security, are the:• Database• Application• Network / Infrastructure• Users

Figure 11 – The Last Update Date will not tell you how many times a field has been updated, simply when it was last updated




As an administrator, you are responsible for asking the difficult questions – and continuing to ask them – to make sure that your organization’s overall security is maintained, such as:• Why does the controller need to process AP?• Why did the accountant make changes to our suppliers?• What system does the functionality for this high-risk business process activity come from?

Also, look for any other systems that integrate with Oracle EBS, such as Salesforce and Workday for CRM and HR activities. Transactional and master data flow between all of these systems can create SoD issues across applications that may be hard to find without a dedicated search or tool that can provide robust SoD insights and reporting across multiple applications.

ConclusionAs mentioned in the Introduction, securing your Oracle E-Business Suite (EBS) application is an ongoing and evolving task. It is not something you perform once on installation and never need to worry about again. Maintaining a secure environment requires consistent, diligent monitoring.Accomplishing the tips and tricks outlined in this eBook will significantly help you achieve optimal and robust Oracle EBS application security. Additionally, it will achieve more sound governance and remediation of key business and IT risks for your organization.

To watch an on-demand session on this topic presented by Fastpath, please visit this link, “30

Security Tips n’ Tricks for Oracle EBS in 30 Minutes”.

About FastpathFounded in 2004, Fastpath has deep expertise in audit, security, and compliance, with multiple Certified Internal Auditors, CISAs, and CPAs on the team. Fastpath has global partnerships with several audit firms and a client base which spans across multiple industries within both publicly traded and privately held companies. Fastpath Assure® is a cloud-based audit platform that can track, review, approve, and mitigate access risks across multiple systems from a single dashboard.

Visit our website for additional resources like this eBook, on-demand webinars, and more.

For a live demonstration which targets your specific requirements, please contact us.



https://www.gofastpath.com/od_30_tips_oracle-ebs

https://www.gofastpath.com/od_30_tips_oracle-ebs

https://www.gofastpath.com/resources

https://www.gofastpath.com/demo