IBM i Multi-Factor Authentication for MFA Compliance

IBM i Multi-Factor Authentication (MFA) is a critical cybersecurity defense required by PCI, FFIEC and 23 NYCRR 500 in Section 500.12b, stating any company providing financial services within the state of New York must implement MFA to protect system data and applications for all users that have external network access, or use an approved access control equivalent. IBM i Multi Factor Authentication prices are very affordable, simple to implement and provide the quickest means to protect against the cybersecurity threats 23 NYCRR 500 was drafted to address. IBM i 2FA, Two-Factor Authentication is the same as MFA and Multi-Factor Authentication.

Why does 23 NYCRR 500 require Multi-Factor Authentication? The majority of all security breaches are the result of poor user authentication practices, phishing scams and related credential thefts, so the state of New York made Multi-Factor Authentication a commonsense cybersecurity defense requirement. Although the IBM i has traditionally not been as susceptible to most cybersecurity threats like other platforms, with the adoption of SSO, EIM and other cross-platform integration efforts, implementing MFA will only enhance the platform’s security posture. Unlike PCI, the 23 NYCRR 500 requirements affects companies of every size equally. In addition to implementing IBM i Multi-Factor Authentication, the OS400 has many other security and access controls that can be enforced to tighten security. Simply strengthening system value password policies for example, can significantly affect chances of a security breach.

IBM i MFA forces users to authenticate with at least two different pieces of artifacts in addition to a user name and password to ensures their identity, which significantly reduce the chances a hacker or criminal can gain access. The odds a hacker could both guess, locate or steal a user's password and use one of the additional authentication factors is extremely low. The additional authentication factors must include at least two of the following three categories:

• A user’s knowledge (e.g.: password, PIN, passphrase)
• A user’s possession (e.g.: email account, smartphone, code-generating device)
• A part of the user (e.g.: fingerprint, iris, voice) ​

Using an authentication factor in the same category is not Multi-Factor Authentication. A user answering a security question and entering a PIN once their password is validated, is still only single-factor authentication. To be considered Multi-Factor Authentication, users must provide two or more different authentication factors.

Multi-Factor Authentication versus Two-Factor Authentication
Two-factor authentication, a.k.a. 2FA, is often used interchangeably with Multi-Factor Authentication, but there is a difference between MFA and 2FA. Two-Factor Authentication only requires use of two authentication factors, as the description implies, whereas Multi-Factor Authentication can mean use of two or more authentication factors.

Additional authentication factors requiring something the user possesses typically requires use of a phone, email, or a special hardware device, and is in most instances delivered as a special code or token, and not able to be reused. They should also expire if not used within a set period of time. Authentication codes and tokes are usually generated by a separate authentication system or third-party authentication service. The most common methods for the delivery of codes are: Smartphone app, Email (for this method to be secure, users must have a different login for email than for the IBM i), purpose built hardware devices (which usually provide many alternate delivery methods), telephone call (codes sent via audio message to one or more designated phone numbers), SMS/text message (no longer a recommended method due to successful hacking incidents).

Additional authentication factors that is a part of the user or is inherent to the user is usually the most expensive approach, as it requires expensive devices to scan the fingerprint or iris, or perform voice or facial recognition. This authentication method likely makes sense when there are only few authentication systems needed, or when data is extremely sensitive and costly to lose.

Multi-Step Authentication versus Single-Step
Multi-Factor Authentication solutions are developed differently and some allow the processes to be configured differently, such as when asking the user for the authentication factors in a single step or in multiple steps. Multi-step authentication prompts the user for each authentication factor on separate screens or windows, such as password and the following screen will prompt the user for the next authentication factor on an additional screen or window. Single-step authentication prompts the user for all authentication factors on a single screen or window and validates them all at the same time.

Companies may choose one over the other for various reasons, but multi-step authentication is less secure, as it confirms the first factor was correct before prompting the user the next authentication factors. Single-step authentication is more secure if validation of both factors is performed in unison, because it does not confirm which authentication factor failed, providing no useful information to the hacker. In fact, many authorities do not consider multi-step authentication to be an acceptable Multi-Factor Authentication solution. PCI DSS regulations only recognize single-step authentication, and further denote the user must not know the cause of failed logon attempts.

Third-party Authentication Services
The special authentication codes sent to users can come from various sources, depending on the Multi-Factor Authentication method and security level required. Third-party authentication services that can integrate with IBM i MFA solutions include:

• RADIUS—Generates codes for a variety of computing platforms within an organization via a special enterprise server.
• RSA SecurID—Provides codes using hardware or software, or on demand via smartphone. Generates a one-time code that expires in 60 seconds. This solution can be optionally coupled with a user's PIN.
• Authy from Twilio—Installs on a mobile device or in a browser and provides time-based, single-use codes on demand. Doesn't require a cell connection because it works through a standalone mobile app. Can also deliver codes to a mobile or landline phone.
• TeleSign—Provides authentication codes by mobile and voice.
• YubiKey—Provides codes via a thumb-drive device.
• Low risk environments may opt to use a Multi-Factor Authentication software offerings own authentication code–generating features.

MFA for IBM i and OS400 integration features
MFA for IBM i is a flexible solution that can be presented to users 5250 sign-on screen when logging onto a system. It can further be limited to a select group of users. MFA for IBM i can also be invoked based on a User ID’s special authorities, IP address, device type, based on dates times, OS400 or Supplemental Group, and a variety of other definable criteria.

MFA for IBM i can also be integrated into web applications, third-party applications and processes at a very granular level. For instance, only requiring MFA when a user accesses a sensitive application, and/or when a user need to access or change sensitive data.

IBM i MFA Auditing
Authentication on the IBM i is taken very seriously, and all access and security related operation activity is logged in the IBM System Audit Journal (QAUDJRN), and cannot be altered. All audit logs on the IBM i can be forwarded to a SIEM or SYSLOG Server enterprise logging. There are two different types of events that are logged, MFA application configuration changes and MFA authentication events and failures. For the scenarios that require immediate attention, administrators can have alerts trigger when a specific failure occurs, or automatically disable a user’s profile.

Advanced features above and beyond MFA
There are some environments that have extremely sensitive data where changes and access must be supervised. IBM i MFA provides feature called "four eyes" that allows a user to perform sensitive changes or operations which triggers an email to an administrator with a single-use code and the identity of the user making the request. The administrator can use the code to view the user's screen to watch it live.

IBM i MFA also provides User Self-Service features for Profile Re-Enablement and Password Changes without intervention from the Help Desk or an administrator. When a user answers preconfigured security questions, they can be automatically sent a time sensitive, single use code via pop-up window, email or hardware device to make the permitted user profile changes.