Considering all the benefits of Web-based transaction processing, why hasn't Java transformed the Web into a gigantic, global marketplace? What's the hold up? The answer can be summed up in two words: network security.

The Risk of Executable Content

Allowing executable content to move across a network in order to be executed on a user's desktop without direct intervention or monitoring by the user or the system administrator is a serious risk. An "executable-content enabled" browser can open the door to all sorts of network intruders. Executable content can wreak havoc with business system security and integrity when either hostile or buggy Internet programs penetrate a business's network and run amok. Hostile applets are written by hackers deliberately, while buggy applets may be an inadvertent breach of security. The number of companies concerned with the implications of not protecting their corporate networks against such attacks and potential problems continues to grow. Yet, in spite of the vast dangers, the number of companies seeking to capitalize on the power of executable content also grows because of the allure of transaction processing and the potential for competitive gain.

Given the risk, is it possible for business to use executable content safely? The answer to this question lies in the purview of system and network administrators, who have employed several methods to manage the security risks.

Managing the Security Risk

Defense by Abstinence

The first method, blocking executable content at the firewall, is an obvious, effective method of minimizing the risk of allowing executable content use on your network. However, banning executable content from internal networks poses several problems. Organizations are being asked to provide more functionality for their users rather than less. To keep Internet Java applets forever outside the company's gates is to exile a potentially useful tool. As an all-or-nothing solution, it prevents network invasion, but it also kills the prospect of business-to-business transactions across the network.

A modification of the absolute banning of executable content from the enterprise is to allow separate firewall-protected groups within the company to implement different security policies. Several firewall vendors provide for central management of firewall policies, tools which can be used to manage executable content on the enterprise, division, or department levels. For example, a corporation might ban executable content from the finance department but not from the sales department. A firewall erected between the two organizations would keep them effectively segregated. Thus, the finance department is secure all around, while the sales department, safely within its own parameters, can take advantage of the power of executable content. The problem is that the benefits of executable content are not shared within the organization. It's a tradeoff: benefits in terms of potential transaction processing or benefits in terms of security.

As more corporations choose to deploy mission-critical, enterprise-wide applications using executable content techniques, complete banning is clearly not a long-term solution. The enterprise, to truly function as an enterprise, cannot be chopped into functionally divergent pieces by firewalls.

Sandboxing

The second method is the sandboxing technique. Netscape and Microsoft have enabled their browsers with a "sandboxing" capability, which puts constraints on applet access privileges. The browser's sandbox, where the code must be executed, prevents the executable content from accessing any critical devices in the computer such as the memory, disk drive, or other network links. The design of Java directly facilitates such an approach.

This method is effective only as long as there is no exchange of data between the executable content and the user's computer, which of course limits the usefulness of the executable content. Essentially, only those applications that do not require any disk or network access can be effectively secured within a sandbox. Legitimate applications from a trusted source, however, may often require the ability to write to the local disk or to make multiple connections to computers on the network. For example, an application may need to write data to a temporary directory to preserve the state of the application. Similarly, applications often need to connect to multiple servers in order to exchange data. If the application is running within the browser's Java sandbox, this is not allowed.

Proponents of the sandboxing technique propose to solve this problem by providing digital signatures with applications to verify that they come from a trusted source. In this way, only mobile code with the appropriate signature would be given the appropriate access for that application. One can discriminate among different applications, allowing limited disk and resource access to some and more extensive disk and resource access to others. Unfortunately, digital signatures only identify the author of the applet. They cannot indicate the trustworthiness of the applet. Recent reports have surfaced regarding "spoofed" signatures that can effectively side-step such security mechanisms and therefore potentially give buggy applets unreasonable access to resources.

The sandboxing technique also has limitations in terms of scalability and manageability. A sandbox must be maintained on every browser desktop that is to run executable content. For the sandboxing technique to be effective, all parts of the organization should be using the same version of the sandbox. This is a big challenge. Many organizations run multiple vendor's browers and multiple versions of those browsers. It is also difficult to centrally control the browers, as the promised tools for this management task are vendor and version specific and won't be a solution for the typical heterogeneous browser environment. System administrators will thus be forced to implement security policies desktop by desktop. Moreover, security imposed at the desktop may be easily compromised by the end user. Most desktop operating systems provide little or no means for preventing a user from changing settings determined by the administrator. Managing security at the desktop level can be a nightmare. Also, the sandbox implementation must be correct. As browsers evolve so quickly, new bugs keep creeping in. There is no second line of defense.

Byte Code Scanning

The third method is to use byte code scanning. Byte code scanning programs analyze executable content, and, if it meets the criteria set forth by the administrator, they allow the code to pass through to the internal network. The products currently available for byte code scanning of Java applets and applications attempt to assure that the byte codes coming through the network conform to a legitimate Java application by comparing the incoming applets to a database of known hostile applets. They also attempt to determine if the executable content could do something that is disallowed by the security policy.

For example, the byte code scanning could see if there were APIs called to write to disk. If so, the scanning prevents the applet from passing through.

One advantage of byte code scanning is that it adds another layer to the security model, instead of simply allowing the mobile code to travel unimpeded and unscrutinized through an organization. Even so, byte code scanning does not provide an adequate solution to the security problem. It may prevent blatantly hostile applets from entering the corporate network, but it cannot ensure against a slightly mutated hostile applet (or a self-mutating hostile applet) that has not yet been identified in the "database of known hostile applets."

Checking every piece of code that comes through the network takes a great deal of time and CPU resources. Therefore, once the executable content is checked, a hash function such as the MD5 algorithm is applied to the code. The output of the hash function serves as a tracking tag, and is used to save time. When another piece of executable code with the same hash code comes through the firewall, it is allowed to pass.

There are two current types of byte code scanning techniques; desktop versions, and server versions. In terms of manageability, the byte code scanning technique at the server Internet gateway gives some level of central control. Because the executable content is checked on a server dedicated to the task, system administrators can manage security at the firewall level, rather than at the desktop level as with sandboxing. The desktop version of the byte code scanners is a constant challenge to administer, with reinstallation required with each browser version update. However, given the growing list of hostile applets, both the server and the desktop versions will require the latest version of the byte code scanner software to maintain the most recent database version of "known hostile applets." As with virus checkers, a continual game of catch up is played. One bothersome point about this technique is that it goes against one of the basic principles of network security: "That which is not specifically allowed is denied." Internet executable content is allowed to enter the enterprise under the assumption that it has been examined against an "up-to-date database of known hostile applets."

Redirecting

The fourth method is a new approach that combines the advantages of abstinence and sandboxing. The mobile code is redirected at the firewall to a specially configured bastion host, which provides a safe environment for executing the code outside of an organization's firewall. The bastion host runs a monitored JVM and establishes a connection to the requesting browser on the internal network. The twist is that the connection from the internal browser proxy applet establishes a connection to the bastion host. That connection is based solely on the exchange of data-only graphics commands. In other words, a local trusted proxy applet gets substituted for the downloaded applet. The user therefore is able to use the Internet java applet on the browser while it is actually executing on the bastion host that remains on the outside of the company's firewall, typically in a company's so-called DMZ.

Since no Internet Java-based executable content is allowed to pass through the firewall, there is no way for an intruder to attack the company intranet using Internet Java. It is theoretically possible, however, to attack the bastion host itself. This can be prevented by leveraging the robust OS features and hardening the server. This includes allowing the machine to run only essential servers. Finger, SMTP, the R-commands and TFTP therefore should not be started. The bastion host is also deployed on the less secure side of the firewall, that is, outside of a company's internal network in the DMZ. Using this method, an organization can be secure, yet still be allowed to use the same Java applications that are available via the Internet.

In terms of both scalability and manageability, redirecting is the optimal solution. Unlike sandboxing, this technique can be controlled from a centralized position. Unlike byte code scanning, this technique does not require constantly updating the version releases. And unlike abstinence, this technique permits an enterprise to begin to realize the power of dynamic executable content.

Summary

The future of the Internet may indeed lie with executable content technology. By way of preparation, system administrators should evaluate the various ways to control Java applets and similar technologies that may transform the Web from a static medium into a virtual marketplace. Maintaining network security is the key to realizing the benefits of online services and business-to-business transactions.

To successfully and safely deploy Internet Java applets throughout the extended enterprise, system administrators not only need to defend internal networks from rogue or buggy applets, but also they should:

Of the four main techniques for securing Java-based executable content within the enterprise, only one satisfies all the criteria listed above. Total abstinence, or banning Internet Java from the corporate network, is effective, but very limiting. Sandboxing opens the door to the power of executable content, but also requires a large amount of administration at the desktop. Scalability and manageability are significant drawbacks to this method. Byte code scanning is a partial solution, potentially enabling companies to reap the benefits of Java applets that are deemed safe and allowed through by the system, but also potentially compromising security because it is an imperfect filter.

The fourth technique, isolating Internet Java on an external execution host, combines the strengths of the first and second methods to satisfy the criteria for security. It executes Internet Java outside the firewall, thus maintaining security, while using proxy applets to bring the dynamic, interactive processing potential of the Web into organizations. By moving the execution of Java applets and their security enforcement away from end users' browsers, the external execution host places these functions under the centralized control of system administrators, who can equip that host with a range of applet monitoring and automatic load-balancing capabilities. When used in conjunction with cryptographic signatures that give applets different security clearances under different conditions, this technique enables security policies to be tailored to different applications.

This technique may well be the path to a bright future for executable content. One thing is certain: if the executable content revolution materializes, you can ensure that your business can securely take advantage of its benefits.

About the Author

Todd Radermacher and Peter Kocks are members of the development team at Digitivity, Inc., a Java deployment consulting firm based in Los Altos, California, and Cambridge, England. They can be reached at (415) 947-1900 or www.digitivity.com.