Strengthen IBM i Password Security With Multi-Factor Authentication

March 15, 2021 Bill Hammond

As stories of data breaches caused by exploited credentials continue to make headlines, basic password protection mechanisms are no longer good enough. Organizations require an additional layer of protection that is also easy to use and doesn’t impose an additional burden on administrators.

IBM i systems contain the data that drives your business, including financial transaction information, healthcare records, and other personally identifiable information for customers, partners, and employees. Much of this data is subject to regulations such as SOX, PCI DSS, HIPAA, and GDPR. Therefore, any data breach can result in regulatory fines, lost revenue, remediation costs, legal fees, lost productivity, brand damage, and more. To fully secure data and comply with regulations, you need overlapping layers of security to detect and respond to threats and address evolving requirements.

The basic IBM i password policies that served in years past are no longer sufficient. Security breaches caused by passwords stored in unsecured locations (such as written on sticky notes), guessed passwords, or brute-force password attacks have compelled IT shops to implement stronger password management controls. Fear of such breaches, coupled with best practices and regulatory requirements, have driven companies to adopt multi-factor authentication (MFA) procedures that require users to enter an additional form of identification beyond passwords, especially when accessing systems that hold valuable or sensitive data.

How Multi-Factor Authentication Works

Multi-factor authentication, also referred to as two-factor authentication, has become a popular method for strengthening security since it requires a user to provide more than one identifying factor prior to accessing a system, an application, or its data. MFA requires a user to authenticate with at least two different pieces of evidence (beyond a username) that prove one’s identity. In order to qualify as MFA, these pieces of evidence must come from two of the following three categories, known as authentication factors:

• Something the user knows (password, PIN, passphrase)
• Something the user possesses (email account, smartphone, code-generating device)
• Something inherent to the user (efingerprint, iris scan, voice recognition)

Because MFA requires users to provide at least two authentication factors, the chances of a hacker gaining access to a system is substantially reduced. In other words, there is a very low likelihood that a hacker could both guess/ find/steal a user’s password and obtain the use of the second authenticating factor – for instance, the user’s smartphone that receives an authentication code.

It is also important to emphasize that a second use of the same authentication factor doesn’t constitute MFA. In other words, having users provide the answer to a security question or enter a PIN once their password is validated only amounts to single-factor authentication because the user is providing two forms of the same type of authentication factor: something they know. To be true MFA, a user must provide two or more of the different authentication factors that were just mentioned – for instance, something the user knows (such as a password) and something the user possesses (such a code delivered thorough their smartphone).

MFA Is Integrated With IBM i Processes In Various Ways

Multiple third-party vendors, with Precisely among them, provide MFA solutions for IBM i, and IT shops often choose to buy and implement one of these rather than going to the trouble to create their own. Regardless of whether the MFA solution comes from a third party or is developed in-house, it is important that it provide flexibility in how MFA is invoked since users access the IBM i from different places and processes. The most common way MFA is presented to users is from the 5250 sign-on screen a user sees when logging onto a system.

Nonetheless, you may not need to require MFA for all users or in all situations. For this reason, your MFA solution should provide the ability either to select individual users or groups of users that require MFA or to define specific situations in which users require MFA. And it should go a step further by allowing you to set a variety of rules for when MFA is invoked; for instance, you may want to enable or disable MFA based on special authorities, IP addresses, device type, dates/times, and a variety of other criteria.

Logging MFA Activity

Like other security-related IBM i operations in which it is important to log activity, it is essential that your MFA application also provide comprehensive logging. A secure file or journal (such as QAUDJRN) is often utilized to provide an audit trail that cannot be altered. Of course, if your enterprise uses a SIEM console to capture enterprise-wide security events, you’ll want to integrate the logging from your MFA solution with your SIEM solution.

There are two different types of events that should be logged: MFA application configuration changes and MFA authentication failures.

• Logging MFA Application Configurations — Object-level auditing and user-level auditing should be in place to record any changes to MFA configuration functions.
• Logging MFA Authentication Failures — Not only should authentication failures be logged but, in some cases, it might be important for administrators or security officers to receive alerts when failures occur. Some MFA solutions provide the ability to automatically disable user profiles in the event of certain kinds of MFA authentication failures.

The solution you choose should also provide a way to integrate MFA into your IBM i applications and processes at a granular level. In some cases, you might want to invoke MFA when a user accesses a sensitive application, and/or you might want to trigger MFA when a user is about to change sensitive data. For some IBM i shops, it is also important to have the ability to integrate MFA into web applications.

Precisely Can Help

MFA is a powerful technology for protecting sensitive data from being accessed by external and internal actors with bad intentions, and there are numerous approaches and features to consider when choosing an MFA solution that’s best for your organization. It’s important to work with a trusted company to deliver an adaptable MFA solution that will work seamlessly with your IBM i environments and that is backed by expert services and responsive support.

Precisely provides end-to-end security solutions and services for IBM i, including powerful options for MFA that support a range of authentication services. Let our team of IBM i security experts help you solve your MFA needs. Find out more at https://www.precisely.com/product/precisely-assure/assure-security.

This content is sponsored by Precisely.

Bill Hammond is product marketing director at Precisely. Bill has over 25 years of product marketing and product management experience with enterprise software products. He has been responsible for the messaging, positioning and launching of products in a broad range of disciplines from business intelligence to eDiscovery to storage management. At Precisely, Bill covers the IBM infrastructure products which includes the Assure product family for IBM i and the Syncsort family of IBM mainframe solutions.

RELATED STORIES

Can You Build Data Integrity Without Securing IBM i Systems?

A Conversation With Carol Woodbury on IBM i Security