Exclusive Interview with

Linwood Overby

Senior Technical Staff Member, IBM
Enterprise Networking & Transformation Solutions
Designer for z/OS Communications Server

Network security has been a key focus area for the z/OS Communications Server. For many z/OS releases there has been a steady stream of significant security technologies added to the product. While these functions are built on standards for optimal interoperability, they provide superior protection by leveraging the hardware and software strengths of the platform. Business focus on security has become more intense recently in the face of increased regulations and threats of attack. There is also increased awareness that many security breaches occur from within the enterprise. One of the outcomes of these trends is that network security is no longer considered just a perimeter technology but rather has evolved into a multilayered discipline which includes implementation of more network security enforcement on the target server systems. The z/OS Communications Server has the technologies needed to enable a safe and secure deployment in this increasingly demanding and hostile environment.

Lin Overby: a synopsis

Lin Overby is a Senior Technical Staff Member in the Enterprise Networking and Transformation Solutions area of IBM. He is a designer for z/OS Communications Server with a focus on TCP/IP technologies and is the lead designer for network security on z/OS. Lin has been with IBM for 27 years.

He has been certified by (ISC)² as a Certified Information Systems Security Professional, has 32 patents or patent applications, and is an IBM Master Inventor.

Q1: Lin, I gather that there are some very germane (and possibly even exciting) security related enhancements that have been added to z/OS Communication Server.  Lin, to get us going can you please give us a fairly high-level, and hopefully pithy, summary of what these enhancements are all about?

A1: Our latest release of  z/OS Communications Server has significant new security functionality. In z/OS V1R7, which became available September of this year, we added new support for IPSec and a new function called Application Transparent-Transport  Layer Security (AT-TLS). The focus of these enhancements is to lower the deployment cost of implementing network security on z/OS in terms of programming and administrative costs. Both technologies are available to applications without requiring application changes and are controlled with network security policy. Our new IPSec support is an eventual replacement for the existing z/OS Firewall Technologies for IP packet filtering, IPSec, and Internet Key Exchange (IKE). It has a simplified supporting infrastructure, reduced definitions, and improved diagnostic and event messages. It also adds support for Network Address Translation (NAT) traversal which resolves a long-standing incompatibility between IPSec and NAT.

      Our AT-TLS support is new technology and provides TLS support as a TCP/IP stack service. We are providing a new workstation-based configuration tool called the Network Security Configuration Assistant which allows an administrator to easily configure both IPSec and AT-TLS policy together as a single administrative task. These technologies enable building a secure network infrastructure using IPSec, TLS, or a mix of both IPSec and TLS.

Q2: Lin, though I think that I might know the answer to this, why don’t you please share with this readership as to what you see as the role and objective of z/OS Comm. Server security functionality?

A2: Since the hostility of networks that are allowed access to the mainframe has increased, the demands for security are greater than they were in the days of pure SNA. The Communications Server provides the network access to the mainframe, and therefore must maintain a hardened line of defense for the platform. To this end we have built a suite of protections. For example, we have an integrated intrusion detection and prevention service built directly into the TCP/IP stack. This IDS, which is policy-based rather than signature-based, has capabilities to detect and prevent not only known attacks, but also new attacks for which there are no developed attack signatures. Our TCP/IP stack has also been armored to use SAF (e.g.RACF) protection against unauthorized user access to TCP/IP resources such as local ports, the network, and the TCP/IP stack itself.  In environments subject to compliance regulations, it may be required that z/OS applications communicate only with network resources and users that are at the appropriate security level. In these situations, the Communications Server provides key functionality in the overall z/OS Multilevel Security (MLS) solution by ensuring that network communication occurs without “write-down” or “read-up” violations.    

      Protection of critical mainframe data in the network is also crucial. z/OS Communications Server makes available numerous network security protocols, such as IPSec, AT-TLS, and SNA session level encryption, that use strong cryptography to protect both TCP/IP and SNA application data. Many applications included with Communications Server are enabled for TLS and Kerberos. For network security, we exploit the zSeries and z9 hardware for cryptographic acceleration, and are able to take full advantage of the z/OS SAF digital certificate support.

Q3: Lin, z/OS has now had intrusion detection capability for sometime now … so can you please tell us what is new on this front and what z/OS users should be looking to do to gain full protection from what is now on offer?

A3: There are new trends in network security that are increasing the value of deploying the intrusion detection service in z/OS.  First, I’d like to compare the z/OS Communications Server Intrusion Detection Service with other intrusion detection methods provided by traditional outboard network-based IDS devices. The Communications Server intrusion detection service is integrated into the TCP/IP stack and detects network attacks that are targeted at the z/OS system by evaluating data in context at pre-determined points, called attack probes, in the execution path. Outboard network intrusion detection systems scan traffic as it traverses the network towards the target. Because of the placement in the network of these functions, these two IDS methods use a vastly different approach and have different strengths. We view the z/OS IDS as complementary to these outboard network-based IDSs in that it extends the overall IDS coverage that an enterprise can achieve by detecting attacks that may otherwise go undetected by outboard network-based IDS devices.

      While an outboard network-based IDS device can detect attacks based on attack signatures, there are several trends that are decreasing the effectiveness of using an outboard network-based IDS device. The first trend is the increased use of end-to-end encryption. When data is encrypted, network-based IDS does not have access to cleartext data and is unable to detect an intrusion based on a comparison of encrypted data to an attack signature. This was fine when encryption terminated at the perimeter, but not when the entire data path is encrypted. The z/OS IDS checks for intrusions after inbound data, encrypted with IPSec, has been decrypted in the endpoint z/OS.

      The second trend is an increase in attacks that outpace the ability to create new attack signatures. In fact, a major complaint cited in the field of intrusion detection is the administrative overhead in keeping the multitude of attack signatures current. Without using attack signatures, our policy-based approach allows an administrator to specify IDS actions to take for a category of intrusion conditions. This means that we can detect both known and new attacks. For example, a policy could be set up that specifies that undersized packet fragments, which are indicative of an intrusion attempt regardless of content, are discarded and an event recorded. A policy can specify a single attack condition and IDS action for all malformed packets. By leveraging our built-in defensive error checking, the IDS can determine that a packet is malformed without the use of signatures for each malformed packet attack (e.g. Ping-of death, teardrop). The z/OS IDS exploits its position as the connection endpoint using a number of behavior analysis techniques to determine potential intrusions. By having access to system resource consumption patterns such as storage usage and packet discard rates, and knowledge of connection states, the Communications Server IDS more accurately detects intrusions with less incidence of false alarm, and aggressively limits resource consumption that can occur during peaks of activity observed during denial of service attacks. The sensitivity level and attack response of the z/OS IDS can be regulated for the environment through its IDS policy.

      Recently Tivoli has added support to NetView to extend the base functionality Communications Server provides by enabling automation of notifications and more sophisticated actions based on the alerts generated by the Communications Server IDS. In addition to strengthening the coverage of intrusion protection, we are focused on increasing the usability of the function. We have a workstation-based configuration tool, the zIDS Manager, that greatly simplifies the task of configuring IDS. We have recently updated this download to include sample configuration to help administrators jumpstart the configuration task. As with our IPSec and AT-TLS support, a major focus is reduction of deployment costs.

Q4: Lin, most of us that have worked with Web-to-host have some idea of what SSL is and kind of know that TLS has superseded it.  Now I see IBM talking about something called Application Transparent - Transport Layer Security (AT-TLS).  Can you please tell us what this is all about and how we can exploit this new technology

A4: TLS is a popular network security technology used to encrypt data and its use has extended beyond web to other applications. Traditionally, applications needed to be enabled for TLS in order to benefit from TLS protection. This TLS enablement meant that the application source code had be updated to add TLS API service calls, possibly dual pathing for both TLS and non-TLS paths, and TLS function control had to be added to the application configuration. By the way, this configuration would most likely be made in an application-specific manner so that an administrator had to use different configuration for TLS for each application.

       Traditional application TLS enablement means delays in security deployment in a time where there are increasing requirements to deploy network security quickly. Our AT-TLS changes this situation dramatically. With AT-TLS, TLS is now a TCP/IP stack service which can be used without requiring application enablement. The AT-TLS function can be selected through an AT-TLS policy file that is common for all applications. A z/OS application using the AT-TLS function can interoperate with a TLS-enabled application since AT-TLS uses standard TLS protocols “on the wire”. Some applications may make changes if they need to be “TLS-aware”. A new programming interface is provided so that applications can access the AT-TLS function of the stack without requiring full TLS enablement. For example, using the programming interface, an application can verify that a connection is TLS-protected, or can request the SAF userid associated with a client certificate received and verified during the TLS handshake. AT-TLS opens TLS protection to a whole class of  z/OS applications that were unable to use TLS in the past such as applications where source code is unavailable, and applications written in languages other than Java or C, such as COBOL or PL/1. In fact, AT-TLS can be used for applications using all of the supported sockets APIs, including CICS Sockets, except for the PASCAL API.

Q5: Lin, from what I recall there are so many different, and often competing, IP-centric security schemes for end-to-end data encryption and authentication … and I know that we support nearly all of them on z/OS.  Is there any easy (if that is at all possible), rules-of-thumb that we can use as to what scheme (or technology) we should use … in preference to others … for different scenarios.  If there is no short answer to this … that is also OK.  Just share with us what we should be looking at and where we can go to get some help to determine what schemes we should be using for different host related activities or scenarios [e.g. SNA access, Web-to-host, FTP, Web server etc.]

A5: I agree with your assessment that there seems to be many competing protocols, and there certainly are lots of available options. There are differences in each scheme and there does not appear to be a single solution that meet the requirements for every environment. Fortunately, the main schemes such as SNA session level encryption, IPSec, TLS, Kerberos , and SSH all provide basic strong encryption and authentication of application data. IPSec goes an extra step and protects network headers. So given that all of these functions cover the basics, some key questions remaining when making a technology selection are what workloads are covered by a given security protocol, and which of these security protocols are supported by other platforms in the network.

      In general, IPSec provides the broadest protocol protection for TCP/IP covering all of the transport layer protocols. TLS, which requires reliable transport, covers TCP only. SNA session level encryption protects SNA application data, however, some of the IP technologies are applicable when that data is carried over an IP network. For example, IPSec can protect the UDP-based Enterprise Extender (EE) traffic. Both IPSec and TLS can protect the TCP-based TN3270 traffic in the IP network. It should be pointed out that many network services such as SNMPv3 , OSPF, and DNS have security built-in to the service at the message level. These security protocols are defined by the Internet Engineering Task Force (IETF) as part of the network service specification.

      Generally, it is more likely that you will be able to run IPSec when considering the  other platform security protocol support, since IPSec is implemented as part of the OS in most platforms. As mentioned earlier, TLS has been traditionally associated with an application since the application requires changes for TLS enablement and so other platform support may be more limited.  The Communications Server AT-TLS support should improve this situation on the z/OS side since z/OS applications no longer requires TLS enablement.

Q6: Lin, everything said and done mainframes, and ‘MVS’ in particular, have never been a high profile target for ‘hackers’ – most likely because many of them have heard that mainframes have good security.  Today, we are pushing Linux on mainframes … and though Linux is also more secure than Windows … we know that hackers to try to infiltrate Linux systems.  So, given that z/OS, with Comm. Server, has all these high-end security features … is there ‘game play’ where we might use z/OS as a ‘super-duper’ firewall type scheme for Linux ‘guests’ on a mainframe?

A6: One of the main security advantages of running Linux on the mainframe today is that traffic between Linux and z/OS LPARs can utilize hipersockets links within the mainframe so that inter-system traffic is safely contained within the mainframe, without network exposure. Another strength, which ties in with the value proposition of Linux server consolidation on the mainframe, is that these Linux systems can be more tightly controlled physically, and can be centrally managed, which means less exposure to information theft when compared with a non-mainframe deployment of Linux boxes which are distributed and physically dispersed. A major strategy of the IBM Mainframe Charter is to position the mainframe as the security manager of the enterprise. So over time I expect to see that the Linux side of the mainframe will be able to take increased advantage of the security services of z/OS such as SAF control of private keys and certificate management.

Thank you very much Lin.

Lin, as you must have heard, in-depth interviews with high-profile IBMers like YOU are a trademark of this Web site.  Your friend Mac Devine's 3 interviews continue to be extremely popular.  I have a feeling that this interview will join those exalted ranks.  I can't thank you enough.  This was very enlightening to me and you helped tie up many lose ends.  Keep up the good work Lin and maybe we can do an update in Spring of 2006.  All the best.