Note: The use of a second identical authentication factor does not suffice as a valid MFA safe guard. For instance, users answering a second or third security question or using the addition of PIN after their password is validated, only accounts for single-factor authentication since they are both the same type of authentication factor "something they know".
Difference between Multi-Factor Authentication and Two-Factor Authentication
Multi Factor Authentication MFA is usually used interchangeably with 2FA Two Factor Authentication. MFA is more commonly used to described requirements in compliance regulations. The only difference "might" be the number of factors used for authentication, since 2FA only involves two, while MFA could mean two or more authentication factors.
Implementing Single-Step versus Multi-Step Authentication
IBM i MFA solutions are designed differently and can be configured to ask the user for authentication factors in a single step or in multiple steps. Single step authentication prompts the user for all authentication factors from a single screen and then validates all factors at one time. Multi step authentication prompts for one authentication factor on one screen or window, such as password and, if accepted, then prompts the user to provide the next authentication factor on another screen or window.
Companies may choose, but multi-step authentication is considered to be less secure since it reveals that the first factor was correct if the user is prompted for the subsequent authentication factor. Single-step authentication is the most secure route as long as it validates both factors at the same time, and should the login fail, it doesn't tell the person who is logging in which authentication factor failed. In other words, no useful information is divulged to a would-be hacker. Because of this, many entities don't consider multi-step authentication to be true MFA. For instance, PCI DSS regulations recognize only single-step authentication to be a valid form of MFA, and then only if it is implemented in such a way that the user can't see the cause of a login failure should one occur.
Secondary Authentication Factors and Methods
Let's look more closely at the two authentication factors and methods that are used beyond the first authentication factor (which is usually something known, like a password). Something that the user possesses through the use of a landline phone, a smartphone, email, or a special hardware device, a second factor of authentication is in most instances delivered as a special code (sometimes referred to as a token). In order to prevent codes from being saved and reused, they are typically created in a way that they can be used only once and will expire if not used within a set period of time. The code is usually generated via a separate authentication system or third-party authentication service (more about these services in the next section). The most common methods for the delivery of codes are:
- Smartphone app - A variety of mobile authentication smartphone apps exist that interface to the system to be accessed and generate single-use codes.
- Email - Codes are sent to the user's email address. For this method to be secure, it is essential that users have a different login for email than for the IBM i.
- Telephone call to landline or mobile number - Codes are sent as an audio message to one or more designated phone numbers associated with a user
- SMS/text message - Codes are sent by text message to a designated mobile phone.
Although this continues to be a common way to deliver codes, a number of recent high-profile hacking incidents involving this method is causing many agencies, including the National Institute of Standards and Technology NIST, to discourage the use of this method.
Special hardware devices usually in the form of a small device that can be attached to a key ring, these have a range of features and methods for delivering authentication codes. Some are as simple as showing a code on a small screen on the device, which is then entered by the user. Hardware-specific delivery of codes is more secure than delivery by telephone, smartphone app, or email. However, this method can be costlier to deploy and, like smartphones, these devices can be lost or stolen.
Something That's Inherent to the User In some organizations, the secondary or even the tertiary factor of authentication is made through something that is inherent to the user, such as fingerprint, iris scan, face recognition, etc. Depending on the method used, the cost of implementing this as a factor of authentication can be high, so it is mostly used by organizations that have particularly sensitive data.
The special authentication code that is generated for the user can come from a variety of sources, depending on the authentication method and level of security needed. Some examples of third-party authentication services that can integrate with IBM i MFA solutions to supply authentication codes 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.
It should be noted that some MFA software offerings provide their own authentication code–generating functions, but these are generally utilized only in low-risk environments.
MFA is Integrated with IBM iSeries Processes in Various Ways
Multiple third-party vendors, with Syncsort 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.
Your solution 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.
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.
Additional Functions That Incorporate MFA
Some MFA solutions provide added functionality that can be used in specialized situations:
• The "Four Eyes" Principle for Supervised Changes and Operations—For operations that could have significant risk or for data changes that are so sensitive they must be supervised by another person, some MFA offerings provide the ability to enforce what is called a "four eyes" policy. Here's how it works: when a user wishes to perform a sensitive change or operation, a designated administrator receives an email with a single-use code along with information on the identity of the user making the request. The administrator can then enter the code into the user's screen and observe the change or operation while it is being made.
• Self-Service Profile Re-Enablement and Password Changes— Multi-factor authentication technology can be used to help users re-enable their profiles or change a forgotten password without the intervention of an administrator, thus freeing administrators to focus their time on other priorities. For instance, a user can answer preconfigured security questions and/or receive a single-use code via pop-up window, email, or hardware device before making changes to their profile.
Syncsort MFA Multi-Factor Authentication solutions
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. This is why 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. Having brought together the top security solutions in the industry, Syncsort 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.
Compliance Regulations for IBM i MFA Multi-Factor Authentication
23 NYCRR 500 - Financial and insurance institutions are commonly required to meet the requirements defined by the State of New York Department of Financial Services in its cybersecurity regulation that covers companies providing financial services within the state. The 23 NYCRR 500 regulation applies to institutions that do business in New York, regardless of where they are headquartered. 23 NYCRR 500 Section 500.12(b) states: "Multi-Factor Authentication shall be utilized for any individual accessing the Covered Entity's internal networks from an external network, unless the Covered Entity's CISO has approved in writing the use of reasonably equivalent or more secure access controls."
PCI DSS - The Payment Card Industry (PCI) Standards Council specify the Data Security Standard (DSS) for companies that handle credit card information must meet. Section 3.2 of PCI DSS requires all users connecting remotely to the CDE be secured by MFA, including administrators, general users or outside vendors. It also requires that all administrators attempting non-console access to the cardholder data environment (CDE) provide MFA. In the past, MFA was required only for any remote access to the CDE, but the new requirement means any administrative access via internal networks must also be validated with MFA. At some companies, this could include quite a few people because a typical IBM i environment has several user profiles that are technically at the administrator level and who can access the CDE—for instance, anyone with *SECADM or *ALLOBJ authority.
FFIEC - The Federal Financial Institutions Examination Council (FFIEC) provides guidance for the use of MFA in an Internet-banking environment, providing minimum expectations for authentication of "high-risk" online transactions involving customer access to critical information and/or movement of assets. Specifically, it states: "The agencies consider single-factor authentication, as the only control mechanism, to be inadequate for high-risk transactions involving access to customer information or the movement of funds to other parties."
Many other compliance regulations state or imply the benefits of MFA, including HIPAA, Swift Alliance Access, GDPR, SOX, GLBA, and others.Considering the increased cybersecurity threats facing companies, it is perhaps just good common sense to implement MFA, even if no obligation exists to meet regulatory compliance requirements. The fact that the IBM iSeries is usually housing companies most sensitive or mission critical data and business services, security best practices would have you consider adding this MFA to further protect sensitive data from being accessed in an unauthorized manner. After calculating the the significant costs and disruptions a security breach causes, it is in fact the prudent thing to do.