Evangelizing Mainframe
Print Email

Be Proactive With Security

We pretty much assume that mainframes are completely secure. We’ve had RACF or other security products installed and used for over 20 years—of course it’s secure. But in these days of ransomware attacks and government-sponsored cyber attacks (let alone groups of hackers with their own agenda) do we really know that our mainframe is secure?

Common Vulnerability Scoring System

Let’s suppose that a vulnerability were to be found in a Microsoft product. Would we know about it? Yes. Information about the vulnerability would be released by anti-virus software vendors. It would appear in the news. And Microsoft would issue a patch that fixed the vulnerability. So what happens when IBM discovers there’s a security vulnerability in its software? IBM finds out and creates a patch to fix it. It also gets a Common Vulnerability Scoring System (CVSS) score. The CVSS score reflects the overall security impact of a vulnerability: 0.1 to 3.9 is low, 4 to 6.9 is medium, 7 to 8.9 is high and 9 to 10 is critical.


One thing to bear in mind is that mainframes are massive transaction servers. They can run enormous numbers of transactions in short periods of time. They can multi-task. And that means that an attack can get into the mainframe without standing out because of the amount of noise (real work) going on around it.

Messages from end users, potential customers and the Internet of Things need to be secure so that they can’t be intercepted. For example, FTP is an old standard, and data is sent as cleartext. That means that commands and IDs and passwords are also sent as cleartext. To get around this, people adopted SSH, a network protocol that provides administrators with a secure way to access a remote computer. SSH also refers to the suite of utilities that implement the protocol. SSH provides strong authentication and secure encrypted data communications between two computers connecting over an insecure network (e.g., the internet). SSH uses public/private key encryption to authenticate users and machines, encrypt traffic and ensure the integrity of data.

SSH tunneling can be used to transfer data between two z/OS FTP installations, with SSH in the middle. A file transfer gets encrypted before it leaves its home machine, then decrypted after it is safely inside the destination machine. SSH clients/servers reside at either end, guarding the passage between the FTP clients/servers and the outside world. The SSH tunnel safely transports encrypted FTP commands and data between them.

SFTP is the SSH version of FTP; it’s the file transfer mechanism built into SSH clients and servers. But SFTP commands are different from FTP commands, so the batch jobs can’t speak to SSH directly. They need some kind of translator in between. Users can put an SSH client on z/OS, between their FTP client and the outside world. The batch jobs talk to FTP. The FTP client passes commands and data to the SSH client, which translates FTP to SFTP. Then secure SFTP traffic travels the SSH connection to the SSH server at the other end.

Old SSH Keys

SSH keys provide a more secure way of logging into a virtual private server with SSH than using a password alone. Generating a key pair provides users with two long strings of characters: a public and a private key. The public key goes on any server, and users can unlock it by using the private key that they have previously been sent. The problem for mainframe sites is that they may well have been generating these keys over a number of years and don’t have any real control over them in place. Remember, these SSH keys never expire. Apart from the security risk this creates, it may make an organization non-compliant with mandatory security regulations such as Sarbanes–Oxley Act, Federal Information Security Management Act, Payment Card Industry and HIPAA. NIST-IR 7966 recommends ensuring keys are rotated, eliminating static keys, prohibiting automated access that relies on hard-coded passwords, and prohibiting sharing or copying private keys.

Popular Programming Languages

The other issue with mainframe security comes from the fact that it has embraced popular software. The most obvious one is Java. Java running on Windows and Linux frequently has issues with security and articles about them abound. By running the same software on the mainframe, users make themselves vulnerable to the same exploits. The same applies to other programming languages that may be running on your mainframe.

Be Aware

The thing to remember is that you shouldn’t assume that your mainframe can’t be compromised without the proper security. It’s worth testing the security, or employing a company that will test it for you, for vulnerabilities. And it’s worth testing whether you have any people vulnerabilities—whether someone will answer the phone and give the person on the other end access to your applications. The price of peace really is eternal vigilance.

Keeping your mainframe secure is a never-ending battle as the hackers get more knowledge and more sophisticated, your security team needs to do the same. After all, you don’t want to be the first mainframe-using organization to be front-page news for being hacked.

Trevor Eddolls is CEO at iTech-Ed Ltd, an IT consultancy. A popular speaker and blogger, he currently chairs the Virtual IMS and Virtual CICS user groups. He’s editorial director for the Arcati Mainframe Yearbook, and has been an IBM Champion every year since 2009.

Posted: 10/18/2016 12:00:40 AM by Trevor Eddolls | with 0 comments

Print Email

Please sign in to comment.

Sign In

Blog post currently doesn't have any comments.

Join Now!