IBM i (AS/400) Security Best Practice: Recommended Response to Invalid Sign-On Attempts

Larger numbers of invalid attempts could indicate an intrusion attempt, while three, five, or even ten attempts are probably the sign of a frustrated user.

It’s also possible that attempts numbering in the thousands or even hundreds of thousands are the sign of a broken application, perhaps one lacking a built-in mechanism to recognize when its attempts to connect to the server are being denied. But that assumption should never be made without investigation. And a broken application is still an application that is not fulfilling the business purpose for which it was written.

The level of risk increases significantly if the offending profile is determined to be, for example, QSECOFR, and is not disabled automatically, or if the security team has no way to be notified of failed access attempts in a timely manner.

Virtually every system in the latest State of IBM i Security Study had at least one profile with an invalid sign-on attempt, which is not surprising. 49 percent of systems had a profile that had experienced more than 100 denied attempts. 20 percent had more than 1,000 invalid sign-on attempts against a single profile. One system in our study had more than three million attempts against a single profile.

It’s worth noting that the count of the number of attempts continues even if the profile is disabled. There is nothing an administrator can do to prevent the attempts as long as the user can obtain a connection to the server. For that reason, the most important element is timely detection and notification.

Figure 6 shows the default action taken when the maximum number of allowed sign-on attempts is exceeded. In 95 percent of cases, the profile is disabled and this is always recommended. When using explicitly named devices (as opposed to virtual device names) the recommendation is expanded to include disablement of the device description. It is not recommended to disable virtual devices, as the system typically creates a new device when the user reconnects. The device setting does not apply to all connections, such as ODBC and REXEC services.

The other five percent of servers disable the device, but leave the profile enabled. This creates risk if the user re-establishes a connection, or perhaps connects to a service that does not require a workstation device.

Timely notification and investigation of an unusually large number of denied access attempts is a critical first phase in the detection of a possible compromise.

Too often, data breaches hit the headlines accompanied by a startling revelation over just how long the breach was permitted to occur. An organization cannot stop a breach if they don’t know it’s happening, and invalid sign-on attempts are one of the most obvious indicators.

To protect your system, make sure profiles are disabled by default after the maximum allowed sign-on attempts is exceeded.

A tool for self-service password resets can help the users who have truly forgotten their passwords. Password Self Help is one option that makes it easy for IBM i users reset a password and it sends instant alerts to designated personnel when unsuccessful resets occur. This allows administrators to take corrective action before any damage is done.

A multi-factor authentication solution can also protect your systems by requiring another credential in addition to a password. Powertech Multi-Factor Authentication is one such option that can help protect servers inside and outside the firewall, as required by PCI DSS.