IBM Security Global Forum

 View Only

Is your MFA solution really safe, as in, risk-free?

By Jim Porell posted Tue August 20, 2019 09:34 AM


Multifactor authentication (MFA) and data encryption are the best means to reduce the risk of hacking attempts on a platform. However, it's critically important to understand that an MFA solution targeted to one platform, say a mobile device or desktop as the system of engagement, is probably insufficient to address the security needs of another platform that gets accessed later, such as a system of record.

IBM Z systems are considered the most secure enterprise platforms in the world. That's the myth. The reality is, they are the most securable. They are just as vulnerable as any other platform when critical vulnerabilities are left open. Good mainframe security is a triumvirate that includes processes and people, in addition to technology. Unfortunately, based on the reputation of the mainframe, many customers are not leveraging the best processes available to them. According to the 2019 Verizon Data Breach Incident Report, human error continues to be one of the top causes of data breaches.

Let's take a look at two common, dangerous situations and how to address them.

First, consider the business that adopts MFA for access to their desktops and mobile devices. This is a smart proactive step to reduce the risk of unauthorized access to those devices. The user subsequently uses the internet to access mail, web links, download files or any number of other ways in which a virus or trojan horse can infect their desktop. With the mistaken belief that the desktop MFA will make all subsequent system accesses secure, they go to log on to another system, like IBM Z, using traditional passwords or pass phrases. Unfortunately, their internet behaviors may have enabled a key stroke logger, or for an insider attack, allowed someone else in their organization to see their password, and now that back-end system is at risk. In other environments, a business may use a third-party tool to request a temporary password to access a back-end system. Again, a key logger could be in place that enables that service to be subverted for malicious purposes.

To defeat these problems, ALL systems should have MFA deployed.

Second, many businesses believe that only privileged users (e.g. system programmers, database administrators) need MFA.  Again, a mistaken and perilous belief. Any system access on IBM Z by a business usually includes access to personally identifiable information, money management, intellectual property or other valuable assets that a business believes should be protected. As a result, all IBM Z users, regardless of role, should leverage MFA to sign on directly to the mainframe. The good news is that the same MFA logon processes used on the desktop can be used on many of the backend systems, such as IBM Z, because of the open way in which the IBM Z Multi-factor Authentication product has been developed. While it doesn't provide a single-sign-on solution (and I don't believe there is any product that meets that goal), it can provide a consistent sign-on with a wide variety of third-party MFA solutions.


Don't leave your IBM Z system at risk. More importantly, don't leave your critical business processes at risk. Protect your business and your users with IBM Z Multi-Factor Authentication to align your people, process and technology.



Thu September 12, 2019 05:29 AM

Good point! I agree it is paramount to protect our business and users with IBM Z Multi-Factor Authentication. Thanks for the insight.

Tue September 10, 2019 04:34 AM

Thank you James.
If I'm not wrong, we are talking about "technical userids" often used by distributed applications, where "biometric" does not seem applicable in many cases. I agree with you about the possibility for smartcard to be stolen,  at the same manner as our credit cards in the wallet can be also stolen. Then, I think that MFA is a very good solution, when applicable. When not, we can use the bases of security with the adequate level of security education.

Sat September 07, 2019 09:22 PM

Luigi, I'm a big fan of digital certificates. Many times, they are put into a smart card. Unfortunately, since they are inanimate, they can be stolen. As a result, I'm a much bigger fan of biometric authentication. As for occasional use of MFA and biometrics, show me a mainframe user that isn't accessing critical business information. Anytime personally identifiable information, money or intellectual property is at risk, I believe it should always be strongly protected. Occasional access just doesn't seem good enough to me for those instances.

Fri September 06, 2019 09:56 AM

I think that old client systems or external client procedures that use a technical userid can use Digital Certificate with client authentication to enforce a more effective secure login adding also a user activity tracking to monitor the access. This could be the first step for a strong authentication.   MFA can be used for the occasional access with regular userids. It's just my opinion.

Thu August 22, 2019 12:37 PM

Great question, Rob. Probably two separate problems here and it spans beyond FTP. 1. Batch jobs that are regularly scheduled over a network. Most of those jobs don't require a userid/password. FTP could be part of a scheduled task, so exempt from sign on in those cases. 2. The other is the FTP, telnet, SSH variety that are done on an occasional basis. Then the answer breaks down into two parts regarding trusted target or source. Things like MFA Out of Band access might work for some of the applications that use 8 character userid/password combinations. If the application doesn't use RACF or SAF to satisfy the sign on and do that themselves, then it might be time to look for an alternative implementation that leverages a system authentication, instead of an application unique authentication.

Wed August 21, 2019 03:37 AM

With MFA protecting human access to the system and applications on IBM Z, how should we further secure FTP access to data sets and files on IBM Z?  Denying all FTP access may be the way to go, but reality presents us with old-fashioned client systems that use FTP to download text data sets.  Those customers cannot just shutdown FTP, and with a multitude of client platforms they will still have users on RACF that are susceptible to user id + password authentication, with never expiring passwords, or no password at all (ACF2).