I am wondering how other Public Companies are maintaining compliance considering the severe weakness in Epicor’s system? Has anyone actually turned on change logs on every financially relevant table to ensure that Security Managers are not performing inappropriate transactions? Did you come up with some slick way to not burden the business with reviewing every transaction to ensure segregation of duties?
A little background for people who have never worked in a SOX environment. Sarbanes-Oxley was a US Government law that was passed in the wake of the Enron scandal - Wikipedia. What SOX cares about is risk and making sure that the company has sufficient controls in place that show there is proper segregation of duties. The best way to say that you have controls in place is by using your systems to have roles that do not allow for incompatible access. Think of the procure to pay process, if I can create a supplier, cut a PO, receive the PO, and pay the invoice; I could be making bank.
Now the issue with Epicor is that the Security Manager OVERRIDES all security. So, as long as there is one person who is a Security Manager, you are not SOX compliant. I know what some people will say, but that person requires that access to do their job. That does not matter, even if the employee pinky swears, signs in blood, allows their first born to be held captive, etc.; the risk still exists. Now, you can mitigate that risk by putting manual controls in place that are detective (not preventive). To say that your company is compliant, someone would need to review all transactions on a regular basis (probably monthly in this instance, but at least quarterly) to ensure they were not performed by someone who should not have done them. Now imagine how many transactions you would need to review to ensure that a Security Manager has not done a transaction that they should not have. Think about how many change logs you would have to turn on and the size of your database after one year. This is completely untenable for any company. You would need to hire at the least one full time employee to do this.
So, I am wondering how other Public Companies are handling this. I would like to avoid having to disclose a weakness on our financials without having to manually track everything.
We never had anyone as Security Manager in Production, no one besides real people could login into production. If you ever wanted to, you put in a Service Now ticket requesting access for a period of time.
You have a Service Account, for example the user manager remains and is strictly used to your Service Now hooks to enable, disable Administrative users. You will always have Service Accounts, with impersonation rights among other things. Make a REST API button
So it’s more about making it harder to access a Security Manager account, not necessarily not having one. In the end a password still has to be stored somewhere, and decrypted with some key that will also have to be stored somewhere.
We never even made anyone a Security Manager in Production, only the IT Staff that has instructions to deploy Customizations as per Instructions.
We always passed the bdo audits, as long as its not the Developer, the person can’t code and deploy.
Its just about Segregation of Duties. The person who is IT Admin should not be doing Orders etc…
You will need access to Service Account to schedule MRP, Update System Agent stuff, you will have IT Helpdesk who needs Clear Personalization, Reset Password, Create Sales Person, Review Multi Company Logs, Company Maintenance, Company Config, and the rest pretty much read only is fine.
I have a BDO worksheet somewhere, we had to fill out with all the Menu IDs we are granting exceptions to.
Ultimately if you have Audit Trails, you can pass too… its either blocked, allowed with exceptions backed by Audit Trails (Helpdesk ticket asking for the key for 3 hours to perform X duties).
Exactly. In the DevOps world, what Haso is talking about is called Configuration As Code.
In this practice, there is a repository that holds a configuration for your system. For example, let’s keep track of System Managers. There would be a file in GitHub (for example) that holds the users names of who is a System Manager. To gain that capability, someone submits a pull request adding the user to the list. Another person would have to accept that request. All of this is logged and versioned. Once approved, a GitHub action is kicked off that lists the current users with System Manager capabilities and adds the missing users as well as removes those not on the list while also logging any removal since it might represent a breach. The GitHub Action gets the password from a KeyVault and it is the only one who has access to that entry. Periodically, a GitHub action can rotate that password and update the Key Vault. Any activity against that Key Vault is also logged but also protected by Conditional Access policies.
Contrast this with what others call “Click Ops” or manual entry. Click Ops is difficult to reproduce if the user who has the information in their head is not available or does not remember how they performed the task previously.
And as Haso mentioned, this can be done with a request to a service account that has limited scope to perform the only thing it is allowed to do. Granting just enough privilege for the least amount of time is a good Zero Trust practice.
I would say the key here is not letting the auditors know that Security Manager has God level access. Once they know, they will ask for proof that anyone with Security Manager access (approved or not) did not perform an inappropriate transaction.
I’m not advocating for this, if I am responsible for the ITGCs, I want to know I am covered. And that is my complaint about Epicor, there is no easy way to get comfortable without a lot of customization and manual lookbacks. I would think that 20+ years after SOX was implemented, Epicor would have provided better tools to help their customers out.
How does one explain Domain Admin or Global Admin to auditors? Every system has this problem. The “work around” is practicing Zero Trust principles, which means strong identity, least-privilege access, and assume breach.
Domain Admin (if I am correct, you know I don’t understand much outside of Epicor) does not have access to transact in the system of record. They only have the ability to create accounts on the domain and potentially give inappropriate access to the system of record. I would think that is easily controlled, but have no idea. When talking about a system where the business transactions take place, there should be no God level access.
