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.