JD Edwards Upgrade: Security Risks to Fix Before Go-Live

Upgrading JD Edwards doesn’t automatically resolve the security risks already in your system. In this episode, Brian Connor joins Nate to discuss where security gaps hide, which issues to address before an upgrade, and what can wait. Learn how outdated permissions, integration accounts, and overlooked controls can create risk, plus practical steps for testing security and preparing for a successful go-live.

Are you preparing for a JD Edwards upgrade without knowing what security risk might be hiding in your environment? And how do you know which security issues need to be fixed before upgrading, and which ones can wait?

Today, we're breaking down where JD security gaps tend to hide, how to prioritize the fixes, and what to check for go live. By the end, you'll have a practical approach to strengthening security without turning your upgrade into a much bigger project.

Welcome back to Not Your Grandpa's JD Edwards podcast, where we help JD Edwards customers make smarter decisions about their ERP environments.

When companies prepare for an upgrade, they usually think about performance, new features, downtime, and making sure everything works when they go live. But what about security? Over time, permissions changed, integrations get added, and security configurations can become harder to manage. And just because you're upgrading your JD Edwards system doesn't mean those issues automatically disappear.

So today, we're answering an important question. What should you actually fix before upgrading? And where should you start?

Joining me is Brian Connor from ERP Suites to walk us through what JD Edwards should be thinking about. Brian, how are you doing today? And for those out there that haven't seen you on the pod before, could you maybe give us a little background about your JD Edwards history?

Absolutely. Thanks for having me on again, Nate. Happy Wednesday.

So I've been in the JDE space since 1995 quite a while, been focused on security and compliance risk management for JDE customers since about 2009. So a lot of, a lot of time doing this for a lot of different customers.

Yeah, As for sure. I mean, 2009 is an interesting year to start in JD Edwards. But you've definitely seen a thing or two throughout these years. It's it's been a wild ride. And I don't think you ever really thought about having to do security for AI during this. So it's a little different these days.

I mean, I've heard of those 2 letters.

Yeah, fair enough. Well, then again, I think Terminator came out around 2009, so maybe you had heard of it at that point. So you never really know.

Hidden Security Risks: Outdated Users, Roles, and Excessive Access

So let's start here. What are the biggest security weaknesses JD Edwards customers should look for before starting an upgrade?

I think a few areas to look at. So old information that's in the system, so old decremented use, users that have left the company, roles that are no longer in use, things that were created that nobody understands why they were created because that's just a lot of stuff that you don't need to take forward to the new system, to the new platform, wherever you're going.

So looking at that plus it, it's a risk because you don't know what they actually have access to or if somebody's using it. Looking at your underlying infrastructure, looking at things such as improvements in some of the security technologies going from SSL to the TLS and the constant updates that Oracle's making there. And then also some of your connected system. So things that are reaching into JD Edwards or that JD Edwards is reaching out to?

Yeah. And that's, that's interesting. I was just talking to one of our good friends, Drew Rob, about this of yeah, you can have security inside of your JDE system, but when it comes to communications outside of it, that's where security can get a little tricky, especially for something like an upgrade. So how can user roles and permissions create security risk that companies may not even realize they have?

Absolutely, a couple of different ways. We'll go with the the end user focused one first. So accumulated access. If somebody's been at the company for a while, they have helped out in various areas where they've got a promotion or move departments. And so they've accumulated access from, you know, purchasing to accounting to various other areas within the company. Roles get added, but very rarely do any roles get taken away from the user. So the accumulated access is definitely a big one.

The other part is kind of what you were referencing with Drew, which is some of these integration points. When these are being built, typically you use an account that has all access just to make sure that your orchestrations, your APIs, everything is going smoothly. Very rarely do those accounts get right-sized to make sure that they're only accessing the parts of JD Edwards that are relevant to the job being done. And you end up with access in production with, you know, no restrictions.

Yeah. Which is always so funny to me because security is one of those things that, yeah, you usually don't think about until you need to. But it's also one of the most important things for a JD Edwards system, especially when dealing with sensitive data. Yet it gets overlooked so much. I mean, we talk about this all the time, the amount of times that security gets overlooked until maybe the last week of an upgrade, isn't it? So it's more about being proactive on all this stuff, which is, again, it baffles my mind.

And it's been that way for 30 years. So this is nothing new. Customers always come in and say, you know, we're probably, you know, the worst you've ever seen. And and typically not, they've just done it the way all customers done it, which is make sure the system works and does what you needed to do for the business, which is absolutely critical. And like you mentioned, security comes in at the last minute and somebody says, hey, did we create some roles around these people? And so everybody's scrambling and, and you don't get the complete picture at that point.

All right, I have to ask the question, what is the worst you've seen?

I think the worst that I've seen is a company, I don't recall what it sometime within the last probably seven years, their security table consisted I think of a grand total of 60 records for a 300 person company. So that was a little bit shocking.

So if if for the listeners who aren't familiar, JDE security is open by default. So until you lock it down, users can access whatever they want. So having a security table with only roughly 60 records in it is not good. So I, I honestly, I was a bit shocked with that one. Hopefully you're not listening.

I can't imagine. I can't imagine.

Yes.

All right, let's get back on top of here. Sorry for that tangent, but I needed to know what should companies examine beyond JD Edwards application level security.

JDE, Oracle have provided some really good tools that sit inside of JD Edwards. They relate to security, but they don't sit in the security table. So things like your batch approvals, making sure that if I enter a batch I can't approve it, somebody else has to approve that batch before it can get posted. That's been there for a long time. Unfortunately, it's not used as much as it should be.

Address book data privacy to restrict access to employees and vendors, personal information, so home address, phone numbers, dependents, all of that sort of thing. A little bit more recent bank account masking to hide the account numbers so that people can't take the routing number and the account number and try to use that for fraudulent means. So those are those are a few of them that I think are are pretty important.

Yeah. And it's a great way to at least start. You know, there are still more in there, but I think those are maybe the most important to at least start with.

I think so. And you know, just back to the bank account masking that kind of happened without a lot of companies understanding it. It it came out through through an ESU and was turned on by default globally. So a lot of companies went and just effectively did an undo on it and allowed everybody full access to all the bank accounts and have never revisited it.

Because in a pinch you have people that need to see that information. And without knowing exactly what needed to be done, they they did their own patch to it, which opened it all back up. And a lot of them haven't gone back to readdress that.

Yeah. And maybe talk about things that need to be readdressed. How can integrations and automated processes create additional security concerns?

They're bringing data in from outside. And if a user, you know, perhaps has access to the system that originates the data and is then brought in automatically via an API or through an orchestration, they're controlling the data that's being pushed into the system and then they process that within the system.

So from a fraud perspective, and I hate to be so cynical, but that's kind of my job. If you can manipulate the invoices in a third party system before they come in and then pay those invoices, even though JD Edwards doesn't see it as a conflict because they're integrated versus you manually entering them, it's still leaving you open to the potential for fraud. Thankfully, most employees aren't doing that. But it only does only take one.

Yeah, like you said, most. There are some of those out there.

All right. I know for this next question you're going to say everything, but let's play the game. Once security issues are identified, how should JD Edwards customers decide what needs to be fixed before an upgrade and what could maybe wait other than everything as you mentioned?

I think those things that impact business operations. So if you have multiple operating companies and you have a lot of issues around your row or column security, then I would recommend you take a look at that and get that cleaned up and working properly because that's going to provide a significant gain in business operations. Depending on how you have your row security set up currently could provide a boost in performance going from exclusive to inclusive.

So I think anything that is going to have an impact on how you are able to do business and then protecting the business is the next one. So if you don't have some of those built in tools being utilized, look at implementing those as part of a as as part of the process.

And then last I, I know a lot of people consider it just housekeeping and it can wait to phase two, which rarely happens to be honest, is cleaning up a lot of the items that have just been gathering dust in your system. So, you know, when a hoarder moves from a two-bedroom house to a five-bedroom house, you don't bring all the stuff with you. So start clean.

Yeah, you should talk to my mother about that. She's a little bit of a hoarder herself, but yeah, I like that. Like the housekeeping. You're right. When it comes to phase two, they're looking into so many different things that they're typically not like, Oh yeah, we should do some housekeeping. Right now. They're I, they're focused on other things.

But it is such an important part because if it's broken before you actually upgrade, then it's going to be broken after you upgrade. So you're literally just pushing, you're kicking the can down the road. You're going to have to look at this eventually. And if you do it before an upgrade, you're going to mitigate those risks before you take this next step in evolution.

Exactly.

So what types of security issues should companies treat as non negotiable before moving forward?

Admin level access. So users that were part of the project team from the last upgrade or from the original implementation that still carry that level of access forward just in case. I think that needs to be remediated right away.

A big part of that, and I know I won't make friends with CNCs here, but CNCs don't need full access in production. There are things that they need to be able to do, access to all of their tools 100%, but a CNC does not need to be able to enter a purchase order or sales order or anything of that nature.

They may need if they're helping to troubleshoot something, inquiry access to be able to get in and look at things. Or preferably since you're working with live data, if there's an issue, you should be testing and troubleshooting that in a lower environment so that you don't accidentally impact your bottom line with that with doing things in production.

So as as a recovering CNC myself, I know I did not like to have full access in production in the event that there is any issues and it not necessarily fraud. Let's say somebody accidentally runs the sales update report wide open. I don't want to be a part of that conversation because I have the ability to do it. So I as as a technical person, even doing security, I don't like being in production. And I push to make sure that my access is limited to only what I need to see.

Yeah. And I know we're not trying to make any friends here when it comes to CNCs, but we do have a lot of great CNCs on our team.

Oh yeah, some of the best, if not the best in the business.

But I would argue that they're OK with only having that specific access for what they need. They don't need full access.

User Acceptance Testing and Security Validation Before Go-Live