The Importance of Penetration Testing on IBM i

Many businesses host core applications on IBM i, but the operating system is often overlooked when it comes to penetration testing. Fortra’s Amy Williams explains its importance on IBM i—and how to do it well.

By Amy Williams

Many organizations have requirements for performing penetration testing (pen testing) annually or even more frequently. We hear that many of these efforts do not include the IBM i , often because the IBM i is thought to be an unknown, unlike more common OSes like Linux or Windows, for example.


Another common reason for excluding IBM i from pen testing: “Our vendor doesn’t know the IBM i. Does it really need to be included?” The reality is that IBM i is not as unknown as it was before. There are limited resources for qualified IBM i pen testers—but don’t ignore your IBM i because you're hanging on the hope that “cybercriminals don’t know about it” or “it’s behind the firewall.” Not taking action to protect your IBM i means it’s a matter of when, not if, your system is affected. So, when should your IBM i be included in your enterprise pen testing scope? When it contains any confidential or proprietary data or runs critical business processes, which is often the case as the platform frequently hosts core business applications that are critical for financial reporting as well as daily operations.

What Is Pen Testing?

Pen testing is an authorized activity to test the vulnerabilities of a system. In most cases, there are five stages to pen testing:

Reconnaissance (gathering information)
Evaluation
Assessment
Exploitation
Reporting

Each of these phases can take a different amount of effort and length of time—for instance, some tasks can be automated. It’s highly recommended that the testing or exploitation phase be a combination of automated and manual testing. Relying too heavily on automation can result in missing misconfigurations that would typically be identified by human testers.

 

Valuing all the data you have and knowing which data is most valuable to your business continuity will help set the scope of any pen test.

Types of Pen Testing

There are three types of pen tests: black box, gray box and white box. All consist of the same high-level steps to achieve their goal; the only variance is in how the goal is achieved.

Black box

This testing is done without any prior knowledge of the target being tested. Black box testing requires a detailed reconnaissance mission to identify the attack path to be used. This type will most often take the longest amount of time to complete.

White box

This is the opposite of black box testing. A broad amount of knowledge about the already identified target is provided, including credentials, system information, network configuration and functionality expectations, along with any other relevant information for the scope of testing. This allows the pen tester to identify an attack path and methodology to gain control of the system without a long reconnaissance phase.

Gray box

With gray box testing, less information is provided than in a white box engagement, requiring the pen tester to do some reconnaissance.
The reconnaissance phase for all three types of testing involves scanning the target systems and network to gather as much information as possible. Depending on the engagement, reconnaissance can also include phishing and social engineering methods.

Why Should You Perform a Pen Test on Your IBM i?

Today, threats against our data are coming at our organizations at nothing less than an alarming rate, whether they stem from outside firewalls or from unintentional misconfigurations. Having confidence in your controls and configurations is a good place to start; proving that they are working as hard for you as you think they are is priceless. Pen testing done against your IBM i should provide you with these answers—both good and bad.

“Having confidence in your controls and configurations is a good place to start; proving that they are working as hard for you as you think they are is priceless.”

—Amy Williams

As an administrator I would often find myself wondering if the steps I had taken to secure my system were enough. Unfortunately, the answer was always no. Securing any system requires constant monitoring for malicious activity and continually updating configurations to reduce the threat landscape as much as possible. With each new version of the OS or update to the applications running on your system, a new vulnerability could be introduced. The saying goes, "Security is a journey, not the destination.” Pen testing can help us understand just how far we need to go, or how close we actually are.


I have been performing pen tests formally against IBM i systems for seven years. Before that, testing the security configurations on my systems to ensure I was getting the desired results was much less formal. In other words, I was making sure users were constantly failing to gain access to restricted files, commands or programs without a consistent set of tests. Many systems that I have been invited to test were thought to be secure. Then I would peel back the first layer of confidence using a common misconfiguration to grant elevated privileges so I could create a new administrative account. Fundamentally, there is little difference in pen testing of an IBM i versus other targets. The “i” stands for integrated, so testing the OS for misconfigurations is the first place to start.

SPONSORED CONTENT

What’s the State of IBM i Security in 2023?

The latest data is in—get real-world insight into IBM i security with Fortra’s 2023 State of IBM i Security Study. You’ll learn what tools and strategies organizations are using to secure IBM i and where systems are often left vulnerable. 

 

This annual study is a go-to resource for understanding IBM i security risks and the steps you can take to harden system security.

Tap to reveal more…

Automated Testing Versus Human Testers

A combination of automation and manual testing provides the best results because automated testing is sometimes unable to detect certain vulnerabilities. Using automation for phases in the engagement—for example, the reconnaissance or the scanning phases—can root out opportunities for exploitation. A manual tester can make additional choices during the exploitation phase that possibly were not thought of before. Each IBM i environment is unique, whether it’s the operational purpose, the age of the software, the level of customization and the level of the OS, just to name a few. All these factors can create a new decision tree for the exploitation phase.

 

When evaluating if automated testing will provide the same confidence level in your secure configuration alone as opposed to including a human tester, understanding the scope and goal of the automated testing is crucial.

 

Many factors determine how the testing will be performed and what types of exploits need to be tested. These include how the system is used, when the system is used, whether it has interactive or only batch processing and what the patching schedule is. Testing should not only consist of exploits that are known to provide elevated access; it should also include testing of less obvious opportunities.

 

As I mentioned, not all incidents are intentional—some are mistakes. This kind of evaluation and exploit testing can be best accomplished by a human tester that works through day-to-day processes and looks for any configurations that could potentially put the data or system at risk.

Choosing a Pen Testing Strategy

Testing any system requires an expansive knowledge of how misconfigurations can happen, where they can be found, and most importantly, how they can be exploited. Not all pen testing goals are to take over a system by creating an administrative account. Instead, sometimes the goal is to ensure the most sensitive data cannot be altered or removed from the system. When building an attack plan, understanding how configurations can work together to secure an environment, or give a false impression of secure data, is very important.

 

Any obvious ways to exploit a system should be tested and documented, and the testing should not stop there.

 

A pen test plan needs to include steps beyond the low-hanging fruit and attempt to exploit the next level. Assumptions of failure must be taken into consideration, including questions such as:​

Is there 5250 access?

Is SSH is being used?

Are connections encrypted?

Is the OS level current with its patches?

Is a common software installed?

These questions are just a starting point for performing a more comprehensive environment test that includes both system misconfigurations and common configurations in the industry.

 

In the end, testing IBM i is like testing other endpoints in your infrastructure. The same attention to detail and planning must take place. The difference is the lack of experience in the pen testing community on the platform. This is changing daily. The IBM i is getting more attention as threat actors are becoming aware of how valuable IBM i data can be. After all, we know that many call this OS the system of record for a reason. Are you confident your records are safe?

Amy Williams
Fortra
Amy Williams is a senior security services consultant who joined Fortra in 2015. She holds CISSP, CISA and PCI-P certifications. Amy first began working on the IBM i platform in 1994 and her experience includes application testing, system installation, system administration and architecture.
Share this article