Building Your JD Edwards Security Strategy
When revamping your JDE security, develop a strategic approach specific to your company’s needs and resources. In this blog post, I will show you how to use use design-first thinking, process design, and duty segregation to establish a JDE security security strategy.
Has it been a while since you have implemented Oracle JD Edwards (JDE) at your company? Since implementation much has likely changed, but the initial security setup has remained and it is time to start rethinking it.
Some reasons to revamp JDE security include:
Roles are no longer aligned to current business processes
Duties are not clearly defined and it is becoming harder to justify open access in JDE
People wear too many hats at the same time and need access to more than what their job entails
There are no defined controls for assigning and delegating security
User management takes significant efforts
With current emphasis on security breaches and meeting compliance and internal audit requirements, it is time to have a serious look at how your company’s JDE security is set up and what needs to be done to get to a secure Closed Security Model.
Undertake a Strategic Approach
To successfully revamp your organization’s Enterprise Resource Planning system security, it is important that you approach it from a strategic perspective rather than as a simple technical solution. Improving JDE Security has more to do with capturing requirements and creating a well-thought design. It must take into account the company culture, structure, compliance and regulatory requirements as well as how the internal business functions interact with each other. With that understanding, it becomes easier to review published best practices and then use them as a guide to create your own flavor. Otherwise, the users will be disrupted, processes will become intertwined with access woes and the whole security revamp will fall on its face, despite having the best tools and experts on hand.
‘Closed’ Security Model
This strategy denies all actions to any object by default. The idea is to grant access to specific role / user in order for them to complete their job. This approach takes more time in the design phase, but provides the necessary secure environment that meets your business needs.
Design First Thinking
Create a detailed design document. Start by identifying all stakeholders and capture their requirements to perform their jobs. This entails interviewing all stakeholders at different levels to document what they are responsible for. If you currently have detailed access data, you can use that to accelerate this process. In some cases, challenge why they are doing something that falls outside of their job description.
Understand the cross-functional requirements of each department / business function. It is important that each business function reviews such cross-functional requests and approve them before it is incorporated in the design. Validate any concerns and obtain sign offs.
Document and analyze these requirements and compare with industry best practices. This will help quantify and validate whether they are in line with such practices and capture the exceptions. These exceptions should be signed off by business leaders and internal audit and then incorporated in the design as well as any controls that are used for audit.
Outline each user and the roles that they should have along with the level of access. This will help get a clear picture of the what should be included in a role to minimize and simplify roles. Create a separate set of roles that will cater to cross-functional access. This is generally “view only” access with the ability to look up information or run reports for verification.
Process Based Roles
Process Based Roles are gaining momentum as they are easier to manage and are specific to individual business processes. The security is assigned to the role such that a business process can function in isolation. These process based roles are then assigned to users who need to perform that business process.
Understand Requirements around Segregation of Duties
Segregation of Duties (SOD) is a critical component to be reviewed by internal audit. When creating the security design, it is important to add internal audit as a key stakeholder. Capture their requirements for controls, verification and mitigation of SOD infractions. If this is incorporated in the design from the start, it helps simplify the implementation. This may also trigger the need for defining processes that cater to situations where additional access may need to be granted temporarily and helps document the actions for audit purposes.
Emphasize Change Management
Accept the fact that this revamp is a change in how the users perform their duties on a daily basis and in many cases, have been doing it for a long time. Change management, therefore, should be a critical factor in your strategy and approach. You should have a full buy-in from the senior management before you even start the project. They will need to provide support during the roll out and the transition period. Get sign offs from key business stakeholders on the design document before it is handed off to the technical team. Ensure that you have outlined all areas where the impact is higher as a result of the new security setup.
Please visit our other articles on JDE Security Best Practices. The recommendations focus on how to accomplish those best practices as defined specifically in Oracle JD Edwards EnterpriseOne (E1). The three-part series will address Function-based Roles, Business Unit Security, and Super Roles.
Smartbridge and ALL Out Security are partnered to provide services and solutions for JD Edwards customers. Smartbridge customers have the added value of ALL Out Security products – software and solutions that enhance the security needed by JD Edwards customers.
All Out Security is a member of the Smartbridge Partner Alliance.
Receive more posts just like this, right in your inbox!
↓ Sign up for emails with the latest from Smartbridge.
Or add this feed URL
to your favorite blog reader.