As part of our webinar series for October’s National Cybersecurity Awareness Month, we recently offered a webinar on Oracle ERP Cloud, covering implementation and governance of security. Here are some of the key points from our discussion.
The benefits of cloud-based applications are many – they are easy to access, requiring only the internet and a browser. Fewer resources are required to support cloud applications, enabling focus to shift from back-end maintenance to business operations. It’s also easier to keep cloud applications current, since upgrades are pushed by the cloud provider and they force companies to adopt a more regular schedule for applying patches and updates.
Oracle ERP Cloud Security Model
Oracle ERP Cloud security differs significantly from Oracle E-Business Suite (EBS). The concepts of Responsibility, Menu and Function have been replaced by Job Roles, Duty Roles and Privileges. In general, a user is assigned a Job Role, which is made up of Duty Roles and Privileges. Data a user can access is secured through a combination of data-security and data-access policies. Abstract Roles are also used to provide functionality across a common group of users based on organizational structure.
Key Security Risks
Oracle’s new security model can expose organizations to risk if it isn’t configured carefully. Below are a few examples of issues we’ve encountered in various engagements:
- Segregation-of-duties conflicts (SoD): Seeded roles (those provided out of the box as part of the Oracle ERP Cloud product) can include high-risk conflicts, and the problem is compounded when a user is assigned multiple roles. For example, many seeded roles contain the ability to perform both setups and transactions, which is typically considered high-risk.
- Excessive access to sensitive data: Seeded roles can include inappropriate accesses that aren’t apparent when assigned. For example, some seeded roles provide a user the ability to manually create subledger journal entries.
- Automated controls not enabled: Oracle ERP Cloud provides options to enable automated controls, but controls are often not enabled by default.
Security Implementation Approach
Stakeholders
Truly successful projects are a product of having the right stakeholders involved, both as part of the implementation in general and when designing security. Business-process owners will make final decisions on requirements, role design and controls. Internal resources will configure Oracle, conduct testing and help stakeholders understand the security design’s capabilities and limitations. Audit will validate that the risk rule set conforms to best practices and provide guidance on mitigating control design. Information-security resources will clarify the different security elements and how they impact user functionality. All stakeholders must work together to facilitate a successful end product.
Developing the Risk Framework
One of the most critical components of a successful implementation in the early phases is the development and communication of a robust risk-ranking framework and corresponding SoD polices. This step ensures that all stakeholders are on the same page regarding risk levels and definitions and is key to applying decisions consistently based on common business objectives.
An SoD risk framework should define and rank the risks, and describe the action required for each risk. The risk description should outline certain risk qualifiers that help determine the risk rating, and the required action should define whether remediation or mitigation is required. Organizations should identify those key business activities that, when in conflict, create a violation that aligns with the definitions within the SoD framework, and assign a risk ranking to these activities based on the descriptions within its SoD framework. Once the business activities and conflicting functionalities have been defined or identified, associated privileges should be mapped to those activities and functionalities. The privilege assignment is a prerequisite for the assessment of the organization’s role design.
Role Design
Following development of the risk framework, role design can commence and should be based on future-state business processes and user-access requirements; it is important, however, to be mindful about separating conflicting business activities defined in the organizations SoD framework. Privileges and data-security policies should be grouped into duty roles, which will then be combined to create job roles and abstract roles. Below are additional recommendations to keep in mind when designing security:
- Maintain design consistency: The convention of assigning privileges only to duty roles, duty roles and abstract roles to job roles, and job roles to users should be enforced to ensure a well-structured, consistent and scalable role design.
- Develop a strong naming convention: A naming convention should be established and should clearly articulate the role purpose to ensure that end users, management and system administrators are all aware of a role’s capabilities.
- Prevent function duplication: Limit the duplication of key functions across multiple job roles as much as possible.
- Incorporate a SoD tool: Consider utilizing a SoD tool during the design process to ensure that roles are developed free of conflicts.
Test and Implement
Building security in Oracle ERP cloud is an iterative process, and role redesign may be necessary as latent requirements and user-access risks are discovered through security analyses and unit- and user-acceptance testing. The steps in the iterative security development and deployment cycle should be followed, listed below:
- Design, build and unit-test new roles
- Run security analysis to validate design
- Design user mapping and assign roles
- Run security analysis to validate user mapping and design
- Perform user-acceptance testing
- Migrate to production and go-live
During this process, it is important to manage user and business expectations. Communicate that the level of effort spent during testing and redesign phases can have a significant impact on the accuracy and functional effectiveness of the roles prior to go-live. The time in each phase will vary from project to project and will be driven by the number of custom roles created.
Governance for Oracle ERP Cloud Security
Consider developing ongoing governance processes before going live. Governance is critical for maintaining security policies, managing ongoing security and compliance risks, and facilitating organizational and role change management; this will better prepare your organization to be ready to face changes from go-live onward.
Implementing an Oracle ERP Cloud secure application architecture is a significant effort. Think of governance as continuing protection to secure your organization’s investment.
The full webinar is available online, and we will be releasing a white paper on the step-by-step approach to building a strong security architecture during Oracle ERP Cloud implementation and redesign projects, so stay tuned. Also, in case you missed any of the webinars from the Cybersecurity Awareness webinar series, you can still watch the replays.
