You may wonder what JD Edwards security functions can I leverage from my ALLOut Security (AOS) package that would pay dividends without needing a great deal of time and training?
First let’s listen to some of the questions the business faces on a regular basis and the ‘work arounds’ developed by long forgotten names are still nagging. Maybe we should look at these with a fresh set of eyes:
Q: I manage a SOX audited system; how can I determine if a new user account will create a Segregation of Duties (SOD) conflict when copied from an existing user?
Q: I have a request to add additional roles to a user. How can I test to determine if the new combination will create a SOD conflict without actually granting access to the user?
Q: There is a requirement to combine the job functions of two users into a new position. How do I determine if or what SOD conflicts will arise from this realignment?
Q: The auditing team has reported that we need to clean up SOD conflicts in order to avoid failures in our review. How can I determine what roles are causing the findings?
You’ve probably heard these in some variation, and some have been given up on while others are performed after picking the person with the most spare time to weed thru a cumbersome procedure.
Are you using SOX lists like this to review the programs and conflicts? In addition, you have to deal with the manual sequencing of the roles to get the correct authorizations. It works but how efficiently?
You can import this information into AOS then run reports against these definitions
The values can be entered manually or using the AOS provided import tool.
Once you have the definitions installed, you access the SOD reporting tool and enter the desired information.
Segregation of Duties Rules – SOD reports against the list of definitions you just created
Filter Results by Level of Access – This looks at Action security to see what level of change can be made
User/Rule Range – These work singly or jointly. You can specify A thru Z or a set in between
The output would look something like what is below. The cover sheet of the report confirms the input values of how the report was run. Additionally, the page, date and time stamps are included in the right corner. This is very desirable for submission to the auditors because it is repeatable and once the selection criteria are defined and accepted, a standard document for all to use.
Going back to the back to the questions at the beginning
Q: How to determine if a new user will create a conflict?
A: Run Segregation of Duties report against the existing user to confirm the base account (copy from) does not have conflict(s) which might require additional approvals.
Q: I have a request to add additional roles to a user. How can I test to determine if the new combination will create a SOD conflict without granting access to the user?
A: Create a test account with additional role(s), preferably in a lower environment with a designated name ‘TESTUSER1138’ then run the SOD report to confirm the outcome. Then delete test user.
Q: There is a requirement to combine the job functions of two users into a new position. How do I determine if or what SOD conflicts will arise from this realignment?
A: Update an existing test user with AOS ‘Copy and append to existing user’ function from the User creation tool. Then you can run the conflict report to determine if the requested access is acceptable.
Q: The auditing team has reported that we need to clean up SOD conflicts in order to avoid failures in our review. How can I determine what roles are causing the findings?
A: Run the SOD report and specify the user or the SOD conflict in question. The report will provide which roles are introducing the conflicts, then the offending access can be expired. Run new reports confirming the remediation has been completed.
Opportunities:
In addition to reporting on SOD conflicts because of program access, you can also run reports against access to CO and MCU. When companies are added, changed or deleted and Row Security may/may not have been updated. Reports can catch these changes.
The audit review conducted annually where the managers must approve user access is appropriate. The report is run, and users are already assigned group membership by Cat Code. This makes distribution to the correct managers easier.
If your organization protects information considered Master Data such as updating Address Book information, Bank account or Banking information, Customer/Vendor Master information, as well as anything else that can be identified in Security Workbench. Using the same set up as SOD rules all these programs can be reported on.
Another area of concern would be access to Critical Access programs. In addition to normal business functions such as Opening/closing periods in Finance you can also report on technical programs. Some areas of interest could include who has access to OMW, Security programs and other System Administrator type authorities. Using the same set up as SOD rules all these programs can be reported on.
Try holding a brain storming session with business users to see what needs they have. You will probably find you have the knowledge, tools and some imagination to get the job done.
To find about GSI’s JD Edwards Security Practice or any of its products or services including JDE project consulting services, managed services, upgrade services, cloud services, and more, call us at 855-GSI-4ERP or click on CONTACT US to send us a request for more information.
Meet the Author
David Fernandez