ERP Risk Advisors blog

Monday, January 30, 2017

Security standards for Oracle E-Business Suite; the good, the bad, the ugly...

Security Standards for Oracle E-Business Suite; the good, the bad the ugly

Organizations that use Oracle E-Business Suite rely on the quality and completeness of the guidance provided to them by Oracle through My Oracle Support (MOS). There are several documents that organizations should know like the back of their hand and should have documented their compliance with the recommendations in detail. One such document is MOS Note 403537.1 – Secure Configuration Guide for Oracle E-Business Suite. Compliance with this document prior to going live is a necessity. Because of changes being introduced by users, DBAs, security administrators, developers, and via patches provided by Oracle, compliance needs to be reviewed and re-tested on a regular basis.

Over the last 10 years we have uncovered several issues with this document. We have published our findings from time to time and Oracle has acknowledged use of our feedback in their documentation. Recently we have identified four other issues that we’d like to address that frankly has us questioning the quality and completeness of the document as well as questioning the quality and completeness of the internal processes that should be influencing this document.

I wrote an article documenting the pros and cons of this document that I’d encourage you to download and read. The MOS Note presents various risks that organizations need to be aware of and Oracle provides some recommendations related to these risks. You can access this article here.

Conclusion

I have identified several major issues with this MOS note. Why isn’t Oracle updating their documentation when they release new forms that allow SQL injection? Could it be the problem is with their development standards and peer review process? Are they not identifying these risks as part of their development process? If so, isn’t that a bigger concern. Perhaps this is why they have backed off making ‘best practice’ recommendations.

Why doesn’t Oracle see the ability to decrypt credit card and bank account data as a security risk?

How is it these deficiencies exist in their documentation (failure to identify that JTF_FM_QUERY is a view and that they aren’t monitoring the ALR_ACTIONS table) and have gone unnoticed for over three years from the release of this guidance in September 2011? The only logical conclusion is they are not implementing and testing their own guidance.

Over the past few years, we have noted deficiencies in the easiest of these recommendations – seeded application users and seeded database users. We have also identified four new functions which allow SQL injection that have not been updated in their documentation. At one point, there were five, but two of them have been since added to their documentation. We have published the three functions above.

My concern is that organizations relying on this guidance have a false sense of ‘security’ if they follow this guidance. Following this ‘guidance’ is certainly necessary at a minimum, but additional risks exist that Oracle isn’t adding to their documentation. We’d love to see Oracle increase its effectiveness which can only be done by taking a hard look at their internal standards and setting a regular schedule for testing their guidance and updating this documentation. Compliance with this document is necessary, but with Oracle, sometimes you need to fill in the blanks…

Recommended Services from ERP Risk Advisors

We offer assessment services that can evaluate your organization’s compliance with part or all of the recommendations in this MOS Note along with other high risks not considered by Oracle. This engagement can range from one to six weeks.

Since some of these risks need to be evaluated by reviewing access controls, a SaaS service to review role design may also be appropriate. We perform that service through our partner, CaoSys.

Contact us at erpra.net/contactus.html for more information about these services or CaoSys GRC solutions if you are interested in learning more. We offer our Role / Responsibility analysis consulting as a service (CS*Proviso) or via installed software (CS*Comply). See more about CaoSys GRC solutions at caosys.com.

About ERP Risk Advisors

ERP Risk Advisors is a leading provider of Risk Advisory services for organizations using Oracle Applications. We provide consulting and training services related to compliance, security, risk management, and controls. We also assist organizations in implementing GRC-related software from industry-leading companies such as Oracle, CaoSys, Smart ERP Solutions, and MentiSoftware.

About Jeffrey T. Hare, CPA CISA CIA

Jeffrey Hare, CPA CIA CISA is the founder and CEO of ERP Risk Advisors. His extensive background includes public accounting (including Big 4 experience), industry, and Oracle Applications consulting experience. Jeffrey has been working in the Oracle Applications space since 1998 with implementation, upgrade, and support experience. Jeffrey is a Certified Public Accountant (CPA), a Certified Information Systems Auditor (CISA), and a Certified Internal Auditor (CIA). Jeffrey has worked in various countries including Austria, Australia, Brazil, Canada, Germany, Ireland, Mexico, Panama, Saudi Arabia, United Arab Emirates, and United Kingdom. Jeffrey is a graduate of Arizona State University and lives in northern Colorado with his wife and three daughters. You can reach him at jhare@erpra.net or (970) 324-1450

Jeffrey's first solo book project Oracle E-Business Suite Controls: Application Security Best Practices was released in 2009. He published a second book called Auditing Oracle E-Business Suite: Common Issues in 2015. He is working on an expansion of his first book which will be called Oracle E-Business Suite Controls: Foundational Principles and is working on an update for his second book. Both are expected to be released in 2017.

He has written various white papers and other articles, some of which have been published by organizations such as ISACA, the ACFE, and the OAUG. Jeffrey is a contributing author for the book “Best Practices in Financial Risk Management” published in 2009.

LinkedIn: linkedin.com/in/jeffreythare

Twitter: twitter.com/jeffreythare

Blog: jeffreythare.blogspot.com

Friday, January 13, 2017

Why Utilities Diagnostics Should NOT Be In Scope for SOX

The setting of the Utilities: Diagnostics profile option has been a source of scrutiny for our clients over the past few years. Some auditors have suggested that access in Production allowed by the setting of Utilities: Diagnostics could provide a back-door way to update financially significant data that a user would not be able to maintain through their normal access. Access this video at: https://youtu.be/5eXzhv7jTpM.

This testing was done on an R12 environment and the conclusions should not be applied to 11i or prior environments.

Recommended Services from ERP Risk Advisors

We offer an evaluation of Application Controls design effectiveness along with an analysis of the configurations. This service can be performed typically in one to three weeks.

Since some of these risks need to be evaluated by reviewing access controls, a SaaS service to review role design may also be appropriate. We perform that service through our partner, CaoSys.

Contact us at erpra.net/contactus.html for more information about these services or CaoSys GRC solutions if you are interested in learning more. We offer our Role / Responsibility analysis consutling as a service (CS*Proviso) or via installed software (CS*Comply). See more about CaoSys GRC solutions at caosys.com.

Appendix A- Screen Shots of how Utilities: Diagnostics works:
Following are a couple of screen shots related to Utilities: Diagnostics:

Friday, January 6, 2017

A Back Door Way to Changing Supplier Addresses in Oracle E-Business Suite

Background:

Most organizations have a control defined over the entry of and changes to Supplier Master data including the Supplier’s address. Allowing a user as part of the payment process to change the address for a check would essentially allow them to circumvent the expected controls that normally happen through the supplier master maintenance process.

Risk Presented and Analysis:

The Allow Address Change option in the Payables Options form enable a user to make a change to the Supplier’s address to re-direct where a check it sent. This would allow a fraudster to make a change and give them physical possession of a check that is not meant for them. There are various ways that fraudster could get that check cashed.

Therefore, this option should never be allowed to be set for any Operating Unit. All changes to a Supplier’s mailing address should follow your organization’s normal change process rather than allowing a clerk to make this one-off adjustment when entering a check.

If this is currently allowed, it needs to be disabled (unchecked). The process should be to require an additional address be set up or a change to the default address through the Supplier Master process.

Following is a screen shot of the Payables Options configuration form:

Note that this configuration is org (OU / org_id) specific. If you have more than one Operating Unit, this configuration will need to be evaluated / changed for each Operating Unit independently.

Following is a description of this process from the Oracle Payables Users Guide:

Recording a manual payment

1. In the Payments window select the Manual Type.

2. Enter a Trading Partner. The Supplier Number is automatically displayed. If there are multiple Supplier Sites, select the appropriate site from the list.

3. Enter the Payment document Date. The date must be in an open period. If the Allow Pre-Date Payables option is enabled, then you can only predate a computer-generated payment.

4. Enter the Bank Account from which you want to make the payment.

5. Select a Payment Method.

6. Select the type of Payment Document if Printed is selected as the Payment Process Profile.

7. Select a Payment Process Profile.

8. If you have enabled the Allow Remit-to Account Override Payables option, then you can select a different, active Remit-to account. The list of values includes bank accounts assigned to the supplier that have the same payment currency.

Important: The system ensures that Quick payments cannot be created for payment to inactive bank accounts.

9. Enter a Maturity Date if the Bills Payable payment method is selected.

10. Select a Rate Type.

11. If necessary, enter or adjust other information:

• If you created the payment for an address different from the supplier site and your Allow Address Change Payables Option page, Payments tab is enabled, adjust the address. For example, you may need to send an expense check to a

consultant working at a site away from home.

Following is an excerpt from the process related to recording a manual payment (which is often used to generate a ‘one off’ check.

Recommendations:

Following are our recommendations related to this risk and configuration:

1. “Allow Address Change” should NOT be checked (enabled) for any Operating Unit

2. Any changes to Payables Options configurations should be approved by someone responsible for fraud prevention. In other words, the Payables Process Owner should NOT be able to approve a change to this configuration.

3. If you have a tool to monitor access control risks, you should have rules as follows:

a. Single function rule related to Payables Options – verify that the only users with access to this function are those that can make changes in Prod once approved as part of your organization’s change management process – typically this means IT users / business analysts.

b. SoD rules – Enter AP Payments vs Payables Options – no one user should have access to the ability to generate AP Payments (particularly the function that allows single payments to be created) as well as the ability to maintain Payables Options. The SoD rule would be “Enter AP Payments vs Payables Options” – our rule ID PP048.

Note: For recommendation 3 above, we offer a service to evaluate access control risks that includes Segregation of Duties conflicts, single function risks (Restricted Access), and access to sensitive data. Our rule set is the most comprehensive in the industry. Find out more about our rule set at: erpra.net/Content.html. Our content includes Rule ID PP109 as a single function rule to identify who has access to maintain Payables Options. Our content also includes Rule ID PP048 “Enter AP Payments vs Payables Options” since no one user should have access to the ability to generate AP Payments (particularly the function that allows single payments to be created) as well as the ability to maintain Payables Options.

Contact us at erpra.net/contactus.html for more information about CaoSys GRC solutions if you are interested in learning more. We offer our Role / Responsibility analysis solutions as a service (CS*Proviso) or via installed software (CS*Proviso). See more about CaoSys GRC solutions at caosys.com.

Download a pdf of this article here.

Recommended Services from ERP Risk Advisors

We offer an evaluation of Application Controls design effectiveness along with an analysis of the configurations. This service can be performed typically in one to three weeks.

Since some of these risks need to be evaluated by reviewing access controls, a SaaS service to review role design may also be appropriate. We perform that service through our partner, CaoSys.

Contact us at erpra.net/contactus.html for more information about these services or CaoSys GRC solutions if you are interested in learning more. We offer our Role / Responsibility analysis consutling as a service (CS*Proviso) or via installed software (CS*Comply). See more about CaoSys GRC solutions at caosys.com.

Appendix A- Definition of Payables Options:

This query below can be run to identify how this configuration is set:

Select *

From AP_SYSTEM_PARAMETERS_ALL

The column related to the “Allow Address Change” configuration is UPDATE_PAY_SITE_FLAG. A value of ‘Y’ means the capabilities are allowed – i.e. they CAN change the Supplier Address when a manual payment is processed, effectively bypassing any controls over the Supplier master.

About ERP Risk Advisors

About Jeffrey T. Hare, CPA CISA CIA

Jeffrey's first solo book project "Oracle E-Business Suite Controls: Application Security Best Practices" was released in 2009. His second book project “Auditing Oracle E-Business Suite: Common Issues” was released in 2015. Jeffrey has written various white papers and other articles, some of which have been published by organizations such as ISACA, the ACFE, and the OAUG. Request these white papers here. Jeffrey is a contributing author for the book “Best Practices in Financial Risk Management” published in 2009.

LinkedIn: linkedin.com/in/jeffreythare

Twitter: twitter.com/jeffreythare

Blog: jeffreythare.blogspot.com

Tuesday, January 14, 2014

Reliability of Application Controls in ERP Systems Should be Questioned by Auditors

Reliability of Application Controls in ERP Systems Should be Questioned by Auditors
By Jeffrey T. Hare, CPA CIA CISA

The guidance related to relying on Automated (or Application) Controls was originally published by Institute of Internal Auditors (IIA) in July 2007. The IIA Global Technology Audit Guide number 8 (GTAG 8) takes into account the guidance provided by the PCAOB in Auditing Standard No. 12 (Appendix B, in particular). The testing of an automated control typically requires the skills of both an internal auditor (functional or process auditor) as well as the skills of an IT auditor.

In fact, in GTAG 8, the IIA recommends that the help of an IT auditor is needed.[1] IT auditors are typically needed to help test IT general controls such as controls over changes to the configurations, code changes, segregation of duties, and access controls.

The most common way to test the automated controls is through a “benchmark strategy.” The IIA guidance summarizes the PCOAB standard as follows “If general controls that are used to monitor program changes, access to programs, and computer operations are effective and continue to be tested on a regular basis, the auditor can conclude that the application control is effective without having to repeat the previous year’s control test. This is especially true if the auditor verifies that the application control has not changed since the auditor last tested the application control.”[2]

Since IT auditors are typically tasked with testing IT general controls, the IT auditor normally is responsible for testing ‘program changes, access to programs, and computer operations’ as well as ‘that the application control has not changed since the auditor last tested the application control.’

The beauty of ERP systems, such as Oracle’s E-Business Suite and SAP, is that an application control can be configured to meet an organization’s different requirements. The ‘configurations’ drive the design of the control and, therefore, a change to the configuration can change the design of the control. From a Sarbanes-Oxley perspective, the PCAOB and your external auditors should care immensely about whether or not the configurations related to key controls change from year to year. If these configurations change, the auditor of the related application control should re-benchmark the control or test the control in another way.

The Problem

The problem faced by most organizations is there is no change history specifically built into the system for the configurations related to key controls. In fact, as most auditors have discovered, little change history exists in most ERP systems unless the system is built to do so. In ERP systems, such as Oracle’s E-Business Suite, the change history of a transaction only exists in a few cases and it rarely exists for configurations.

This leaves an IT auditor with a dilemma when trying to test the ‘general controls used to monitor program changes’ as is required in the IIA and PCAOB guidance. How does an auditor get comfortable that no change has been made during an audit period?

Absent audit history created by the system, ERP systems have built-in ‘row-who’ information. This information typically tells you when a record is created and when it is last updated. Therefore, an auditor can reasonably assume that when the ‘last updated by’ time stamp isn’t within the current audit period (and should be in the period in which the configuration was ‘baselined’ or earlier) that the configuration hasn’t been changed.

There are three problems with relying on the ‘row who’ information:

Most systems don’t have the queries predefined
A false positive can be occur when data from another column is changed
Some ‘back door’ methods of updating the data don’t change the ‘row who’ information

Lack of predefined queries

In an average system, there may be dozens of configurations related to key controls. Ideally, the software provider would develop a ‘read only’ role that auditors could use to query the data. Sadly, this information isn’t provided by most software companies or this information is only available in another product you need to license such as a GRC suite.

False positives

Another issue is false positives whereby a different column is updated than the column related to the key control. Take a look at this change history:

Change	Column A	Column B	Created Date	Updated Date
Initial data entry	Yes	Yes	01-Jan-2014	01-Jan-2014
Change 1	No	Yes	01-Jan-2014	15-Jan-2014
Change 2	Yes	Yes	01-Jan-2014	19-Jan-2014

In this example, column A’s data is NOT related to the key control and column B’s is what impacts the design of the key control. As change 1 and change 2 are made, the updated date changes from 01-Jan-2014 to 15-Jan-2014 to 19-Jan-2014. So if you are an auditor looking at the change history during 2014 you’d could falsely draw the conclusion that the configuration related to the key control (Column B) was changed when actually it was a different column (Column A) that was changed.

Back door methods of updating data

Finally, back door methods such as the use of an unsecured database login or SQL injection could change the data in column B, but not update the Updated Date column. This risk is especially acute in certain systems such as Oracle E-Business Suite that provides over 50 forms and web pages that allow SQL injection (and in some cases ability to execute packages or OS scripts).

The Solution

If auditors are to rely on application controls and have reasonable assurance of operating effectiveness, a detailed audit trail / change tracking history is essential. Most auditors give organizations a ‘pass’ when they don’t have detailed change history and take a sample from the change management tickets rather than insist the client develop the change history so the sample can be taken from the system. We believe this approach CANNOT provide reasonable assurance related to the changes to configurations related to key controls.

The technology necessary to develop this change history differs from system to system. In our area of domain expertise, Oracle E-Business Suite, there are reasonably priced third party systems that can be deployed using database triggers to create the necessary change history. The benefits of such technology extends well beyond Sarbanes-Oxley ‘key control’ requirements and can be applied to updates to master data (such as supplier bank accounts) as well as other requirements (password resets for critical access accounts, forms that allow SQL injection, etc.).

The Conclusion

So here we are in 2014 – nearly seven years after the issuance of guidance by the IIA and the challenges facing reliance on automated controls are not much different than those faced when the guidance was first issued. The time has come for auditors to hold client’s feet to the fire. As it relates to application controls, either insist on a system-based audit trail or disqualify the reliance on the application control. You’ve given a ‘pass’ to your clients for far too long when reasonable assurance cannot ‘reasonably’ be attained using the current approach.

About the Author

Jeffrey Hare, CPA CIA CISA is the founder and CEO of ERP Risk Advisors. His extensive background includes public accounting (including Big 4 experience), industry, and Oracle Applications consulting experience. Jeffrey has been working in the Oracle Applications space since 1998 with implementation, upgrade, and support experience. Jeffrey is a Certified Public Accountant (CPA), a Certified Information Systems Auditor (CISA), and a Certified Internal Auditor (CIA). He has worked in various countries including Australia, Austria, Canada, Mexico, Brazil, United Kingdom, Ireland, Saudi Arabia, and Germany. Jeffrey is a graduate of Arizona State University and lives in northern Colorado with his wife and three daughters.

[1] IIA GTAG 8, page 14 “Need for Specialized Audit Resources”

[2] IIA GTAG 8, page 3 “Benchmarking”

Friday, June 7, 2013

Password Decryption Risk for Oracle E-Business Suite

Password Decryption Risk for Oracle E-Business Suite

Unsecured passwords can allow a hacker to access application and database accounts by decrypting their passwords...

We had a great webinar in May in conjunction with Steve Kost of Integrigy. We covered the risks related to the decryption of passwords. Three questions for you:

Have you applied the new hash password scheme? If you aren’t sure, read more about it in MOS Notes 457166.1 and 1084956.1).
Do you consider the column that hosts the password data in the FND_USER table as ‘sensitive data.’
Is your password length for the applications and database less than eight digits?

If you have answered ‘no’ to any of these questions, you need to see our recorded webinar based on the webinar titled “Account Password Decryption, Threat Explored.” This webinar along with others we have done over the past few years can be accessed at: http://www.erpra.net/WebinarAccessForm.html

Tuesday, May 21, 2013

Oracle E-Business Suite: SYSADMIN must have password expiration set

The risks related to SYSADMIN are often misunderstood. It is a critical account to leave active, yet we find that many organizations don't set the password expiration days because they fear that the account will be locked and the system will come to a halt (including workflows) if the password expires. This is NOT the case. If the password expires it will need to be reset next time someone logs in using that account (just like ALL accounts). However the processes that run in the background tied to that login will still continue to perform as expected.

This is also supported by Oracle. Take a look at MOS Note 403537.1.

Find out more about this topic at: http://erpra.net/files/Chapter_7_Excerpt_Use_and_Care_of_Generic_Logins.pdf

As always, if you have questions related to this or other topics, please email me at jhare...at... erpra.net.

Tuesday, April 23, 2013

Webinar, Wednesday April 24, 2013 2:00 ET: Sensitive Administrative Pages in Oracle E-Business Suite: Are You Overlooking This Threat?

Webinar: Sensitive Administrative Pages in Oracle E-Business Suite: Are You Overlooking This Threat?

Hear from industry experts, Jeffrey T. Hare, CPA CISA CIA from ERP Risk Advisors and Stephen Kost, from Integrigy Corporation. This is the second in a new series of webinars by ERP Risk Advisors and Integrigy Corporation presenting hidden security threats found in the Oracle E-Business Suite.

Within the Oracle E-Business Suite, numerous pages and forms allow a privileged end-user to enter SQL statements, operating system commands, or modify the application configuration. Continuing our webinar series on the Hidden Security Threats in Oracle E-Business Suite, this one hour educational webinar will explore the risks associated with sensitive administrative pages and how these pages can be used to circumvent application controls. We will look at what sensitive administrative pages are, how they can be used to manipulate data or commit fraud, how you can determine who has access to these pages, and what is required to mitigate the threat.

ERP Risk Advisors blog

Popular Posts

Monday, January 30, 2017