Security Testing and the Approaches for Malicious Code Insertion

Yvonne Enselman

The need for proper security on IBM i systems is increasingly well understood. Equally important is proving out the hardening is sufficient via comprehensive testing. As is true for all IT infrastructure, no single type of testing will ensure your system is stable, so we need to incorporate security QA in multiple ways.

What is security testing?

It is a component of Reliability Testing which is how the system is configured for its intended use. This is an area that thinks about what the environment needs to do, how it needs to be done, and what variables are known as requirements. Testing types will include:

  • Black Box is input and output based on the system responding to specific criteria without visibility to what is happening via the process.
  • White Box is the opposite, one has access to the programming and/or database procedures and sees how the system is responding at a level invisible to the users.

Both Experience-based and Exploratory designs are important. Experience-based test design uses the knowledge of the business and the IT environment to determine where the risk lies and ensures it is mitigated. Exploratory also depends on end-users and their intuition. However, it is a process where transactions with seemingly invalid data or paths are attempted to ensure the system doesn’t allow erroneous entries. Lastly, it is important to note that while security testing is usually thought of at the system level, indications of risk are throughout the software development lifecycle and need to be addressed at unit, integration, and regression levels.

Security vulnerabilities fall into general categories and there are ways to approach testing in each of these areas in this and future articles.

Buffer Overflow and Malicious Code Insertion are known security risks. Patches and updates address this area more often than any other, as the ways systems are hacked evolves constantly. Testing in this area is frequently done via dynamic stress testing. As homegrown code interacts with COTS (Commercial off the shelf), there are numerous places data can be slipped in. Standard ways to addresses this are remaining up to date on all fixes. Your software (and this means all software, not just the main ERP), needs to be kept on active maintenance.

Even something like a basic utility tool can be a risk in an integrated system. Of course, PTFs need to be applied on a regular basis. Even if your OS is out of support, IBM is still releasing Hipers you need to apply for security. HMCs and FSPs can’t be neglected, nor should any storage or backup devices, and your replication software needs attention. Known attack vectors are the stake frame allocation, return addresses, threads of execution, and pointers.

One last comment on 3rd party software, as I said above: Don’t neglect maintenance. So many companies drop maintenance for minor applications however anything, especially older code, can be hacked. While you may not be concerned about the reliability of an old fax utility, etc. if malicious insertion happens a back door to your system can be achieved. You also need to be confident in your vendors and their development protocols as you may not have access to the source code running on your hardware.

Next month we will look at privacy and denial of service threats.

More articles from this month:

Leave a Comment

Your email address will not be published.