The Wall Street Journal stated that, as part of the Equifax breach, database queries were performed “that provided access to documents and sensitive information stored in databases in an Equifax legacy environment.” Many organizations have dubbed their IBM i as “legacy.”

We don’t yet know the details of the Equifax breach. But just for fun, let’s assume for the moment that their legacy system was indeed an IBM i. What could Equifax have done to protect themselves?

IBM i provides many options for implementing “defense in depth”—the approach you want to use if you’re serious about protecting the data on your IBM i. Another way to think of defense in depth is implementing “multiple layers of defense.” With this approach, you assume that one layer will fail or be breached, so you have another layer that will stop the breach or allow you to detect it. You implement as many layers of defense as you need to come into line with your organization’s risk-tolerance level. Let’s take a look at the options we have available.

Run at QSECURITY Level 40

Your first layer of defense is to make sure the system is running at security level 40 or 50. Otherwise, profiles can elevate their privileges without having authority to the higher-powered profile. In addition, some tasks may be performed without being audited. Which brings me to the next layer of defense.

Use Auditing

Turn on auditing! Too many organizations don’t bother turning on auditing because they never intend to look at the audit journal. If you don’t configure auditing and at least send it to your SIEM (if not look at it yourself), you’ll be limited in your ability to recognize and be alerted to what may be inappropriate access or attempts to access your system and organization as a whole.

Get Rid of Default Passwords

I realize that I must sound like a broken record by now, but really…you must stop allowing profiles to have default passwords. This is possible beginning in V7R2. If you specify *LMTPRFNAME and *ALLCRTCHG in the QPWDRULES system value, you cannot create or change a profile to have a default password. It’s well-known, when encountering an IBM i system, that the first password to try is the profile name. Don’t give hackers that opportunity!

Set QSECOFR to Status of *DISABLED

You can protect QSECOFR from misuse by setting it to STATUS(*DISABLED). As long as you know the password, you can always sign on to the console, even when QSECOFR is *DISABLED.

Reduce Excess Special Authorities

Reducing the number of profiles that have special authorities will reduce the damage that can be done should the profile be compromised. Obviously, limiting the number of profiles that have special authorities—especially *ALLOBJ—to as few as possible is key to keeping your system and data secure.

Use a Method to Elevate Privileges

There are times when special authorities are required to perform tasks on IBM i. Rather than assign the special authorities to a user’s profile permanently, use a method that will elevate users’ privileges. One method is to write a utility that adopts authority. Another method is to purchase a utility, such as HelpSystems’ Authority Broker, that provides a more structured method of elevating authority. These products typically allow you to choose between adopting authority and swapping and provide logging and reporting of the elevated authority.

Implement Object-Level Security

If an object is *PUBLIC *EXCLUDE, unless a profile has *ALLOBJ or has been granted authority to the object, users (and hackers) will not be able to access it. Regardless of how the object is accessed, object security is in effect.

Use Row and Column Access Control (RCAC)

Beginning in V7R2, you can use SQL to apply additional permissions beyond object-level security to limit which rows a user is allowed to access.

Implement Exit Programs

Exit programs are a great secondary line of defense for when a profile requires access to an object. For example, a service account may need authority to read a file via a JDBC connection. Using an exit program, such as HelpSystems’ Network Security product, you can restrict the connection to a specific IP address and then prevent access via other network access methods such as DDM and FTP. This is just one example of how exit points aid in the defense in depth strategy.

Encrypt Data

Last but not least, when protecting data, consider encrypting it. If the data is lost or stolen but has been encrypted, it will be much more difficult (if not impossible) for the hacker to sell the data or exploit it themselves.

Encrypt All Communications

One of the ploys of hackers is to sniff the internal network for user IDs and passwords. If all your communications—both internal and external—are encrypted, credentials cannot be sniffed.

Use Multifactor Authentication (MFA)

While MFA is no guarantee that your credentials cannot be misused, multifactor authentication makes it much more difficult.

Stay Current

If there’s only one lesson to learn from the Equifax breach, it’s the importance of staying current. I realize that there are operational restrictions to staying current. Some PTFs require an IPL, for example, and outages are not always possible. I discussed the benefits of staying current in a previous article.

Scan Your Web Application

Even if you are running your web application on IBM i, use a web application scanner to ensure the application doesn’t contain vulnerabilities or is susceptible to issues such as SQL injection errors. I’m surprised that most organizations skip scanning their IBM i web applications. All web applications—regardless of the web server on which they’re run—can be poorly coded. Running the web application on IBM i doesn’t magically exempt them these vulnerabilities.

Assume Your Organization Is Going to Be Breached

If you take the attitude of when rather than if you’ll experience a breach, you will be much better prepared if an event occurs. I’m still surprised at the number of organizations that haven’t developed an incident response plan. Do you know what you’d do if you discovered your organization was breached? Who should you call first? Do you stop processes or let them continue? Do you have an arrangement with an organization that will help you investigate the breach? Have you talked with the local field office of the government organization that should be notified if your organization is breached? In the U.S., that would be the FBI, but obviously the appropriate agency will vary by country. Do you know when/how you’d have to notify individuals that their personal data was compromised? The specifics vary by country and are rapidly changing. For example, both Australia and Canada have recently broadened their breach notification laws, and the EU’s General Data Protection Regulation (GDPR) is just around the corner.

Summary

Even with highly publicized breaches, the details are often not published; therefore, we may never know what kind of “legacy system” was compromised in the Equifax breach. But I’m hoping that you will take my suggestions seriously and implement “defense in depth,” using as many features as you deem appropriate to protect the data residing on your IBM i systems. The last thing you want is the possibility your IBM i configuration contributing to a data breach.