The mainframe community is rightly proud that our platform is one of the most secure in the world. But are we missing a trick by continuing to rely on passwords for authorizing access, despite the fact that IBM is now supporting more secure multi-factor authentication methods
in the z/OS environment?
Even Mainframers Are Bad With Passwords
Most mainframe users today still typically log in to their applications using the traditional ID-password combination. We know the risks that come with passwords; people write them down, share them with others, fail to update them regularly or use the same string of characters for logging into several systems. Guess what? Mainframe users suffer from these bad habits just like everyone else.
Some companies have replaced eight-character mainframe passwords with passphrases, which can range from fourteen to one hundred characters. But even if you adopt this approach, the same bad password practices can still compromise security.
Enter Multi-Factor Authentication
Considering these bad password practices and the risks they entail, it makes perfect sense that multi-factor authentication (MFA) is now available on the mainframe. The key to MFA, as most people working in technology will know, is that users have to authenticate in two or more ways, something they:
- Know (e.g., a PIN or password)
- Are (e.g., a fingerprint or retinal scan)
- Have (e.g., a fob, token or smartphone app that generates a temporary verification code)
Using more than one authentication scheme is much more secure than a single password or phrase. Considering that the risk of unauthorized access to the mainframe is rising, the argument for adopting MFA becomes even stronger.
Big Iron Security Risks Are Increasing
Today’s z Systems boxes are more open to the outside world than ever. Far from being isolated in a secure computer room or data center only accessible to technical staff, many of today’s systems are connected to the internet and host applications that are tapped into by a wide range of users across the enterprise and beyond. Because they are central to transaction processing and hold core business information such as financial data and customer records, they are routinely accessed by business users, customer-facing staff and sometimes end-customers themselves, increasingly from the web and mobile devices.
In addition, the rise of web and mobile interfaces for the mainframe
allows IT support teams to support z/OS applications while at home or on the move. This is largely a good thing, but it also increases the security threat. Mobile devices are more likely to be lost or stolen, and are susceptible to keylogging and other techniques that can be used to steal passwords and login information.
Despite these growing risks, companies are still procrastinating about adopting MFA, partly because of the implementation challenge. Updating the standard login screen for a mainframe application to enable MFA isn’t a simple process. Even modifying the login fields and adding descriptions to explain what authentication information users have to enter is a time-intensive task. If you’re running hundreds of mainframe applications (as many Big Iron customers do) then the workload involved is enough to make you think twice.
Session Managers Can Support MFA Adoption
One way around these issues is to use modern session management software. Most companies with a mainframe already use a session manager because it provides an easy way to access multiple applications. Users log in to the mainframe just once and immediately gain access to all their authorized applications. They can also switch between them without having to log on and off each one individually. Session managers streamline the login process, save users a lot of time and enhance the mainframe experience, especially if they support web and mobile access in addition to traditional 3270 sessions.
The cherry on top is that a modern session manager drastically cuts down the work involved in moving to MFA. Modifying the login screen on a session manager is much simpler and easier than playing around with the login process on individual applications. Additionally, you only have to do the modification once on the session manager screen, meaning the job takes a fraction of the time when compared with having to update every application.
What’s also extremely useful is that the login screens for a session manager can be customized for different individual users or groups of users. So, for example, you could easily pilot test MFA with one group of users (who will see the screen that supports the new authentication methods) while keeping the old login screen for everyone else. You could test different access methods (e.g.,a mobile app for some users and a physical pinpad for others) to see which works best. You could even give users a choice, if you so choose.
The beauty of this approach is that if IBM introduces updates to the way it supports MFA (which looks likely) you can incorporate these new capabilities without the headache of making changes to each of your mainframe applications each time.
No Room for Complacency
Any system is only as secure as its weakest link. In the case of the mainframe, this is users and their passwords or passphrases. As IBM has introduced MFA to combat this vulnerability on the mainframe it seems logical to implement it at the initial point of entry, which for most of us is our session management interface. However it’s done, we must accept that unless we embrace this opportunity to strengthen user authentication, we will be operating under a false sense of security.
Keith Banham has worked in IT for over 35 years and is the R&D manager at Macro 4, a division of UNICOM Global. Keith is responsible for the company's mainframe suite of products. He started as an Assembler programmer at a major bank and during his 30-plus years at Macro 4 has worked on many of the company’s solutions for application lifecycle management, application performance management, document management and session management. One of his recent roles was the modernization of these solutions by building web, Eclipse and mobile interfaces, as well as the modernization of Macro 4’s internal mainframe development environments.