35 Cybersecurity Risks for IBM i Administrators and How to Thwart Them

The good news for the many IBM i users around the world is that the platform is highly securable, making it an excellent choice for safeguarding critical business operations and corporate information assets. The bad news is some administrators believe it’s inherently secure without any additional oversight. This isn’t the case.

It’s important to take stock of what’s happening across your environment today and invoke the proper controls to make all operations running on IBM i fully secure. The controls are there—you just need to review these common areas of risk and make the changes necessary to prevent intrusion as well as malicious employee activity.

Here’s a rundown of commonly overlooked IBM i cybersecurity risks and how to make sure they don’t open your business up to a disastrous situation.

1. Overlooking server-level malware protection

IBM i doesn’t have built-in protection against malware, but it does have the structure to support measures that can accomplish this task. Although a lot of people assume malware is destructive only on user workstations, it can also reside—and go undetected—in the integrated file system (IFS). Native virus protection in the form of endpoint antivirus software scans for this type of infection so you can address it quickly.

2. Having too many users with *ALLOBJ authority

Many organizations allow too many user profiles to have access to all database files and all objects on the IBM i system. This means there’s nothing to stop employees from accessing unauthorized files or even deleting the entire OS. Make sure to regularly review profiles and the associated activity. Implement role-based permissions, monitor which users have access, and control employees leveraging access through unexpected entry points.

3. Lacking exit programs

Unfortunately, you can’t assume your menu and application controls are enough to restrict user access to data. PC interfaces enable users to bypass these controls, damaging or even taking information. It’s important to control exit points and close any open back doors to the network including FTP, ODBC, SQL, JDBC, and Remote Command. This way data access is restricted only to those authorized to interact with it.

4. Failing to use the audit journal

IBM i provides an audit tool within the native system, but users often overlook this information and fail to keep track of what’s happening on their system. This means overlooking the impact of powerful profiles, invalid access to the system, deletion/creation of objects, and authority failures. Once you’ve enabled the audit journal capability for IBM i, implement compliance monitoring and reporting to follow these goings-on automatically.

5. Failing to get an annual risk assessment

Remember to review the state of your system security on a regular basis. Over time, subtle changes can be overlooked and new additions to the system, including third-party applications, can open vulnerabilities. Scheduling a system check on an annual basis helps you stay ahead of issues.

6. Allowing default passwords

Users often have passwords that match their profile names, such as "jdoe." However, hackers will always try using login credentials where the username and password match just to see if they can gain entry—and often they can. Solving this requires user provisioning during onboarding. Ongoing compliance monitoring will also help with running reports to see how many users have default passwords and be on the lookout for appropriate password settings.

7. Having poorly defined security policies

Even if your company has taken the important step to establish solid security policies that outline how you protect sensitive data, failure to review them periodically will hinder compliance. Implement a solution that will help you look for anything that doesn’t match what your policies stipulate. You can also use this type of tool to compare your procedures against best practices for the industry.

8. Letting users carry special authorities they don't need

Users are often given authorities "just in case" they may need them one day, not because there’s evidence these permissions are required to carry out their role. This means they have administrative rights to the system and can access information they really shouldn’t be privy to viewing or deleting. There are eight special authorities within IBM i, and employees should be given rights only when a need is clearly demonstrated.

9. Ignoring compliance mandates

Some companies may not know how to apply security properly to meet their applicable mandates. In fact, they may not implement the tools or controls properly to meet requirements. Putting off this project means risking fines or hoping auditors won’t be able to spot issues. (It’s possible that an auditor doesn’t know there’s virus protection for IBM i because they don’t understand how the platform works, giving administrators an ‘out.’) It’s critical to research the precise requirements your company needs to address. At that point you can employ the right software or other protocols to ensure you’re doing all you can to demonstrate adherence with these regulations and secure your data.

10. Relying on a single layer of security

Assuming a firewall or PC virus protection provides ample prevention against attack is risky. You need a multi-layered approach that includes exit point management, antivirus software, firewalls, and tight user profiles. Look at your security posture from multiple angles. You don’t want to overlook any of the ways users or those posing as users could gain entry to the system.

11. Leaving critical data unencrypted

Storing customer data, account numbers, social security numbers, credit card numbers, and other sensitive information on the system in the clear can result in a high-profile breach.
The solution is field-level encryption software designed specifically for IBM i.

12. Relying on menu security

Menu security within the green screen gives each user specific options based on their role. But there’s nothing in the system to control these options are the only place a user can go. Knowledgeable users can access other areas outside of the menu options with little trouble. These entry points can let a user get around the menu options initially presented. It’s important not to base security policies on the menu the user accesses the system through. Likewise, pay attention to other PC interfaces at play and implement object-level authority.

13. Using the sign-on screen unmodified

With an unmodified sign-on screen, users can change their initial program, which could give them unauthorized access to the system. The fix is to modify the IBM-supplied sign-on screen to ensure command-permitted users aren’t able to override an initial menu setting of *SIGNOFF and get into other areas of the system. This requires setting up the initial menu correctly.

14. Relying on menu *SIGNOFF

A user can change *SIGNOFF to another program, essentially gaining entry to other PC interfaces that don’t tie access to the initial program. So, if someone goes in through FTP, there’s no initial menu, and the user is launched straight into the system. Some programs don’t monitor how you got there, even if you shouldn’t be there. Rectifying this requires the ability to record user activity, such as who is accessing data and issuing remote commands, in a secure journal.

15. Forgetting to review audit data

Many IT organizations collect audit information but never go back to review it or use the findings to proactively track inappropriate activity on the system. This means issues can go undetected for weeks, months, or even years. Compliance monitoring and reporting helps you drill down into the data to identify unauthorized changes and validate baseline configuration.

16. Allowing end users to have command line permission

Companies often rely on menus to restrict users’ ability to get to a command line. But even the most unsophisticated user can generate errors, which can grant them access to a command line. With it, they can run almost 2,000 commands on the system, some of which can have devastating impacts. These could include activities such as deleting objects, ending subsystems, and exposing data. You need the ability to dictate the environment in which users can run commands—green screen vs. FTP, for example. You’ll also want to keep track of the permissions users have as discussed in previous risks.

17. Thinking the server is protected by the perimeter controls

Did you know it’s more common for insiders to gain access to unauthorized data than external hackers?  Relying on a simple firewall won’t do much good if your issue is internal. It’s important to track, monitor, and control access to system data.

18. Running on an unsupported version of IBM i

As with any software, not running on the latest version can present problems, particularly if you’re running on a version the vendor no longer supports. Having an outdated version of IBM i means you don’t have the latest updates for your security tools and lack patches which could leave you vulnerable. Furthermore, you may not have IBM support if you’re version is too far back. The fix here is simple: Stay current.

19. Not applying PTFs in a timely manner

Not having security-related patches to address known security issues is a dangerous situation. Even if you plan to upgrade to the next release where the fix will be built in, this leaves a window of time during which you aren’t covered. Always stay current with the patches needed for your version of the software.

20. Operating below security level 40

IBM recommends that your security level setting be at least 40. However, some users back-level the setting during upgrades to accommodate older programs, hoping to reinstate the security level at a later point and then never returning to it. This is a serious vulnerability because a user can potentially run a job as another user without permission. It’s important to get up to level 40. However, this isn’t a quick fix in your system; you have to prepare for the change and perform the appropriate testing to make sure no related processes will break.

21. Setting user profiles to something other than *PUBLIC (*EXCLUDE)

Altering user profiles creates a loophole around the security level 40 setting. This means any user can run a job under a profile with PUBLIC AUTHORITY *USE. This is an important situation to address.

22. Reviewing user class instead of special authorities

Users’ special authorities may not match their user class. In fact, someone may have more authority than their designated class. This could include having administrative rights to the system when they shouldn’t. Effective user provisioning and identity management are helpful in this case, as are policy management and compliance monitoring.

23. Leaving SST profiles with known passwords

The use of system service tools within IBM i can allow access that enables users to modify and patch programs as well as reformat disk units. It’s critical to change the default password as you can simply Google credentials, giving unexpected users access to this functionality.

24. Not using multi-factor authentication (MFA) with privileged accounts

It’s increasingly common to use multiple levels of authentication to make sure you know who is accessing the system, especially when dealing with accounts that have administrative rights. In fact, some regulations, such as PCI DSS, require MFA for any administrators entering the cardholder data environment. This additional layer of security in concert with other access protection controls can drastically reduce the amount of damage compromised passwords can cause.

25. Giving users power for temporary reasons rather than using programs that adopt authority

The problem with manually granting temporary authority is it’s too easy to forget to return it to normal. There’s also no auditing of activity that’s carried out while the user has an elevated status. One solution is to elevate authority in a controlled way that can be set to expire, at which point the temporary elevation is revoked. Another viable option is to implement programs that adopt authority to control how and when that authority is invoked.

26. Leaving dormant accounts usable

Dormant accounts that have access to the system are extremely vulnerable to hijacking both internally and externally. Users taking advantage of these dormant accounts will be able to navigate the system anonymously, masquerading as someone else. You think it’s Janet from Finance when in fact it’s Jake from the warehouse—or a completely unknown actor on the other side of the world. Monitoring profile activity is key, as is automatically disabling accounts that go dormant. This can be done via the operating system’s core functionality or through separate software.

27. Not having a retention and archiving policy for audit data

Data breaches are often not discovered until long after they happen, so having audit data available for forensics is critical. Some compliance regulations also require data to be kept for certain lengths of time, so you may need a mechanism to ensure these logs are maintained and available if or when they’re needed.

28. Not having a cyber attack response plan

There’s a big difference between a cyber attack response plan and a general disaster recovery plan. A cyber attack can require a drastically different reaction. You would need to determine where the attack is coming from, how to halt access, and the best way to recover damages or assess data loss. Managing a virus is one scenario, while a hacker trying to pull data off your network is another. The customer impact could also be different in a cyber attack versus another type of disaster. For example, if a hacker steals customer data there’s a different set of risks than if a server is destroyed in a fire. Make sure you have two different response plans in place to handle these situations and the appropriate remedies and communications.

29. Not encrypting data in flight (communications/backup media)

Many people don’t realize that the most common protocols, such as FTP, send data in clear text, setting the stage for data to be stolen or credentials to be compromised. Some only encrypt data at rest, when data today is often in motion, moving across networks both internally and externally. Having a secure managed file transfer process is critical as is an audit trail of all activity. Basic encryption cannot accomplish this.

30. Assuming high availability will protect from viral attack

High availability means everything is replicated in near real time, including infections! Relying on replicated data to restore files damaged by viruses is unrealistic. Native virus protection needs to be implemented on both production and HA systems to ensure viruses aren’t propagated.

31. Running unused and unnecessary services

Leaving services active when not in use increases the potential for attacks. Unused services aren’t typically monitored, so attacks can progress for longer periods before they’re detected. Unused/unnecessary services should be shut down as quickly as possible as a general best practice.

32. Not monitoring for programs that adopt powerful authorities

Adopting authorities through a program is a valuable tool for allowing functionality without giving users direct permissions. However, these programs should still be monitored to ensure that they’re being used properly and do not become compromised.

33. Not reviewing job schedule entries

Reviewing jobs that have been created on the system for the commands being run and the purpose of the job helps ensure a user doesn’t create a job schedule entry that carries out a nefarious activity. This could include copying files to an outfile for unauthorized use or performing cleanup to cover up inappropriate actions. You need to see which jobs are happening, who created them, and what they’re doing. Especially with powerful profiles, users could undertake activities with far-reaching consequences.

34. Allowing shares of the Root '/' directory

Root ‘/’ directory encompasses the entire OS, including the native database file structure. When mapping is allowed over the root, it exposes the entire system to viruses and/or unintentional damage. Access to shares should be controlled and reviewed regularly—and must never include the root.

35. Copying user profiles for new employees

Users often are granted more authority than required for their role, and copying profiles further propagates this exposure. Profiles should be created based on roles, with specific guidelines for access. They should always be monitored for changes.

Where to Go from Here?

This list may seem daunting, but it’s essential to undertake a thorough examination of where your operations stand to prevent security issues. Knowing where you stand is half the battle, and you can tackle this list in phases to work through it all, pulling in an IBM i expert like Fortra whenever needed.