How many IT security auditors does it take to screw in a light bulb? I promise you a punch line. Soon. But long tradition says I worry you first by describing the serious problem we can help you solve.
Doom and Dread
Keeping your organization’s data out of the hands of bad guys is an urgent matter of grave importance. Failure to keep your data safe can be very, very expensive, among other disadvantages. The infamous breach of 2013, in which a big retailer gave up millions of credit card records, has cost that company $264 million. $90 million was paid for by insurance. The rest was not. And not all the bills have come in yet—the suits are still in court. (Evan Ramstad, 2015)
Last year, a U.S. government agency—the single largest employer on the planet—gave up employee records regarding security clearances. “Hackers likely stole every background-investigation form completed…since 2000.” (Steven Norton and Clint Boulton, 2015) Ain’t that scary: the people who grant security clearances got hacked. The boss, Katherine Archuleta, no longer runs the agency.
In November 2015 they indicted the guy who allegedly stole 83 million addresses from a big, giant bank in New York. He and his people appear to have used the addresses to persuade bank customers to buy stock that the thieves had bought low, so the price would go up, so the thieves could sell high. (Liz Moyer, 2015) Except for the getting caught part, that sounds like a much cleverer use of stolen e-mails than smuggling bank accounts for the Nigerian prince.
Please forgive me for making light of these matters. I do respect the high importance of data security. I just don’t think you need to be reminded. If you don’t already know that data security matters, a lot, then you’ve been living under a rock, in the dark, and some IT security auditor will very soon direct you to turn on the lights.
How many IT security auditors does it take to screw in a light bulb? Nobody knows. Auditors don’t fix lights. They complain that it’s dark and tell someone else—you for example—to do the fixing.
What do You Fix Next?
What do you fix next? TechTarget reported some survey results last fall that boil down to this: The hardest part of IT security is “risk management,” the guessing where the greatest threats come from and how much time and money to spend on security right now. (Michael Heller, 2015) They make it sound like gambling. To loosely paraphrase: “I bet the next leak will appear at the FTP clients. This year, let’s put our money and people on that, and gamble that no one attacks us through the e-mail server till next year.”
Think of it as investment, rather than gambling. In that case, “What do we fix next?” is at least a two-sided question: One, what investment of time, money, and people will get us the biggest return in crime prevented? And two, what are the small, quick fixes we can implement with a relatively small investment of time, money, and people? And when the auditor points out a dark spot where replacing the bulb will meet both of those criteria, then Bingo! That’s the security problem you fix next.
Take FTP for example. FTP has been in use for a very long time. The bugs are worked out. It just runs, and we can forget about it. Every night, a scheduled batch job uses FTP to transfer today’s patient data across town quietly, competently. Each morning, another job sends yesterday’s credit card charges to the bank. On Saturdays, a batch job transfers next week’s payroll numbers to headquarters.
The trouble is, FTP was built long, long ago, with no attention to security. The data is clear-text. The commands are clear-text. The IDs and passwords are clear-text too. And you simply can’t keep sending that clear-text data anywhere outside the building, not anymore. No matter how many long-running batch jobs you’ve got relying on FTP, you’ve got to secure them, and probably very soon, because the risk is high and the auditor is complaining.
On the other hand, the solutions are surprisingly simple. A simple bit of monitoring will show you the extent of your FTP risk. And there are at least two very reliable ways to secure that FTP traffic from z/OS – without revising a single line of the JCL in those batch jobs.
Both of those solutions involve securing FTP traffic by encrypting it with SSH.
Secure FTP with SSH VitalSigns for FTP
Secure Shell (SSH) is a widely trusted cryptographic protocol. It was first released in July 1995 as a secure alternative to rlogin and telnet. It spread quickly and widely. By the end of ‘95, it’s inventor, Tatu Ylönen of the Helsinki University of Technology, had founded SSH Communications Security to manage further development. The original freeware has evolved into OpenSSH, a broad collection of tools that implement SSH security. Ylönen’s company makes proprietary improvements and now provides Tectia® SSH Clients and Tectia SSH Servers to implement SSH on most significant platforms, including z/OS. SSH uses public/private key encryption (a.k.a. PKI) to authenticate users and machines, to encrypt traffic, and ensure the integrity of data. It is now the standard network security tool in the Linux/Unix world. Remote access to a Linux/Unix system is almost always guarded by SSH. Microsoft® promises a implementation for Windows® this year. (Steve Lee, 2015)
SSH encrypts IDs, commands, and data, and passes them through a single connection between client and server. Configuring firewalls to allow SSH traffic is far simpler than FTP-TLS alternatives, because SSH uses a single connection for both commands and data, in both directions, through one standard port number. That one connection can even handle multiple simultaneous sessions. SSH can secure z/OS FTP traffic in either of two ways:
- Send FTP transfers through an encrypted “SSH tunnel.”
- Convert FTP to Secure FTP (SFTP).
The difference is the number of FTP installations involved. Tunneling means transferring data between two FTP installations, with SSH in the middle. FTP-to-SFTP conversion lets FTP and SSH at one end transfer data to an SSH client/server living alone at the other end—a common situation on Linux/Unix boxes.
FTP through an SSH Tunnel
SSH tunneling means that 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 transports safely encrypted FTP commands and data between them. See figure 1.
Figure 1: z/OS FTP transfers encrypted and passed through an SSH tunnel
Converting FTP to Secure FTP (SFTP) SFTP is the SSH version of FTP; it’s the file transfer mechanism built into SSH clients and servers. The SSH client/server supplies user authentication, data encryption and compression, connection management, data integrity checks. But you can’t just issue FTP commands to an SSH client/server and have SFTP come out the other side. The command syntax is different, so you need some kind of translator in between.
So you put an SSH client on z/OS, between your FTP client and the outside world. The FTP client passes commands and data to the SSH client. The SSH device converts FTP to SFTP. Then secure SFTP traffic travels the SSH connection to the SSH server at the other end. See figure 2.
Figure 2: z/OS FTP transfers automatically converted to encrypted SFTP
What’s the Hard Part?
It is relatively simple to install the SSH clients/servers and get them talking to one another. The harder part is telling the FTP clients/servers to work with their SSH partners.
You might rewrite all the z/OS batch jobs that use FTP, so that they tell the z/OS FTP client to work through SSH tunnels, or to convert FTP to SFTP, or both, or one or the other, depending on the destination. But revising JCL to encode those directions is definitely the hard way, about like shoveling snow with a scrap of lumber.
The simpler alternative is smart controlling software that wraps around the FTP client and changes its configuration to match the job and the destination. Think of it as a proxy FTP client. It sits between the batch jobs and the native z/OS FTP client. You configure z/OS to use it as the default for outgoing FTP commands and data. Then when a batch job wants to send a transfer, it talks to this proxy FTP client. The proxy looks at the job name, or the user ID, or the destination, then passes the message to native z/OS FTP along with configuration instructions about SSH encryption and/or conversion.
Conclusion
The system I’m describing is a VitalSigns for FTP-SSH Tectia combination from Software Diversified Services. VFTP-SSH on z/OS will secure any and all outgoing FTP traffic that has an SSH installed at the other end.
And VFTP-SSH will do that without you having to re-write a single line of batch JCL code.
On top of that, VFTP provides far simpler and more thorough monitoring of z/OS FTP traffic than z/OS itself does. Auditors love it when you show them monitoring records to prove that, yes, you did fix that bulb. The lights are on. The rats stay away. The data is safe.
Free Demo/Trial
We offer individualized product demonstrations by request. Your organization can also try SDS Software on your system for 30 days, free of charge.
Contact SDS
Phone: (800) 443-6183
Phone: (763) 571-9000
200 Village Center Drive, Suite 250
North Oaks, MN 55127
USA