Security is one of the most important design criteria for developers of internetworking applications. Java has much to offer, but there are no guarantees
As a statement about reputation and integrity, this is certainly true. As a statement about security, it leaves much to be desired.
In the rough and tumble world of the Internet, a more appropriate admonition may be “qui desiderat pacem praeparet bellum,” or “let him who wants peace prepare for war.” Whatever the industry or architecture, developers of internetworking applications list security as one of their top design criteria. The only certain thing about the Internet (and perhaps the world at large) is that the security of everything could be better.
“Good enough” is a concept familiar to most people, especially engineering managers. Ultimately, products must be shipped, applications deployed, and services delivered. Decision criteria about what constitutes “good enough” vary by culture, industry, organization, and individual. The goal of manufacturing processes may be six sigma, while for developers of fault tolerant systems, the goal may be 99.99999 percent up-time. But there is no agreed standard for what “security” means in network computing beyond the following: If your system goes down, is corrupted, or is otherwise violated, it is an annoyance. If my system goes down, is corrupted, or is otherwise violated, it is a catastrophe.
Java was expressly designed to make security an integral part of the development environment. In other areas there are certainly benchmarks: the number of encryption bits used, for example. However, most companies seem to view security violations as a tax on commerce. Some level of tax is acceptable, some is not. In the retail industry, businesses accept a tax on commerce in the form of shoplifting and theft. The banking industry accepts some level of loss from credit card fraud. The rule seems to be the following: When the cost of securing goods, information, or transactions seems asymptotic, accept loss over investment. This is certainly a reasonable strategy when measurements are precise. But in many industries, precision is hard to come by.
Reliability and quality have known measurement criteria. For reliability, the criteria can simply be the sum of downtime divided by desired up-time. As a simple estimate at the systems level, this can be the product of each component’s mean-time-between-failure. Quality criteria typically could be considered defects divided by total production. In most industries, however, while there is a notion of acceptable loss, there is no strict definition.
For software developers the notion of acceptable loss (or good enough) is a slippery slope. Software quality typically is defined as total reported bugs, or reported bugs divided by lines of code. However, some bugs clearly are more expensive than others. The most expensive often are not found until after the fact.
Whatever the willingness of companies to accept loss, developers must constantly seek to deliver totally secure code. Compromises can be made at the systems level but not at the component level. Few systems are completely secure, and since it is difficult to prove a negative, it may be impossible to prove that a system has never been tampered with.
Security and Java
Java has much to add in the way of security, and any diversions from the inherent security mechanisms should be treated seriously. Here security and flexibility compete for the developer’s attention. Developers must understand the audience they are targeting with their software. Audiences for internetworking applications fall somewhere along a spectrum between two poles: “saints” and “terrorists.” Many developers design for the mid-point on this curve — “consenting adults” — but this is often a mistake.
The design center for Microsoft’s Authenticode, for example, is somewhere around this mid-point. applications written in Java, however, have the potential to move down the continuum and protect against the terrorist community, or at least the “near terrorist community.”
Despite accepted notions of acceptable loss, security may end up being the principal benefit of Java as an execution environment. The current language and runtime environment already provide a greater inherent level of security than most others do. Establishing a design center for applications is an uncertain process, and a rude awakening awaits those who miss the mark. Java makes these decisions easier, because it makes implementing security easier and more straightforward.
Hostile is a relative term
Most security experts make distinctions between levels of software hostility. McGraw and Felton, in their book Java Security (see Resources for a full citation), distinguish between attack and malicious applets. Attack applets are designed to circumvent Java’s native security mechanisms and perform a serious negative action on the client device (corrupt data, infect it with a virus, or reveal confidential information to the outside world). Malicious applets attack the client machine by denying service, invading privacy, or simply providing some level of annoyance.
These distinctions are useful but somewhat artificial. Take denial of service, for example. In most cases this is simply an annoyance; in others, it is pathological. A recent news item illustrates the point.
In early August, an investor in Norfolk, VA, alleged that E*Trade (a popular broker on the World Wide Web) cost him 0,000 by preventing him from cancelling an online stock trade. The investor claimed that E*Trade’s Web site was so slow as to constitute a denial of service at a critical moment in his investment process. His complaint focused on the performance of the E*Trade Web site, but the lesson is a clear one: Behaviors that are considered inconvenient by some are critical to others.
Imagine, if you will, a malicious applet whose sole mission is to hog systems resources on the client for some period of time. In most cases this is an annoyance — a simple and fairly benign hack. For electronic traders, however, it represents a potential class-action lawsuit against an unwary broker. Indeed, even the rumor of a slow or missed transaction can have severe implications in the financial markets. The National Association of Security Dealers (the organization responsible for the NASDAQ market) has warned that unprincipled stock manipulators have used online investment forums and bulletin boards to affect stock prices.
Simply delaying access to a critical Web site has the potential to cost users thousands or millions of dollars in mis-timed trades. The question is cost whom — the electronic broker or the investor? When a malicious applet denies or slows access to critical medical information at a hospital, the damage has the potential to be inestimably greater than a delayed stock trade.
In the traditional client/server world where the network is known and manageable, these problems are serious. As applications scale across unknown Internet topologies, the situation gets more dangerous and the losses potentially more catastrophic.
What to do
Regardless of any company’s view of acceptable loss, developers are advised to invest both thought and time in security. Here are two good rules to follow:
- Select a level of security that is greater than that required to achieve the company’s view of acceptable risk.
- Use only those technologies that provide a flexible but secure operating environment. Tradeoffs about flexibility and security should be yours to make, not an imposition of the language or execution environment.
Java has much to offer developers in authentication, secure transmissions, and management of executable content. Still, the security of any application is the product of the security of each of its components. It is the developer’s responsibility to maximize the value of this product whenever possible.
Conclusion
Security is an important but often overlooked issue in benign and hostile environments alike. In writing internetworking applications, err on the side of security over flexibility. The benefits may not be apparent for a long time, but the investment will be a good one. Exploit all of Java’s inherent security mechanisms and “permitte divis cetera” — leave the rest to the gods.
