Common System Design Flaws

I recently came upon https://tinyurl.com/SystemDesignFlaws It was written as a chapter of the Handbook of Information Security 2001.  I offer the link to any who would like to see the whole paper but recap the flaws and the recommendations for avoiding them here.

The flaws covered by name are:

• Complexity

• Incomplete Parameter Checking

• Incomplete Error Handling

• Ineffective Binding

• Inadequate Granularity of Controls

• Gratuitous Functionality

• Escape Mechanisms

• Excessive Privilege

• Failure to a Privileged State

• Unsafe Defaults

• Excessive Reliance on Application Controls

• Others

Examples and illustrations of these common flaws are discussed at length in the paper.  

The following recommendation should be considered when crafting and staging applications. By adhering to these recommendations the programmer and the application manager may avoid many of the errors outlined in this chapter.

• Enforce all restrictions upon which you rely. 

• Check and restrict all input parameters to the intended length and code type. 

• Prefer short and simple programs and program modules. 

• Prefer programs with only one entry point at the top or beginning and only one exit at the bottom or end. 

• Prefer reliance upon well-tested common routines for both parameter checking and error correction. Consider the use of routines supplied with the database client. Parameter checking and error correcting code is difficult to design, write, and test. It is best assigned to master programmers. 

• Fail applications to the safest possible state. Prefer failing multi-user applications to a halt or to logon rather than to a new instance of the application or the environment (e.g., operating system). 

• Limit applications to the least possible privileges. Prefer the privileges of the user. Otherwise, use a limited profile created and used only for the purpose. Never grant an application system-wide privileges. (Since the programmer cannot anticipate the environment in which the application may run 

and the system manager may not understand the risks, exceptions to this rule are extremely dangerous.)

• Bind applications end-to-end to resist control bypass. Prefer trusted single system environment. Otherwise use a trusted path (e.g., dedicated local connection, end-to-end encryption, or a carefully crafted combination of the two).  Include in an application user’s privileges only that functionality that is essential to their use of the application. Consider dividing the application into multiple objects requiring separate authorization so as to facilitate involving multiple users in sensitive duties.

• Controls should default to safe settings. Where the controls are complex or interact in subtle ways, provide scripts (“wizards”), or profiles.

• Prefer localized controls close to the data, e.g., prefer file system to application, database manager to file system.  Prefer authentication of users (or using processes) close to the user (e.g., on the mobile client.)

• Use cryptographic techniques (e.g.,digital signatures) to verify the integrity of the code and to resist bypass of the controls. 

• Prefer applications and other programs from known and trusted sources in tamper-evident packaging.