Fastpath 30 Oracle EBS Tips and Tricks

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

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!
© 2020 Fastpath Solutions, LLC. | 4093 NW Urbandale Drive | Des Moines, IA 50322 | 515-276-1779 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 security
3. 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 Users
Available 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:
User Profile Option Name Value Meaning

Diagnostics menu (Help > Diagnostics)
Hide Diagnostics Menu Entry Yes*
is hidden
Diagnostics menu (Help > Diagnostics)
is accessible.
Hide Diagnostics Menu Entry No
Users can directly edit data not visible or
updatable in the typical forms
If the Diagnostics menu is accessible,
users can access the Diagnostics
Utilities: Diagnostics Yes
submenu items: Examine, Trace, Debug,
Properties, and Custom Code
If the Diagnostics menu is accessible,
users must enter the password for the
Utilities: Diagnostics No* APPS schema to use these Diagnostics
features. Not applicable if the
Diagnostics menu is hidden
*Recommended Setting
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

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:
Menu
A 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 Name

This 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.”
Sequence
Sequence 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.
Prompt
As 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.
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
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 Prompts

Because 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.
TIP #4: Maintain and Remediate No Prompt Testing Results
In 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 form
b. Exclude the No Prompt submenu or function from the menu via a Function/Menu
exclusion in the Responsibilities form
c. 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 Access

The 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 purposes
Be 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 Responsibilities

AZN 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 Access
Since 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 Buckets
If 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.
Figure 7 – Example of setting Collections Aging Bucket tiers
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
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 Access

Since 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 Access
Oracle 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:
Figure 8 – Diagnostic script to detect supplier access in your EBS environment
TIP #17: Oracle EBS Does NOT Prevent All Duplicate Invoice Payments
While 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 Assets

Multiple 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
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
TIP #20: Don’t Sublet Subledger Manual Journals

Oracle 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.
Figure 10 – Users with access to the Subledger Journal Entries screen can create manual journal entries
and make them look like system-generated journals
IT General Controls (ITGC)
TIP #21: Establish a Formal User Provisioning Process

Performing 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 Process
Likewise, 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 possible
3. 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 Access
There 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 Review

Many 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 Security

Identify 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 Access

Management 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 SoD
Users 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 System
Auditors 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.
Figure 11 – The Last Update Date will not tell you how many times a field has been updated,
simply when it was last updated
TIP #29: Perform Security Changes in Phases

Security 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 Itself
There 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
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.
Conclusion
As 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 Fastpath
Founded 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.

Fastpath 30 Oracle EBS Tips and Tricks

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Fastpath 30 Oracle EBS Tips and Tricks

Uploaded by

Copyright:

Available Formats

30 Oracle E-Business Suite (EBS)

Security Tips and Tricks

As the application gains more

However, while it is a difficult and often thankless task, it is

Fortunately, the excellent news is that there are a multitude of

Implementing these 30 tips and tricks will help control user

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

We hope you find this eBook valuable, practical, and detailed

Ok, let’s get to work!

User Profile Option Name Value Meaning

Figure 1 – Examine field values using the Diagnostics menu

User Menu Name

More on this and AZN Menus in Tip #9.

TIP #3: Periodically test No Prompts

TIP #5: Minimize System Administrator and Application Developer Access

TIP #7: Beware of Cross-Module Access!

TIP #9: Remove AZN Menus from All Responsibilities

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

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

Automated Application Controls

9 Place orders by customers with insufficient credit on hold

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

Figure 7 – Example of setting Collections Aging Bucket tiers

TIP #13: Don’t Delegate Your Delegation of Authority!

TIP #15: Carefully Review and Lockdown Supplier Access

You can download this diagnostic script here:

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

TIP #18: Depreciate Those Assets

TIP #19: Freeze Journals!

Figure 9 – Using Journal Sources to Freeze Journals

TIP #20: Don’t Sublet Subledger Manual Journals

TIP #21: Establish a Formal User Provisioning Process

1. Document the user access request:

1. Document the user termination

TIP #24: Automate Your User Access Review

TIP #25: Take a Risk-Based Approach to Security

TIP #26: More Responsibility = Less Access

TIP #29: Perform Security Changes in Phases

You might also like