A Step-By-Step Approach to Building Strong Security Architecture During Oracle ERP Cloud Implementation and Redesign Projects
Organizations are becoming more accepting of moving their key business applications to the cloud, including their enterprise resource planning (ERP) systems. For companies looking to move to Oracle ERP Cloud, the advantages are many — high scalability, consistent processes, real-time financial reporting and, not the least of all, cost savings from a hosted solution. Focusing on these benefits, however, should not obscure the need for a strong application security design aimed to deter fraud and ensure that transactions performed in the cloud are appropriate and authorized.
As auditors and the Public Company Accounting Oversight Board (PCAOB) continue to increase scrutiny of Segregation of Duties (SoD), it is important that organizations planning to implement Oracle ERP Cloud include a strong security design within their requirements and project plans.
In this paper, we discuss the steps to achieve a secure Oracle ERP Cloud system and avoid some of the common pitfalls in the process.
Over the past few years, Oracle has been firmly shifting its software solutions portfolio model to the cloud, allowing organizations to focus more on business operations and less on back-end management of the supporting applications and infrastructure. As a result, organizations are rapidly transitioning off the standard on-premise, internally managed technologies in favor of a model that integrates key financial applications onto Oracle’s cloud infrastructure stack, which requires only a browser and an internet connection to access.
The idea of the cloud has existed since the 1960s but has become more popular in recent years as computer processing power and bandwidth have made cloud-based services more accessible. Cloud computing leverages shared, elastic resources that can be delivered to users through self-service web technologies. This allows companies to use only what they need instead of purchasing resources and creating redundancies within their own data center.
Company board members and chief executives are becoming better educated in cloud capabilities and the potential cost savings, and chief information officers (CIOs) are increasingly asked to have a strategy for moving resources to the cloud. This strategy may include data center services, email, VOIP and phone services, Microsoft Office products, customer relationship management (CRM), and enterprise resource planning (ERP) solutions.
As more organizations begin developing their ERP cloud strategy, a number of considerations will drive executive decision-making, including compliance requirements and the impact that a cloud solution will have on the organization’s internal control structure. Most notably, management will have to be proactive in planning for application-specific security to support strong segregation-of-duties (SoD) and appropriate sensitive access levels. Leading practices indicate that access should be granted based on a user’s job duties as well as management’s risk tolerance for performing conflicting functions (e.g., “Create a Supplier” and “Issue Payment to a Supplier”).
A well thoughtout and implemented ERP security design is the foundation for how the company’s employees will interact with the application for years to come, allowing them to appropriately enter business transactions and interpret information used to manage the business. An effective design also scales with the growth of the organization without creating unexpected security gaps.
Companies that do not maintain consistency with a well-designed security model may face challenges during upgrades, acquisitions, employee hiring or termination, and other changes to the business. Consequences of a poorly executed security design include, but are not limited to:
In the full paper, we explain key concepts and provide recommendations to achieve a robust security model and avoid these problems.
The security model within Oracle ERP Cloud is very different from that of the traditional Oracle E-Business Suite (EBS) versions. Oracle has replaced the “responsibility” and “menu” containers with a role-based model that allows for a more robust and scalable approach to user administration.
The security models for Oracle ERP Cloud (Financials) and Oracle’s other cloud applications (HCM, CX, SCM, EPM, etc.) are slightly different, and as such, our focus for this paper will be on Oracle ERP Cloud. However, the concepts for building and evaluating security can be applied toward the other applications.
Although the security design of the Oracle ERP Cloud applications can vary slightly for different offerings such as Financials and Human Capital Management, generally, the application security architecture can be separated into two considerations — functional access and data access. The different components of the Oracle ERP Cloud security model are discussed in detail below:
Duty Roles are made up of different privileges within Oracle ERP Cloud to perform specific actions with specific data; typically, they are very specific task-based activities within the business process. An example of a duty role is “Payables Invoice Creation Duty.” The collection of privileges within this duty role would enable one to create and update an invoice, either through mass updates, updates through uploads or direct modifications within the invoice form. The duty roles are assigned directly to job roles. They are not assigned directly to a user. (Note: While duty roles can be assigned to other duty roles, it is not recommended to take this approach except when strictly copying an out-of-the- box role provided by Oracle.)
Key point: The key to taking a proactive security approach is establishing strong policies governing security design and a solid foundation of job roles that are conflict-free.
Prior to Release 12, data access was managed by data roles and data security policies. A security model introduced by Oracle for new users of Release 11 and all users of Release 12 eliminated the need for data roles. Data access is now managed by a combination of data security policies and data access policies. This new access functionality exists within ERP Cloud and Supply Chain Management (SCM) Cloud.
In EBS Financials, data security was managed through “Profile Options” and access was granted based on “Ledgers,” “Operating Units” and “Inventory Orgs.” This data model still applies, but instead of assigning data access to a responsibility, the data access is restricted through data security policies and data access assigned to users in Oracle ERP Cloud.
Data Access Policies are specific values of database resources. These resource values need to be assigned to each user and to each role that is provisioned to it. For example, the job role “U.S. AP Clerk” would allow the user to perform all the functions of a payables clerk, but only within the U.S. business unit. The privileges inherited by the job role will allow the user to view and transact within all the appropriate business objects such as invoice and payment terms. The data security policy will restrict the access to only the specific business units assigned through the data access policies, in this case, the U.S. operating unit. This becomes very useful when larger companies have several employees with the same job title, but with each employee needing to work within a different set of data.
Data Security Policies define the permissible level of data access allowed in reference to a specific database resource, such as business unit, ledger and asset book, and are assigned to a job role. They act as the WHERE clauses to limit what data can be accessed by those database resources. Due to this, in order for a job role to reach the desired level of access, it may take several data security policies.
Provisioning Rules are the rules that define how access will be granted to users. They ensure that the integrity of the Oracle security model is maintained by laying down specific rules for maintaining user access requests. We discuss provisioning rules in more detail in Steps 4 and 5 in the next section.