As computers become more interconnected, administrators are often charged with providing security for other platforms across various types of network. Providing effective security across these connections is a challenge.
This series examines common problems and approaches to cross-platform security, some basic underlying principles, and provides recommendations to make this security easy and effective.
In the first article, which appeared in the Winter issue of Enterprise Tech Journal (available at http://esmpubs.com/u4eqv), we discussed some of the options and obstacles to implementing cross-platform information security. We provided some simplifying guidelines and suggested Lightweight Directory Access Protocol (LDAP) and Kerberos as part of any optimum solution. The second article, which appeared in the May issue of Enterprise Tech Journal (available at http://esmpubs.com/vwfm5), explained what LDAP is and how it contributes to effective cross-platform security.
Here we describe how Kerberos works with LDAP to prove users’ identities and provide encryption over the network automatically. We will show you two risks it protects against and how it works. Note that in this series of articles, we treat the mainframe as just another server or platform in the network.
The Value of Kerberos
To understand the value of Kerberos, it helps to understand the first risk—sniffer programs. Imagine our example from the previous articles of a programmer’s workbench, a Windows desktop computer that connects through a Local Area Network (LAN) to TSO and CICS on an IBM mainframe. LANs rely on a special circuit board called a Network Interface Card (NIC) that’s added to each Windows computer in order to connect that computer to the network. Most of the time, each NIC ignores all messages on the network except ones that come from, or are addressed to, the NIC itself.
However, a sniffer program running on the desktop computer gives the NIC an instruction, telling it to show every message on the network. The sniffer program can then read every message on the network or network segment, including sign-on requests to the mainframe containing userids and passwords. A hacker running a sniffer program could then use this information to sign on to the mainframe, assuming the identity of that user.
You might think that encrypting the sign-on request could provide protection against sniffer programs, but it doesn’t. The sniffer doesn’t have to decrypt the sign-on request; it can instead record it and then play it back (sending the recording to the mainframe).
When the mainframe receives the recording of the encrypted sign-on request, it decrypts it. (Of course, at this point, the mainframe is expecting sign-on requests it receives to be encrypted, just as the original copy of the sign-on request needed to be decrypted.)
The mainframe then uses the sign-on request to sign on the user. The hacker running the sniffer program would then be signed on as that user. This recording and playback is called a “playback attack.” This is the source of the adage that the greatest security risk to mainframes can be Windows.
A second, related risk is that once the user is signed on and connected to whatever server he wants to work with, his data flows unencrypted, not only over the LAN, but also over any other networks involved.