The risk of SQL forms within the Oracle Applications- How did that Happen?

Transcription

1 The risk of SQL forms within the Oracle Applications- How did that Happen? Alfredo Pantaleon, Sr. Principal- GRC Services, KBACE Jeffrey Hare, CPA CISA CIA - ERP Seminars March 26,

2 Presenter Alfredo Pantaleon, Sr. Principal- GRC Services, KBACE: Formerly with Logical Apps and KPMG/BearingPoint, Alfredo has over 10 years experience in ERP Integrations for several Fortune 50 Corporations, including Oracle, KPMG, Bearing Point, GE, Motorola, CBS, Michelin, BMW, etc., and Public Sector and Government Agencies such as FAA, DHHS, DOT, etc. as a results driven project management professional. Mr. Pantaleon has served clients in industries including High Technology, Telecommunications, Manufacturing, and Security. With a deep understanding of Oracle technologies and the integration of business processes, corporate governance and a strong financials background, Alfredo provides both functional and technical leadership to any size of operations, both domestic and international. 2

3 Agenda Introductions Objective Survey Findings Risks Scenarios Recommendations Q&A Closing 3

4 KBACE Corporate Overview KBACE maximizes the value that Oracle s clients derive from their software investment and goes to market with Oracle to augment the generation of new license opportunities. Incorporated in 1998 Privately held, employee owned, cash-flow positive since inception Headquartered in Nashua, NH with national presence Maintain significant portfolio of Oracle install base clients Specialize solely on the Oracle E-Business Suite & related technology Multiple LOBs Professional Services Support Services Analytics Advanced Technologies Education KBACE runs our business on the Oracle E-Business Suite Release 12 4

5 Professional Services Oracle Application Consulting Practices Financials Supply Chain Manufacturing Projects CRM Advanced Technology Human Capital Management (HCM) Data Services Governance Risk and Compliance (GRC) Development centers in Nashua, NH and Bangalore India Worldwide Certified Advantage Partner Participated with Oracle on Accelerator and Methodology development Currently partnering with Oracle on Fusion validation 5

6 Objective Oracle s E-Business Suite has unique risks that need to be evaluated when designing application security and controls. We will look at one of the highest risk areas in Oracle s E-Business Suite, forms that allow SQL statements to be embedded in them. This presentation will address the following: Overview of SQL forms and the related risks Examples of how SQL forms can be used to manipulate data and commit fraud Best practices related to SQL forms Strategies to monitor access to and activity in SQL forms 6

7 SQL Forms Survey- Awareness of SQL forms risks? I was not aware of the risk 32.6% 0% 9% I have read about SQL forms, but didn't/don't understand the risks 13.0% My company is aware of the risks, but have chosen not to address them 4.3% 22% 4% 4% 11% 4% 13% 33% My company is aware of the risks, but feels monitoring software is too expensive 10.8% My company has put a third party trigger or log-based solution to monitor them 4.3% My company uses Oracle's Sys Admin audit trail to m onitor the activity 4.3% My company requires all SQL form activity to go through IT Change Management 21.7% My company reconciles actually activity to our Change Managem ent approvals 0.0% Other 8.6% 7

8 SQL Forms Survey- How long as Oracle EBS customer? 3% 5% 5% 3% We are not yet live with the system 5.1% 20% We have been live less than 1 year 2.5% We have been live 2-4 years 20.5% We have been live 5 or more years 64.1% 64% Other 2.5% No Responses 5.1% 8

9 SQL Forms Survey- Number of Oracle users? 3% 13% 5% 11% % % Over

10 Risks What type of risks are exposed when users have access to SQL forms? Override of change management process Fraud - employees, consultants Data theft Unauthorized changes to security References Metalink note Best Practices for Securing the E-Business Suite Additional information available in the internal control repository (ICR). 10

11 Scenarios Fraudulent bank account updates for the purpose of misdirecting funds payment to a supplier Reset of SYSADMIN login for the propose of unapproved access and system updates The objective of the following scenarios is to show limited examples of how fraud may be committed. These methods shows are not meant to inspire their use for any activities that may be illegal or unethical. The examples shown are for presentation purposes only and do not outline the full business processes or controls that in place around those processes. 11

12 Scenario 1- Fraudulent Bank Account Update A Supplier has contacted procurement about payments they have not received. Through some reporting it has been found that payments were made however there is some inconsistency in the system. The bank account looks as though it had been changed and then changed back however there are no records of this being approved. Cause- An oracle alert SQL form was used to update the bank account from behind the scenes and then update it back. 12

13 Unapproved Alert is created The select statement itself does not matter as long as it returns 1 row. A clever person could go so far as fire the trigger when the payment is created with the victim bank account and update the bank account record. This is being done as on demand however someone could make it much more intelligent using the event tab 13

14 Unapproved Alert is created There are a couple setups needed for triggers but they are fairly simple and flexible. Alerts are powerful since they can launch programs, sql statements and pl/sql. It should be noted that normal users don t usually have access to create alerts. Create an action set, add an action Select a action type Notice SQL or OS Script Call a pl/sql package or write sql statements 14

15 Take a look at the Bank account BEFORE Bank accounts are not defined per vendor but are defined as bank accounts records and then assigned to other pieces of data. They are used on vendors, vendor sites and payments as an example. This will be the bank account show on the vendor site. This is the value seen on payment and transactions The bank account number is the victim. This is important because it is not usually seen on the transaction, the name is. 15

16 A payment is created A payment is created using the victim bank account. The bad guy could have an alert set to see this or just know what day payments are made so the alert can fire. The trick is to update the account after the payment record is created. Another note is that this type of fraud would likely be directed at electronic payments. The bank account number shows here in the LOV but not on the form. 16

17 The unapproved Alert is fired The alert may be manually initiated to update the account. The smart perpetrator may goes as far as changing the account back after the EFT is completed so it will be tougher for someone to catch what has happened. The alert is raised which will update the records. The last updated date and last updated by will not change. It will look as if the last person changed the record. 17

18 Bank account AFTER payment and back again If someone were to review the bank account record the account number would be different. The last updated date and last update by would not show any different from before. The perpetrator could then update again and effectively wipe away some of the tracks! The bank account number Update by dgeryol at 6:41:02 pm The bank account number changed Updated by dgeryol at 6:41:02 pm 18

19 Scenario 2- Reset of SYSADMIN login Upon routine audit of the system the system admin could not login to the SYSADMIN account. The audit reports also showed a high number of logins by the SYSADMIN user and updates to key profile options. There was no record of approval for any changes by this user and profile options are not normally updated with this login. Cause- A quality plan from the Oracle Quality application was used to reset the SYSADMIN password so that illegal logins and updates could be made. 19

20 SYSADMIN login- Normal Admin personnel may use the SYSADMIN application user for certain admin tasks. The password is tightly controlled SYSADMIN NORMALLY HAS KEYS TO THE KINGDOM TYPE RESPONSBILITIES 20

21 Oracle Quality- not just for Quality Control, but Quality Access! Oracle Quality is a powerful application used in areas like receiving and manufacturing to help capture data related to quality, measurement, specifications and other similar data. The data entry into plans can translate into automated reporting, notifications and updates to areas of the system. Setup is normally where you will find the function to create plans however many have this function available for creating adhoc plans. 21

22 Create a QA plan A fraudulent QA plan is created with minimal information. These plans can be deleted once they are done being used. This removes many traces of what has been done. A bogus QA plan is created Actions.access to GOLD 22

23 Create the condition and pick the event Once a plan is created you need only define your action condition that triggers your action. You then just pick your method to execute. This sets up a condition or trigger value Here are my choices to do damage Operating System scripts and SQL scripts 23

24 Create the action details (sql entry) Using the details window you can write a sql statement or call pl/sql procedures to do your bidding. EXECUTING A STANDARD ORACLE PACKAGE TO UPDATE A USERS PASSWORD WITHOUT KNOWING THE EXISTING PASSWORD. 24

25 Enter a QA result to initiate the plan illegal update To execute the plan a simple entry must be made into the fraudulent plan with the trigger condition. Entering QA results is a fairly standard function 25

26 Entering the trigger condition initiates an update When the trigger condition is entered and saved a periodic alert is run. This is really the only indicator that something has been done. The alert itself is not really traceable since we can delete our trail! TRIGGER CONDITION INITIATED THE PERIODIC ALERT 26

27 USER MAKES ILLEGAL LOGIN AS SYSADMIN The offending user now logins in as SYSADMIN with the password that was set. welcome123 27

28 Recommendations Conduct a thorough analysis of the system to identify SQL forms (see references) and also control risks on master data and system setup forms. Review users that have access to any 2 of the following 3 risk areas; system setups, master data, transaction forms. If there are no system controls there should be well documented manual and closely monitored manual controls. System controls are recommended and should cover the following; Segregation of Duties Change Control System Auditing or Monitoring 28

29 Best Practices Segregation of duties It is not all about transaction forms. If users do not need to see data such as bank accounts, do not let them. This will mitigate people from seeing temptation. Do not allow end users to have access to SQL forms. These are meant to be configured as part of the system and not as a day to day production task. An overall risk assessment should highlight those with access to these areas and SQL forms Change Control Do not allow sensitive information or master data to get changed without a good change process. Master data management can be a great success to an organization, or a great risk. Changes to system setups such as SQL forms should be under change control System Auditing or Monitoring Audit key data for setups and master data Review audit reports regularly to reconcile approved activity to actual activity Mediate conditions that led to any unauthorized activity 29

30 Record History (row who?) Limitations Advanced Oracle Auditing Pro Cons Alerts Pro Cons Triggers / Logs Pro Cons Monitoring Strategies 30

31 Q&A Any questions that we do not get to will be addressed via Please all other questions to the presenter directly This is was an actual Webinar and can be replayed at: Services Tab Webinars 31

32 Thank You Alfredo Pantaleon, Sr. Principal - GRC Services, KBACE apantaleon@kbace.com (561)