APPENDIX I

PRINCIPLES OF GOOD DESIGN

Prefer broad solutions to point solutions — Prefer broad security solutions which work across the enterprise, multiple applications, multiple resources, and against multiple hazards to those which are limited to or specific to one of these. Such practices are almost always more efficient than a collection of mechanisms that are specific to applications, resources, or hazards.

Prefer end-to-end solutions to point-by-point solutions — Similarly, prefer encryption-based end-to-end security solutions that are independent of the network. The more sensitive the application and the more hostile the network, the greater this preference. Such solutions are more robust and more efficient than those that attempt to identify and fix all of the vulnerabilities between the ends of the path.

Design top-down, implement bottom up — Design by functional decomposition and successive refinement. Implement by composition from the bottom. Prefer early deployment of those services and servers which will be required over the long haul.

Do it right the first time — When building infrastructure, build for the ages. Do it right the first time. This strategy is more effective and more efficient than the “assess and patch” strategy that has been the approach to security in the past.

Prefer planning to fixing — Similarly, work by plan and design rather than by experimentation. Necessary experimentation should be carefully identified, contained, and controlled.

Prefer long term to short — Applications are becoming more sensitive and the environment more hostile. While one may consent to a plan that permits an early deployment of an application with a plan to deploy the agreed upon security function by a date certain, do not take a “wait and see” approach.

Justify across the enterprise and time — Security measures must be justified across the entire enterprise and across the life of the application or the mechanism. By definition, security prefers predictable, regular, prevention costs to unpredictable, irregular, remedial costs. They should be justified across a time frame that is consistent with the normal frequency of the events that it addresses. Security measures are relatively easy to justify in this manner and difficult to justify locally or in the short term. In justifying security measures, weight should be given to the fact that applications are becoming more sensitive, more interoperable, and more important, and that the environment in which they operate is becoming less reliable and more hostile.

Provide economy of safe use — Using the system safely should require as little user effort as possible. For example, a user should have to log on only once per enterprise, per workstation, per day.

Provide consistent presentation and appearance — Security should look the same across the enterprise, i.e., applications, systems, and platforms.

Make control predictable and intuitive — Systems should be supportive. They should encapsulate the special knowledge required by the manager and user to operate them. They should make this information available to the manager and user at the time of use.

Provide ease of safe use — Design in such a way that it is easy to do the right thing. Penalties should be associated with doing the wrong thing (e.g., economy of log-on, user should have to log on only once per workstation, per enterprise, per day.)

Prefer mechanisms that are obvious as to their intent — Avoid mechanisms which are complex or obscure, which might cause error, or be used to conceal malice. For example, prefer online transactions, EDI, secure formatted E-mail, formatted E-mail, E-mail, and file transfer in that order. The online transaction is always obvious and predictable; for a given set of inputs one can predict the outputs. While the intent of a file transfer may be obvious, it is not necessarily so.

Encapsulate necessary special knowledge — Necessary special knowledge should be included in documentation or programs.

Prefer simplicity; hide complexity — For example, all other things being equal, simple mechanisms should be preferred to complex ones. Prefer a single mechanism to two, a single instance of a mechanism should be preferred to multiple ones. For example, prefer a single appearance of administration, like CA Unicenter Star to the appearance of all the systems which may be hidden by it. Similarly, prefer a single point of administration such as SAM or RAS to Unicenter Star.

Place controls close to the resource — As a rule and all other things being equal, controls should be as close to the resource as possible. The closer to the resource, the more reliable the control, the more resistant to interference, and the more resistant to bypass. Controls should be server-based, rather than client-based.

Place operation of the control as close as possible to where the knowledge is and where the effect can be observed — For example, prefer controls operated by the owner of the resource, the manager of the group, the manager of the system, and the manager of the user rather than by a surrogate such as a security administrator. While a surrogate has the necessary special knowledge to operate the control, he knows less about the intent and the effect of the control. He cannot observe the effect and take corrective action. Surrogates are often compensation for a missing, complex, or poorly designed control.

Prefer localized control and data — As a general rule and all other things being equal, prefer solutions that place reliance on as few controls in as few places as possible. Not only are such solutions more effective and efficient but they are also more easily apprehended, comprehended, and demonstrated. Distribute function and data as required or indicated for performance, reliability, availability, and use or control.