Newsletter sign-up

View all newsletters

Sign up for our technology specific newsletters.

Enterprise Java

Email Address:

Security is in the eye of the beholder

Security is one of the most important design criteria for developers of internetworking applications. Java has much to offer, but there are no guarantees

By William Blundon, JavaWorld.com, 09/01/97

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.

 

About Us | Advertise | Contact Us | Terms of Service/Privacy

Copyright, 2006-2008 Network World, Inc. All rights reserved.