Everybody thinks it won’t happen to them….
But if somebody at your company commits fraud on your JD Edwards system, would the fingers point to you?
Few people would disagree that you need to have a robust security design for your ERP system to protect your organization from internal fraud. But in JD Edwards, that’s much easier said than done.
Understanding JD Edwards security can be overwhelming due to its layers of complexity and the various components involved in compliance.
Before I joined Q Software as Senior Delivery Manager, I led a security team for a large corporation for several years, responsible for managing all aspects of JD Edwards security. We quickly discovered that security is more than just those 20+ security types and knowing how to add them in the security workbench application; it’s also about people, processes, technology and security strategy.
There are three key items that must be considered when creating an effective security strategy:
- The definition of security
These days, security means many things to different people: applications, servers, networks. It is imperative that security for this purpose means the access to and within JD Edwards.
- The scope of your security strategy
Many people only consider front-end application access and neglect to see the bigger picture where middleware, reporting tools and databases should also be included. Covering all access routes to JD Edwards allows you to build a security model that works cohesively across all areas and improves the accuracy of your overall audit reporting.
- The people that should be involved in helping you build the security strategy
A security strategy should not be built in a silo. Input from management, business, internal audit and various people within the IT department is essential.
Key practices for an effective security strategy
Effective security requires an holistic approach, therefore it is important to implement good security practices to protect your business (and your job!)
Example: aligning Application Security and Database Access Management
The details of setup or configuration may be different for application security versus database security, but the concepts should be aligned.
For example, a developer who is provisioned with front end access to the development environment and restricted from security tables may also have access to update the database for unit testing.
The database access would then also be restricted to the development database and a role provisioned to the developer on that database would contain no update privileges to security tables.
How the security is setup within the application and on the database are very different, but it is important that the concept of a developer being restricted to a specific environment with no access to security aligns on both.
Don’t be caught out! Our White Paper The Top 10 Security Practices You Should Know Before They Cost You Your Job gives more information on key practices that make up an effective security strategy, including user life-cycle, authentication, security models and Segregation of Duties.
And if you need tools to make it easier, you can also find out more about our security management tools for JD Edwards EnterpriseOne.