The IBM Mainframe: Just Another Node On The IP Network!

With the introduction of MVS/ESA Version 4.3 in 1993, the IBM Mainframe included the major foundations for meaningful Distributed Systems connectivity, including the first steps of POSIX compliance via OpenEdition functionality.  However, even before this timeframe, the TCP/IP protocol was available in the first release of MVS/ESA Version 4 (4.1), although in a very limited fashion.  In this instance, MVS was benefitting from the path already trodden by the VM Operating System and the TCP for VM software product.  Put another way, even when TCP/IP was in its early stages, being deployed and evolved in universities and scientific laboratories (E.g. CERN), its foundation was being embedded into the IBM Mainframe.

Early IBM Mainframe TCP/IP usage allowed for RS/6000 (AIX) connectivity, LAN integration via Novell NetWare, typically via the 3172 Interconnect Controller, Sockets Interface (E.g. CICS), et al.  In 1994, IBM introduced the Open Systems Adapter (OSA) processor feature for S/390 Parallel Enterprise Servers.  The OSA provided native Open Systems connectivity to the Local Area Network (LAN), directly via the Mainframe processor.  The OSA feature supported the Fiber Distributed Data Interface (FDDI), Token-Ring & Ethernet LANs, arguably making the 3172 controller obsolete.

So, since the early-mid 1990’s, even before pervasive usage of the Internet, the Mainframe was already a fully functioning and efficient user of IP networking.

How is the TCP/IP function being utilized by the IBM Mainframe today?

TCP/IP on z/OS supports all of the well-known server and client applications.  The TCP/IP started task is the engine that drives all IP-based activity on z/OS.  Even though z/OS is an EBCDIC host, communication with ASCII-based IP applications is seamless.

IP applications running on z/OS use a resolver configuration file for environmental values.  Locating a resolver configuration file is somewhat complicated by the dual operating system nature of z/OS (UNIX and MVS).  Nearly each and every z/OS customer deploys the following core TCP/IP services:

TCP/IP Daemon: The single entity that handles, and is required for, all IP-based communications in a z/OS environment is the TCP/IP daemon itself.  The TCP/IP daemon implements the IP protocol stack and runs a huge number of IP applications to the same specifications as any other operating system.

TCP/IP Profile: Is loaded by TCP/IP when started.  If a change needs to be made to the TCP/IP configuration after it has been started, TCP/IP can be made to reload the profile dynamically (or read a new profile altogether).

FTP Server: Like some other IP applications, FTP is actually a z/OS UNIX System Services (USS) application.  It can be started within an MVS environment, but it does not remain active in z/OS.  It immediately forks itself into the z/OS UNIX environment and tells the parent task to kill itself.

Telnet Daemon: There are two telnet servers available in the z/OS operating environment.  One is the TN3270 server, which supports line mode telnet, but it is seldom used for just that.  Instead, it is primarily used to support the TN3270 Enhanced protocol. The other telnet server is a line mode server only, referred to as the z/OS UNIX Telnet server (otelnetd).

Many IBM and ISV software products exploit IP and USS functionality, most typically WebSphere (MQ).

Whether UNIX System Services (USS) or TCP/IP usage, the convergence of the IBM Mainframe and UNIX technologies arguably became mandatory with the deployment of TCP/IP on the IBM Mainframe.  Obviously the technical personnel that support these different platforms have their own viewpoint as to which platform might be the best, but that is somewhat of an arbitrary point.  However, what is absolutely certain is recognition of how data is stored and secured in a UNIX environment and indeed the z/OS (MVS) specific environment, originally named MVS OpenEdition, but now commonly referred to as OMVS.

There are fundamental differences too numerous to mention when comparing the User and File management policies and processes, when comparing the security and data access lifecycle intricacies of z/OS and UNIX.  So what you might say!  This might be a cursory and lax attitude, as business critical data is probably being stored in OMVS file systems, if only for FTP purposes, but more than likely for other more pervasive and user based access (E.g. Database, Messaging, Data Mining, Data Exchange, et al).

So, which technical party is managing the security of Unix System Services (USS) file systems for the OMVS Mainframe deployment?  Is it the Mainframe Systems Programmer, the Unix System Admin or the Mainframe Security Team, or somebody else?  To date, some people might have thought it didn’t matter, but of course, seasoned security professionals knew that this was never the case.  However, the migration to z/OS 2.1 is a tangible juncture for each and every IBM Mainframe installation to review their USS and thus OMVS security deployment.  Why?

The BPX.DEFAULT.USER facility was introduced with OS/390 2.4 and was a commonly used process for implementing USS (OMVS) security.  However, with z/OS 2.1, the BPX.DEFAULT.USER facility is withdrawn, meaning that the Mainframe user must perform some migration actions.  IBM provide some generic assistance with this challenge via APAR OA42554 and APAR OA37164.  However, maybe this is an ideal juncture to perform a thorough review of USS (OMVS) security, vis-à-vis a comprehensive and dispassionate audit, highlighting issues, implementing standards and securing exposures.  For example, use of UID(0) must be eradicated and certainly no human being should be allocated such privileges.

There are some useful guidelines available from security specialists such as Vanguard, where the process can be simplified using their Identity & Access Management (IAM) toolset.  Similarly, recent user conferences have included presentations on this subject matter.

In conclusion, the IBM Mainframe can be classified as just another node on the IP (TCP/IP) network.  However, as always, no matter how secure the Mainframe platform might be, the biggest threat is typically the human being, and for USS, the migration to z/OS 2.1 forces us to review OMVS security settings.  Therefore, let’s do a good job and eradicate any security exposures we might have inadvertently implemented over the years.  As we all know, passing an external security audit process doesn’t necessarily mean our IT systems and processes are secure, while sometimes the internal security people are better qualified or more knowledgeable than external auditors.  Arguably most external auditors will do a good job of auditing UNIX platforms, yet their Mainframe knowledge and abilities are typically limited.  It is therefore somewhat of a paradox that in this particular area of z/OS USS, the typical UNIX exposures are not highlighted in the typical Mainframe security audit process…

One must draw one’s own conclusions as to the merits of engaging 3rd Mainframe security specialists to perform such an audit, coinciding with this z/OS 2.1 migration activity, safeguarding that OMVS security and processes are as good and secure as they can be.  Put another way, why wouldn’t a Mainframe organization go that extra mile to safeguard their most valuable of assets, namely business critical data, engaging a 3rd party specialist to review and provide guidance on this subject matter.

Is The Mainframe A Good Repository For Enterprise Wide User Passwords?

The subject matter of creating and maintaining passwords is arguably infinite and for the purposes of this article, we will provide a concise review…

In an ideal world, strong multiple factor authentication techniques would be deployed for every user authentication access attempt, including:

  • Biometrics – Unique measurable attribute (E.g. Voice, Fingerprint, Retina, et al)
  • Tokens – A physical device (E.g. Smart Card, One Time Password, et al)
  • User Secret – Something you know (E.g. Password, Phrase, PIN, et al)

Obviously the more authentication techniques used in combination, the stronger the authentication process becomes!

Primarily due to cost and complexity, passwords remain the most pervasive form of user authentication.  This simple fact in itself exposes the human being as the primary vulnerability in safeguarding access to business systems.

However, passwords are simply just words, phrases or a string of characters that can be easily remembered by the user.  As such, passwords can be compromised in numerous scenarios, for example:

  • Hardcopy – The written word; users write them down and/or share them with others.
  • Cracking – Passwords can be guessed; typically a simple program designed to try many possibilities in rapid succession.  Simple passwords might be guessed by another human being.
  • Unsecure Transmission – Passwords no matter how complex are transmitted over an unsecure network in a simplistic (E.g. text) form, or with basic encoding, which can be easily converted to text.
  • Inappropriate Storage – Passwords are stored on a server, fixed or removable media storage, in a simplistic (E.g. text) form, or with basic encoding, which can be easily converted to text.

These potential vulnerabilities generate possibilities for somebody to obtain a password and subsequently access a business system as the user associated with their password.  The potential consequences are obvious, depending on the importance of the user…

However, if password systems are implemented to deny malicious attacks, inspection or decryption of passwords being transmitted over the network, or at rest on fixed or removable storage media; passwords can be very secure.  Therefore a combination of technology and good practice is required, safeguarding compliant and latest technology systems are deployed, educating users not to be the point of vulnerability, by allowing others to easily access their password.

There might be some urban myths as to whether the IBM Mainframe is a good platform for enterprise wide password management, for example:

  • Sniffing For Mainframe Passwords (This scenario depends on the lack of an SSL infrastructure)
  • CRACF (This Mainframe password cracking utility identifies simple user/password/group vulnerabilities)

Both of these scenarios are examples of whether “reverse engineering” thinking is good practice.  So let’s pose as a potential hacker and see if we can obtain a user and associated password.  These scenarios highlight the combined requirement of deploying a secure environment and safeguarding that user’s don’t and indeed are not allowed to create simplistic (low strength) passwords.

Ultimately password strength is governed by password length and associated combination of characters, including alphanumeric, upper/lower case, special characters, et al.  There are also some other urban myths regarding the IBM Mainframe, regarding the maximum length of password (E.g. 8 Characters) and the type of character supported (E.g. only alphanumeric uppercase).  For many years, RACF has supported the password phrase extension to the password rules, increasing password length to 100 characters:

  • Maximum length: 100 characters
  • Minimum length: 9 characters, when ICHPWX11 is present and allows the new value or 14 characters, when ICHPWX11 is not present
  • The user ID (as sequential upper case characters or sequential lower case characters) is not part of the password phrase
  • At least 2 alphabetic characters are specified (A – Z, a – z)
  • At least 2 non-alphabetic characters are specified (I.E. numeric, punctuation, special characters, blanks)
  • No more than 2 consecutive characters are identical

The use of high strength passwords is required because although human beings might give up after trying tens or maybe hundreds of password guesses, automated programs can achieve millions of password access attempts in a second, for example:

There will always be a debate as to whether Single Sign On (SSO) or password synchronization is the best solution for maintaining password integrity and both solutions have their merits.  Once again, a multiple authentication factor solution increases the security strength of either solution.

Passwords are most vulnerable when they’re forgotten and intervention is required to reinstate the password.  Traditionally password resets were performed by an IT Support resource (human being) and this human interaction process generates what are termed “social engineering” challenges.  Let’s explore a typical scenario, while considering any exposure and circumvention techniques:

Password Reset: IT Support Process

  • User has forgotten or mistyped their password (log-in denial/intruder alert)
  • User contacts IT support function (might encounter a no response or queue waiting scenario)
  • IT support asks user for credentials (E.g. name, department, et al)
  • IT Support authenticates this information with some on-line resource/authenticates user
  • IT support resets password or not, depending on whether user is “manually” authenticated
  • User might be prompted to immediately change their password on first successful log-in attempt

The security weaknesses associated with this process are numerous and prone to human error, for example:

Obvious Security Weaknesses: Business Exposure

  • IT Support forgets to authenticate the user
  • On-line resources for authenticating the user are not available
  • User credentials are widely available and so “social engineering” exposes the system
  • Password reset authority is granted to many non-IT personnel, for work productivity reasons
  • Password reset activity is not tracked and so is not auditable, accountable or traceable
  • IT support now knows the user password

Having identified the potential simplistic vulnerabilities, we implement processes to eradicate them, for example:

Implementing Controls

  • IT support training to safeguard user authentication occurs for each and every password reset request
  • Safeguard sufficient and secure user authentication information is available to IT support personnel
  • Implement a password reset solution/process (E.g. software) to eliminate non-IT personnel password reset personnel (I.E. for non-standard scenarios)
  • Implement a self-service solution (E.g. software) that allows the user to change their passwords, based on previously supplied “security challenge” questions and answers

Where user authentication depends on a password, eliminating “human” intervention touch points wherever possible is mandatory, minimizing the opportunity for “social engineering” techniques to compromise security.  We have also identified that the IBM Mainframe does offer a secure environment for retaining passwords with ultra-high-strength security and that as always, the IBM Mainframe remains difficult to hack…

There are many software products to assist password reset scenarios, some that are platform specific and some that don’t support the IBM Mainframe.  For those customers with an IBM Mainframe, Vanguard PasswordReset is an enterprise wide self-help password reset solution.

Vanguard PasswordReset addresses the common problem of forgotten or expired passwords, allowing authorized users to quickly and securely change their passwords at any time without help desk intervention.

Easy to install and use Vanguard PasswordReset does not require any software on user workstations or any additional hardware, with a rigorous set of checks and balances to ensure that only authorized users can initiate password reset requests.

Users register with the Vanguard PasswordReset website by typing a series of questions and answers or answering a set of predefine questions. When users want to change their passwords, they log on to the Vanguard PasswordReset website, type the answers to the questions and reset their passwords.  For increased security, Vanguard PasswordReset allows system administrators to set the number of questions that must be answered and other characteristics of the answers.

A self-service password solution such as delivers Vanguard PasswordReset the following benefits:

  • Eliminates lost productivity when users are unable to access computer applications.
  • Provides improved help-desk productivity by allowing support staff to concentrate on solving other issues rather than time-consuming password resets.
  • Enhances enterprise security by standardizing password reset activities and eliminating human error.
  • Reduces IT support costs by automating costly password resetting activities.
  • Helps retain customers by making it easier for them to access extranet and e-business environments.
  • Virtually eliminates actual or hidden costs associated with installing, administering, maintaining and retiring thin-client software on user work stations.

In conclusion, maintaining passwords for user authentication purposes is a complex, costly and all-encompassing activity.  Eradicating human intervention and touch points wherever possible, minimizes the impact of “social engineering” attacks, while deploying highly secure software solutions further increases the integrity of the primary access method to mission-critical business data, namely user access via authentication.