E9.2 Auditing Privileged Access for SOX Compliance

[ceenankooper]

I am in the process of performing an audit of a client that is running JDE as their main ERP. The client's IT department is small, and there is an individual who has privileged access at every layer of the system. They have an account with the CNC Admin role and they also keep the password for the named "JDE" account, which is part of the administrator group on the application server and has db_owner permissions on the SQL server. Based on our audit methodology, this presents a significant SOD conflict as the user could potentially develop and promote their own changes AND has the ability to directly modify any log which would capture such activity. Ordinarily, we would ask the client to perform a monitoring control whereby a user without an SOD conflict (but with sufficient knowledge) reviews the activity and ensures that it followed the change management process. However, because the individual has direct data access at the SQL level, we determined that we would not be able to rely on the log. After many conversations with the client, we have not been able to produce any suitable log which would be outside the reach of the individual in question.

The client has responded that it is impossible to avoid such a finding in any JDE environment as SOMEONE will always have access to the "JDE" account. I have searched for answers within the Oracle support documents (as well as on this forum) and cannot seem to find what I'm looking for. The client (and their former auditor) have asserted that such elevated access is routine in JDE environments, and since the individual with the SOD conflicts does not perform development as part of her job (and does not know how to) there is no problem with this access.

I am not a JDE expert by ANY measure: I have passed my CISA exam and have several years of experience in performing both IT and financial audits. My instinct and methodology lead me to believe that there IS an issue (specifically: the individual in question could create a phony vendor and pay themselves, or make changes to the system's functionality and circumvent any attempt at logging such changes). The client's response does not give me the warm and fuzzies, but I do not have the expertise to say that they are wrong.

Am I overthinking this? Is it really normal for somebody to have carte blanche in a system because they have CNC Admin access and know the password for the JDE account? How have you dealt with auditors in similar situations?

 

[Larry_Jones]

I'm guessing your client is running an older release of JDE.
At some point Oracle implemented a better ownership scheme and default security on databases. But even before then I don't remember that the JDE account was automatically granted owner privileges at the database level. It typically had those privileges at the Application Administration level but even then we typically disabled except at times of upgrade. A bigger concern if the client is indeed running a old release is that JDE used to be installed with Public access privileges at the DB level. Unless the client implemented security on their own the kimono was wide open.

Still ... if its a really small IT department, adding these SOX layers doesn't stop the person who has to do the work ... it just makes it harder for them to do the work

There's a couple security players in the JDE Space that may be able to better address your questions. AllOut Security and ... Q? something? Can't remember. You may want to give them a call.

 

[JEMILLER]

You are not overthinking but you are dealing with something that is not really unique to JDE. Superuser access is always a problem with a small IT staff.

I have worked in well-funded SOX environments, some that also had to meet FDA validation. With enough staff it is possible to collectively lock the system layers down to specific superuser access or "break the glass" access where nobody has access until there is a need and a separate group controls access to the account "behind the glass". That was coupled with remote access surveillance for any Unix shell sessions, all database queries and remote desktop sessions for Windows machines. All access had to be initiated on the back of a support ticket and there was a separate group who managed opening up superuser access for each piece of work.

You are 100% correct on the ability for someone with backend database update authority *and* a fairly deep knowledge of JDE applications to craft master data and transactions that could be used to pay themselves, pay a friendly third-party and take a kickback. There are all sorts of scenarios from the backend that are possible and this would apply to Oracle E-Biz or SAP as well. Unless you apply database-level technologies to secure the DB from the "insider threat" those risks are always there. I am thinking things like Oracle Fine Grained Auditing, SQL Server C2 auditing, etc. In many environments simply having that level of audit and showing retention of the data was enough to pass the audit. I would argue that an audit trail that is not monitored and correlated with other system audit logs isn't actually very protective but when passing an audit as a box ticking exercise we do the minimum required.

To really protect a system I would use full database auditing techniques along with operating system auditing and correlate system and database access for "system database" accounts to try and detect when database activity that is originating from JDE servers is suspect. E.g. when a privileged operating system user launches a database session from a JDE server which which might therefore appear as just another system query but is actually an interactive session on the server. You need some SIEM tools and a lot of thought on how to process audit logs to catch the skillful insider.

To pass audits I have generally focused on the front-end security and database permissions. Most of the audit firms now seem to have some sort of "How to Audit JDE 101" guide and it focuses on the JDE account. I therefore setup additional system accounts in the application for the JDE system services to run under. I take it as far as having separate application accounts for each logical server role. So I will have a ZAPPSVR01, ZBATSVR01, ZWEBSVR01, etc. I lock the JDE account on both the application and the underlying database. It is needed occasionally for certain update and upgrade activities. Note I probably take it further than needed but I have other reasons for so much account granularity. I like to be able to see at the database activity level what each JDE component initiates.

As Larry has pointed out, database permissions were pretty wide open in older releases. It has gotten better but I suggest that you need at a minimum a dedicated DBA who acts as a gatekeeper to the database to provide some segregation between the CNC Admin and the database.

 

[franck_blettner]

I've having same problem for SOX audit for one of my customer. As Larry and Justin says, the problem is not to restrict access but leave a small IT department to do the job.
To answer quickly, I have proposed to work on proven conflicts and not theorical conflict to check if the user have really do something that he should not be allowed to do. But there is a lot of possibilities to prevent using JDE User:
- Create a new user with CNC Admin rights and modify the password for JDE User
- Check if JDE user try to log directly into the application
- Create a proxy user for database connection from JDE
- Add audit directly on database layer
And finally Larry is right, AllOut or QSoftware are applications that can help you for audit. I'm also a provider of a solution NOMASX-1 who is easy to implement without any changes into JDE and give you all the reports you need for SOX Auditing, as well to be able to identified proven conflict.

 

[Tom_Davidson]

This is a problem for all. SOX doesn't say you can't have SOD issues, just that you understand and accept the risks. In a small shop it is virtually impossible to have true SOD. My suggestion is that the client document they realize they have this issue, and are willing to accept the risk.

Sometimes mitigating a risk just doesn't make cost/benefit sense.

JMHO

 

[ceenankooper]

Thank you all so much for responding, it's very kind of you to take time out to help a stranger!

Larry: Oddly enough they have recently upgraded to 9.2. I do believe they have removed Public access privileges at the DB level. As to the SOX layers: I 100% agree, I try to conduct myself with the client knowing full well that there are many tensions between what is required for the successful operation and what is required to satisfy the auditors. It is definitely not a pleasant part of my job but I try to humbly acknowledge that when performing my inquiries. Still, I can understand why us auditors are NOT the client's favorite people! I will certainly consider reaching out to those organizations you mentioned, thank you!

JEMILLER: You've provided me very helpful insight as to protecting the system. Unfortunately, due to the lack of personnel the first scenario you described (having a "break the glass" configuration) is not practical as you've correctly pointed out. As to your next suggestion around correlating system and DB access for "system database" accounts, that is actually along the lines of the solution that we proposed to the client. We suggested that if they had a gatekeeper (potentially the DBA) who maintained the password for the JDE account, and kept session logs of the JDE account, we could correlate the two and match them up with an associated ticket. The client disagreed that would reduce their risk in a meaningful way and would restrict the ability to perform the SOD user's job. The main problem is that the client's main defense if that the user in question doesn't know how to perform JDE development or directly affect the data using SQL. As an auditor, it is very difficult for us to gain assurance around a negative assertion such as that.

Also, your comments about the JDE account are very helpful and consistent with what Larry said. Unfortunately, the client claims that 99% of JDE environments keep the account open and that it must have all of the privileges they have granted it (including DBO) in order to run its system services. It sounds like that may not be strictly true, even if the level of granularity you've described may not be practical in their environment. (Side note: unfortunately we do not have a JDE 101 training, which could've helped answer this from the start, but that's a separate issue).

Franck: Thank you for your suggestions, it seems that your experience also supports the fact that it is possible to avoid using the JDE account. In this situation, the user in question does in fact have a separate CNC Admin account, but because they also maintain the password for the JDE account, it is difficult for us to gain the necessary comfort. I will definitely incorporate what you've shared in my deliberation, thank you!

Tom: Thank you for your response also. To your point, you're absolutely correct that we do not need to completely eliminate SOD issues and the client is free to accept the risks. In this situation however, the financial statement audit folks must determine the potential impact to the audit. In this case, if we wind up with a significant failure in ITGCs, it would require A) disclosure of such in the financial statements and B) increased sampling requirements on the part of the financial statement audit team. Obviously, this tends to inspire the FS audit team to accept the situation and continue to rely on ITGCs. I have not had experience defending a position such as this to the PCAOB, and have heard mixed messages from people who have. On the one hand, we have beat this issue to death and tried to consider all of the associated risks; some people believe that robust documentation around this would give us a strong defense against any potential comments by the PCAOB. On the other hand, we've noticed the PCAOB seems to be focus on ITGCs and should they ask the right questions, a response of "Well, this person doesn't really know how to do that" doesn't seem sufficient (in my humble opinion).

Please forgive any foolish mistakes I've made here as I am a lowly auditor and not an expert in JDE.

 

[Luke Phillips]

In a small company you're unlikely to have more than one or two people who need complete machine access. It's clearly a SoD risk and your customer needs to have an additional person who can apply oversight.

Even if it is challenging due to company size and practicality, effective reporting, including of database level changes is a way to retain control.

Lastly with an ERP like JDE there is always a separation between the database layer security and the within-application security. In this way even small companies have to have some type of segregation of competence.

We help with JDE Security Management, Change Control and Database level reporting.