Avoid an IBM i Cyber Attack: 6 Things to Check Regularly

IBM i has the capacity to be one of the most secure operating systems around. But each year, the hundreds of Security Scans my colleagues and I perform reveal areas of concern.

For example, most exit points are left unmonitored and unsecured. Users have too many privileges. Many times, users carry root-level access with *ALLOBJ (All Object) special authority.

That lack of basic controls is concerning because servers and privileged accounts are under attack. The best approach to cybersecurity is a multi-layered approach, but all the layers in the world won’t do much good if you’re not staying on top of what’s happening on your systems.

Most data breaches go undiscovered for months—but if you notice suspicious activity, investigate it, and respond accordingly, the damage can be minimized or even prevented.

So, if you don’t want to make headlines with the next major data breach, here are six things to check regularly on IBM i:

1. Events on and Changes to the System

The controls you apply are not something you can just set and forget. There needs to be a constant review of the system; an activity required by most regulatory mandates. The reason is that when an event happens on your server, you don’t want to discover it for the first time during an audit perhaps months or even years later.

Along with constant review, you need to make adjustments when it’s appropriate.

It’s a good idea to have a baseline policy that you use to measure whether the system is compliant with how you expect it to be configured.

Take a look at system auditing. Are you collecting and analyzing all of the critical events? Do you need to send out notifications if this type of event happens? Notifications are a great benefit of an automated monitoring solution to offset the volume of events that would otherwise have to be checked manually.

2. Privileged User Activity

Look at who has the power over the system and the database.

Bear in mind that users require only one user ID and password. That gives them the ability to sign onto the machine to run line-of-business applications.  They can also use the same credentials to log into powerful network services like FTP and DDM to connect directly to the database, to run SQL statements, and possibly even invoke administrative commands.

So, when a user is given credentials, make sure you’ve established the correct containment controls, that the user has been granted only the appropriate level of access, and that you’re monitoring their activity on the system.

3. Password Settings

Take a close look at password and user configuration. Check it frequently to make sure things are not being changed without your knowledge.

You’d be surprised how many times we perform a Security Scan and the customer thinks they know how things are configured only to discover that the password expiration interval has been turned off or the minimum password length has been changed to a much shorter length.

4. Data Access

Data access pertains to the access levels users have to the database.

In the old days when applications were accessed predominantly via the green screen, it was fairly easy to control the users by overlaying menus and restricting a user’s command line permission. We rely on application vendors to correctly configure their applications, but you’d be surprised how often vendors leave the public authority to their application database wide open, inferring that it’s a customer’s responsibility to configure security in a manner that meets their corporate goals.

Essentially, everyone is looking to someone else to take responsibility for security. What happens is we find that security falls upon the server’s defaults. IBM ships the IBM i operating system with public authority levels at *CHANGE. And that’s enough authority to see, modify, and even delete data in a file!

If vendors simply load up their applications or if you create your own applications and don’t take the necessary steps to secure the objects, you’ll find that everyone with a user profile has full access to that application information. Remember, permission to see the data is all that is necessary for a serious data leak to occur.

5. Network Access Activity

The network access side of things came about when IBM TCP-enabled the server. This gave us a lot of great functionality, like FTP and ODBC connections into the database. But we’d previously relied on simple things like menus and application security. Suddenly, our security layer was transparent because FTP doesn’t display a menu and ODBC doesn’t consult with the application itself.

We need to make sure these types of connections are both monitored and controlled. In the world of IBM i security, controlling network access is often the single most impactful change you can make to your security posture. This is often best handled through the deployment of exit programs. Exit programs are registered to IBM i’s exit points and carry the ability to audit PC connections and possibly reject a user’s request to access data or run a command when it does not align with business rules, even if their OS object permissions would normally allow it.

6. System Security Values

Most configuration in the IBM i world is done through system values. It’s important to check these on an ongoing basis to make sure they meet your requirements. I recommend building some form of baseline, so that you have the ability to compare what your system looks like today versus what you expect it to look like. That way, any discrepancies can be addressed. Automation should be considered to simplify this mundane task, permitting more frequent verification and eliminating the manual overhead and possibility of human error.

A policy needs to be reviewed and updated at least annually, or any time new technology is introduced to the environment or a new risk has been identified. More often than not, we discover that the server was changed by someone who wasn’t familiar with the baseline or who made a change expecting it to be temporary but forgot to change it back.

Key Take-Aways

Security isn’t a one-time, set-and-forget activity. Regular auditing of system settings and user activity is a simple way to help maintain your security posture.

If you need help auditing data access, network activity, or want to chat about any of the other items discussed above, a free Security Scan is a great place to start. You’ll get a snapshot of where your system security currently stands along with free time with one of my awesome IBM i security experts to help you carefully interpret the results as well as prioritize corrective action if needed.