Does Big Iron Guarantee Security? Maybe

Are mainframe Web services more secure

• By Roberta Bragg
• 01/01/2002

Increasingly, some analysts and vendors see strong security features as a key reason for moving Web services to the mainframe. But does superior security for some mainframe applications translate to superior security for all applications, including Web hosting? The jury's still out on that one.

To date there's been little hard evidence to prove that mainframe-based Web services make more secure Web sites. This month I'll present the evidence I've found so far, along with my thoughts, marketing propaganda and the questions that you should be asking if your organization is considering such a move.

First some facts: The number of Web servers in the U.S. running SSL, the primary software protecting e-commerce transactions, on the OS/390 doubled last year, according to the Netcraft Secure Server Study (www.netcraft.com/ survey). That's not saying much, though, since only about a half percent of the 121,000 OS/390 systems followed in the survey were actually running secure Web servers. Worldwide, mainframes host a mere few thousand of the estimated eight to twenty million Web sites.

Those small numbers make an overall security evaluation of "Webified" mainframes difficult. CERT, a U.S.- government-funded research center at Carnegie Melon University, has been collecting and publicly publishing specific information on security incidents and specific platform- and application-based vulnerabilities since the late 1980s. A search of their extensive vulnerability and incident databases returns zero listings associated with mainframes. And CERT officials acknowledge that they have little information on the vulnerabilities of mainframe-based Web systems.

Natural Advantages
Lack of evidence as to actual incidences or published vulnerabilities doesn't mean the mainframe presents a more secure architecture. Are there significant facts or features that could prove advantageous from a security standpoint? Some features of mainframe security systems are obvious advantages for Web systems:

Dual Stacks. VM/ESA and other mainframe platforms allow for the creation of two TCP/IP stacks. One stack is connected to the internal network; the other is connected to the public Internet. No pathway exists between them, but each has access to a shared file system. Web server pages are updated to the shared file system repository where the external Web server has read-only access.

Under this system, internal IP addresses aren't exposed to the Internet, and there's no way to access the internal network from the public Internet. Any problems on the external Web server side will not affect the internal. Unix- or Windows-based servers support dual-stack configurations as well, but generally by employing two network cards and thus hiding internal addressing. A mainframe's dual stack, however, offers fewer opportunities for external compromise, since external users are automatically excluded from write access to the file system.

Cryptographic processing speed. To keep information secure, both data and transaction encryption is possible. While most OSes include encryption support, encryption is CPU-intensive and can have a significant impact on overall performance. That means increased data confidentiality carries a heavy price: A reduction in response time to Web requests.

Mainframe cryptographic co-processors can isolate encryption computations and prevent performance problems. While these co-processors may be available for many platforms, newer systems, such as IBM's zSeries, include them as standard components. Several varieties of Web servers, including popular Linux-based versions on Linux emulations, are available. Some of these emulations include support for SSL accelerator cards, another way of freeing the CPU from encryption processing.

Multiple processors. While popular computing platforms tout the ability to manage multiple processors—in some cases up to 32—mainframes offer the ability to combine the computing power of 10 or 20 times that many. IBM's zSeries, for example, supports as many as 640 processors, which in turn supports the creation of larger sites and large numbers of multi-site, single-server operations. Multiple processors don't mean more secure environments, but they do simplify the implementation of multiple security solutions.

Reliability. 24x7 uptime has long been one of the cornerstones of mainframe technology. Mainframe components are designed for zero downtime and many—including security-related components—are duplicated, which allows for downtime-free replacement if something does go wrong.

Server Compartmentalization. The ability to compartmentalize, or operate multiple virtual servers on one system, provides the opportunity to run multiple Web servers and sites while preventing security issues on one from affecting others. It also means that alternative OSes can be emulated and thus provide a wider array of Web server applications from which to choose. Linux, for example, can be emulated, allowing the use of thousands of Apache Web sites running in thousands of emulated Linux servers on a single machine. Because the virtual servers operate independently of each other, the compromise of one Web site would be, in theory, limited to one virtual machine.

Availability. Of course, mainframes aren't available for sale on every street corner. This inherently makes them safer, since a hacker can't compromise that which he, or someone willing to provide him with a tool, has no knowledge of. Comparatively few people have access to a mainframe that would allow them to research and test explorative, exploitive or malicious code. But … understand that it's possible to rent mainframe simulations on inexpensive hardware platforms at a manageable cost—several hundred dollars per month. And unsecured access to mainframe-based Web servers may also be providing just the access needed.

Issues and Unknowns
While there are solid advantages to mainframes-as-Web-hosts, there are a lot of unknowns as well. Some are issues that can be overcome with time and money. Others will simply have to wait until existing Web technologies themselves can be improved.

Single point of failure. Relying on a single mainframe can confine your Web site to a single point of failure. Certainly, the reliability of components is never a substitute for a good disaster recovery plan. But while it's easy to duplicate the typical Web sites on exact platforms at distinct geographic locations, co-locating mainframe-based sites may not be as financially feasible.

Training/staffing issues. Web sites are usually produced using languages and technologies that are far different from a traditional mainframe programmer's skill set. Knowledge of Java, CGI, ASP, Visual Basic, C++ and Perl are required in a legacy Web environment. Managing the transition may require making new programming hires, retraining current staff, or finding products that translate other languages into Java bytecode that can be run on platforms that support the Java Development Kit.

No matter what Web server you run, you must harden it, then maintain vigilance to keep it secure. While it may be true that we currently have plenty of mainframe-savvy programmers and operators, it's an aging generation, and one that has little knowledge of Web servers and Web applications. Where are the young, upwardly mobile mainframe programmers and operators? How many bright college graduates are seeking careers in the mainframe world? Furthermore, where will we find experienced, crack Web masters for the exotic native Web server?

If you contemplate moving to the mainframe because you feel your current platform is too insecure, ask yourself how much time and attention has been devoted to making that current platform secure. If current staff consists of experienced technologists on this platform, what makes you think this staff will do a better job of securing a platform they may know nothing about? As you contemplate movement to mainframe-based Web servers, do a corporate and industry search for individuals with any experience in this environment; encourage young Web-savvy employees to enroll in corporate or industry training on mainframe technologies, and crosstrain current mainframe gurus in Web skills.

Vulnerabilities of current Web servers. Many mainframe implementations use Web server software originally developed for Unix or Windows platforms. Unlike native mainframe Web servers, these products have documented vulnerabilities, and they're not likely to suddenly disappear just because you're running them on a mainframe. By using this software, you may be increasing the risk of compromise. In addition to assuring that mainframe security remains in place, you'll need to gain knowledge of new risks and how to deal with them.

Visit the CERT/CC Web site (www.cert.org) and you'll find multiple vulnerabilities and incidents that apply to Domino Web servers, WebSphere and Apache. Don't forget to scan for Linux problems. You'll find issues involving root compromise, buffer overflows and much more. Microsoft's Internet Information Server (IIS) is lambasted greatly for any flaw; do its competitors really do a better job or does IIS just get more press? IIS was blasted for its "cross-site" scripting vulnerability in February 2000, but Domino (VU# 642239), WebSphere (VU#560659) and Apache (VU#672683) are also vulnerable to cross-site scripting attacks if left unpatched. [The numbers following each server name are the ID numbers assigned by CERT/CC in its vulnerability database.—Ed.]

Patches for these flaws and others exist and must be applied to ensure security. They should also be tested before implementing across, say, thousands of virtual Linux servers on that mainframe. You'll be looking for the potential that patches have to produce new vulnerabilities or interfere with other processing running on the server.

Vulnerabilities of established Web technologies. Even native mainframe Web server applications have to use technologies that have demonstrated vulnerabilities. They have to run TCP/IP; and many tout compatibility with JavaScript, and even Active Server Pages. Can the architecture of the mainframe prevent these vulnerable technologies from causing problems with Web-based applications and mainframe-based data? While no vendor has come forward with definitive answers to this question, the use of dual stacks and other isolating/compartmentalizing technologies that have long been part of mainframe architectures could be instrumental.

Lack of solid cost information. A few years ago the answer to the question "How much will it cost me to have a Web site?" was "How much do you have to spend?" There just weren't enough Web sites from which to draw representative figures. Today we have an abundance of statistical information on traditional platform-based sites.

IBM and others claim reduced cost and speed to market of Web-based applications on mainframes, but I have yet to see publicly available figures. Part of the problem here, of course, is that the cost to move to the mainframe will depend largely on the size of the proposed site, its features, the security implementation desired, and whether your existing mainframe will support the additional load. When you're evaluating vendors' cost claims, don't forget to ask these questions:

• Does the vendor's price include maintenance and support services for hardware and software? For what period of time?
• How much training, recruiting and supporting of staff is included in this price? What are the charges when this level is exceeded?
• How will this implementation reduce my operational costs for Web site security? Get the full details on any reduced cost claims. Compare them to the costs of making modifications to your current infrastructure, practices and policies.
• How much will it cost me to retain experienced staff once trained? If the movement to mainframe-based Web servers does become a trend, this could be a significant financial factor.

Difficulty of implementation. There are lots of stories out there about the difficulties of Web-enabling a mainframe. Some are due to the newness of the technology. Whenever a new anything is adopted, there's a lack of information, users with experience, education and tools that would make using the new technology more palatable. Insist on conversations with current implementers to determine the difficulties you may encounter, and weigh this against adopting those with less potential for headaches.

"Security through obscurity" is never enough. Perhaps now there aren't legions of script kiddies or blackhat hackers dedicated to taking the mainframe beast down. But that situation could change as more mainframes are recruited to be Web servers and visibility increases. With millions of Unix- and Windows-based Web servers against mere thousands of mainframed-based Web servers, there's hardly any reward in developing attacks directed at the mainframe. Running native mainframe Web servers may prevent attacks directed at better-known Web servers, but since only very large organizations can afford the initial outlay for a mainframe-based solution, it stands to reason that these sites have something of greater value to protect.

DoS and DDoS. Mainframe-based Web servers are no less vulnerable to denial-of-service (DoS) attacks that use flooding techniques. Superior capacity for transaction handling may have exempted them from some DoSes in the past. Today, however, such attacks are sophisticated and enlist hundreds, thousands and perhaps millions of unsuspecting and unprotected computers to focus distributed denial-of-service (DDoS) attacks on a single site.

Availability of security technologies on other systems. SSL, SSL acceleration cards, SET, Kerberos, cryptographic co-processors and other security algorithms and products are widely available on other platforms. To implement each of these security solutions on any platform may or may not incur additional expense. Kerberos is free in Windows 2000, but is an additional charge on many other platforms. The cost of SSL depends on the way it's implemented, perhaps as a part of an organization's overall Public Key Infrastructure, or merely via the purchase of a single certificate from public certificate authorities. It also depends on whether additional accelerator cards and co-processors are purchased. There are hundreds of variables that apply to making a cost comparison. Before choosing a Web platform, you should capture applicable information.

Lack of unique security features. Many of the mainframe's best security features are available on other platforms as well. What makes the mainframe stand out is its ability to provide these services for sites that need to manage large volumes of transactions and still maintain performance. Most Web sites don't have the large transaction volumes that would justify the cost of a mainframe solution.

Other platforms can manage high performance by scaling out, or using multiple physical servers. The mainframe, by contrast, can add capacity by scaling up—by adding multiple processors. Which solution is most cost-effective for you will depend on the size of the site, the number of transactions, the technology comfort level of the company and its IT staff, and the site purpose and risk factors.

Bottom Line
While there is no proof positive for the mainframe-as-most-secure-platform for Web servers, its history of reliability, availability and security gives large organizations several strong reasons to investigate this opportunity.

Perhaps one of the largest factors may be its relative anonymity. While security through obscurity holds no guarantee, it's still a sensible philosophy. If I wish to avoid destruction via tornado or earthquake, I'll move my operations to geographic areas where these phenomena, for all practical purposes, don't exist. If the existing Web products and technologies I use have known vulnerabilities and are popular targets for attack, then one thing is sure: If I no longer use them, the vulnerability specific to them goes away.

Of course, there's always the chance I'll be obliterated by a tsunami ...