Java has evolved more quickly than any other computer language in widespread use. As the language itself has evolved, so, too, has the security model. Here are some lessons we have learned as we have watched Java's approach to security change. Type safety alone is not security. Chapter 1, "Mobile Code and Security: Why Java Security Is Important," and Chapter 2, "The Base Java Security Model: The Original Applet Sandbox," explain why type safety is critical to Java's security model. Chapter 5, "Attack Applets: Exploiting Holes in the Security Model," shows what happens when type safety is compromised. Java security is much more than type safety, however. Think of type safety as the foundation of a complete Java security solution. The foundation is essential, but much needs to be built on top of the foundation to make a useful building. Real security is more difficult than it sounds. Securing a system as complex as Java (not to mention systems built on top of Java) is a nontrivial undertaking. Do not let slick marketing convince you that building a secure system is easy. It isn't. Java provides a powerful set of tools that can help you create a secure system, but simply using the tools is no guarantee of success. You must use the tools wisely and closely scrutinize your system from a security perspective. If ever there was a time to practice solid software engineering, design, and implementation of secure systems, it is now. It is impossible to separate implementation errors from design problems. Recurrent security problems are a clue that something is wrong with the way in which a system is being developed. These problems are introduced at many different stages of system design and implementation. In today's fast-paced consumerware market, security assurance is often among the first things to go. Specifications, if they exist, are vague. Sometimes they are silent on critical points, leaving the implementor to play a guessing game. What may seem to be a simple security bug often indicates deeper problems in the development process. New features introduce new security holes. Java has grown by leaps and bounds. With each major release of Java, a number of new serious security holes have been discovered. This is not surprising. It is exceptionally difficult to get everything exactly right in a complex system, and security demands nothing less. Java 2 introduces many powerful new features into Java. Security holes are likely to be discovered in the implementation and design of these features. New classes of attacks keep appearing. Security attacks can be likened to rushing floodwater; sometimes the places they flow are surprising. It is not possible to anticipate all future security attacks, mostly because security attacks break systems in novel ways. Do not rely on using only historical data for security analysis and protection. There is much more to real security expertise than being able to recount stories of past compromises. Humans are an essential element to consider. No system as complex as the Java platform can be used without lots of human intervention. Java 2 provides a perfect example of this fact. Without proper policy creation and management, trust-based security models are exceptionally dangerous. Proper use of advanced technologies requires forethought, planning, and careful management. A big part of this management is anticipating what real users of a system are likely to do, as well as what real attackers are likely to do. These lessons are relevant to each and every security-critical, Java-based system. Creating a secure system is hard work, but it is quite possible to come up with a system that will have reasonable security in the trenches and address a majority of risks as well.
Chapter... Preface -- 1 -- 2 -- 3 -- 4 -- 5 -- 6 -- 7 -- 8 -- 9 -- A -- B -- C -- Refs
Copyright ©1999 Gary McGraw and Edward Felten. |
