The Three Layers of Security for JD Edwards Running on IBM i

The performance, reliability, and security of any software, from the simplest mobile application to complex enterprise platforms like JD Edwards, depends on the environment in which they operate. A full understanding of the software’s technical ecosystem is essential for maximizing uptime, optimizing performance, and protecting critical business data.

In the case of JD Edwards running on IBM i, this means expanding the administrator’s perspective to include not just JDE application security, but also the complexities of securing the IBM i operating system, and the policies & procedures that govern that.

LAYER 1: JD Edwards Application Security

In today’s environment, potential security threats can come in a multitude of ways – from people, places, and things -- which requires a periodic re-evaluation of your application security strategy.

How long has it been since your security strategy was designed & implemented? Has your business grown, or have your processes changed since your last holistic evaluation?

Most application analysts are acutely aware that good security control is much more complex than maintaining the on/off switches! Beyond the common best practices, additional risks are presented by:

• Key user account types
• Relying on “security by obscurity”
• Not considering the up- and down-stream system accesses

Each of the above risks may allow unintended circumvention of your application controls, so it is also essential to explore potential mitigations such as:

• Additional system considerations: available settings that are often overlooked or underutilized, but which can be used to strengthen security posture, depending on your specific gaps/audit findings.
• External business processes: the part of the business process handled outside of the system, which when properly documented and able to be tested to prove it is being followed, will support and strengthen your mitigation efforts.
• Defense in depth: layering application, data & OS security creates a more secure environment than any one layer alone.

Security threats continue to creatively evolve. Your application security strategy should as well! Take the time to dig into the people, places, and things in your environment to assess and fortify your application security strategy.

LAYER 2: Data Protection

JDE business logic and user security is contained within the JD Edwards application. The application then connects to a database. We need to think about what happens if/when users connect to the database without using the JD Edwards application. Users who connect this way aren’t subject to JD Edwards security or audit controls.

JD Edwards database and service accounts are IBM i user profiles that can also be used for FTP, TELNET, ODBC, file browsing and more. If someone knows the password then these profiles can be used as if they are regular users on the server. It is essential to put limits around what these profiles can do.

Four strategies to protect JD Edwards data on IBM i:

1. Use IBM i data protection technologies: Namely, exit points and multi-factor authentication. An exit point is an IBM i security feature that examines a database request and accepts or denies it based on a defined set of rules. You might to allow access from the JD Edwards application while forcing a multi-factor authorization if the user profile tries to connect from outside JDE.
2. Monitor for real-time security events: Would you like to be notified if a super user or service account logs into a server session? What about a password change on a DB Admin profile, or a failed login attempt?
3. Use IBM i journaling as an audit backstop: JD Edwards includes powerful audit features for tracking changes to critical data, but changes made from outside the application cannot be logged. IBM i includes a built-in “journaling” technology to provide this capability. When journaling is enabled, database changes can still be audited, even if they happen outside of JD Edwards.
4. Harden the IBM i security configuration: The IBM i operating system is highly securable, making it an ideal platform on which to run JD Edwards. There are many settings and features that should be reviewed and configured to maximize security. It’s important to review this regularly because IBM updates security with every upgrade.

Now with the first two layers taken care of, let’s now consider Layer 3.

LAYER 3: System Availability

We also need to think about the system itself on which the database resides because we want to do everything possible to keep JD Edwards running reliably in all situations.

Four strategies for JD Edwards availability on IBM i:

1. Monitor everything: Use performance monitors like processor load, disk space, thread waits and others to alert for possible trouble before it happens. Monitor message queues for important system alerts for the JD Edwards database or related applications.
2. Keep the system up to date: IBM releases two major operating system updates every year. Other updates, called “PTFs,” are released intermittently between major updates. The operating system itself gets a major release every 3 years or so. Each release and PTF improves the platform’s security. IBM reported 31 IBM i security vulnerabilities to the NIST National Vulnerabilities Database in 2023 alone. Every single one was corrected by a PTF or upgrade. Staying current is fundamental to running a secure environment.
3. Backup JD Edwards data: Backups are another fundamental component of securing your system and guaranteeing its availability. There are many variables to think about in terms of how quickly you need to recover from a data loss and how many transactions your business can afford to lose. Regardless, off-site data storage should be included in your back-up plan. A full copy of your JD Edwards data should always be available at a separate location.
4. Implement a disaster recovery plan: This plan should include a failover system in a separate data center. It should hold replicated data from your primary system, and it should be ready to be brought online immediately should an outage or hardware failure result in your primary system being unavailable.

There’s plenty to think about! Keep in mind, the average time it takes to detect a data breach is not measured in days, but in weeks and months. Once detected, containment can take almost as long as initial detection -- all the while leaving your data at risk. These breaches can create losses in productivity, competitive advantage, costs associated with the response effort, specific financial losses such as fines and judgements, and have the potential to significantly damage brand reputation and future revenue.

Please feel free to reach out, we are here to help and advise with your JD Edwards on IBM i security considerations.

Contact us to schedule a comprehensive security assessment...

Melissa W. | NuVerge, LLC | JD Edwards Application Security Specialist | [email protected] | www.nuverge.com/securityaudit

Justin Loeber | Kisco Systems | Head of Business Development | [email protected] | www.kisco.com

Kisco Systems is your trusted partner for IBM i security software and services, offering solutions for system monitoring, data protection, and audit. Together with our partners, we provide top-to-bottom security solutions for IBM i.