Principles provide the high level guidelines for a system.
Patterns can be applied to implement these principles and allow use of known good solutions for common problems.
Some of the earliest secure software design principles were proposed by Saltzer in the 1970's:
|Economy of mechanism||Keep the design as simple and small as possible|
|Fail-safe defaults||Base access decisions on permission rather than exclusion|
|Complete mediation||Every access to every object must be checked for authority|
|Open design||The design should not be secret|
|Separation of privilege||Where feasible, a protection mechanism that requires two keys to unlock it is more robust and flexible than one that allows access to the presenter of only a single key|
|Least privilege||Every program and every user of the system should operate using the least set of privileges necessary to complete the jobMinimize the amount of mechanism common to more than one user and depended on by all users|
|Least common mechanism||Minimize the amount of mechanism common to more than one user and depended on by all users|
|Psychological acceptability||It is essential that the human interface be designed for ease of use, so that users routinely and automatically apply the protection mechanisms correctly|
|Work factor||Compare the cost of circumventing the mechanism with the resources of a potential attacker|
|Compromise recording||It is sometimes suggested that mechanisms that reliably record that a compromise of information has occurred can be used in place of more elaborate mechanisms that completely prevent loss|
Minimize the footprint of sensitive data - in time and space
1.1 How long or how often the Sensitive data exists
1.2 Where the sensitive data exists or flows - the code or interfaces that touch the sensitive data.
SOLID is an acronym for the first 5 principles of object-oriented design:
|SRP The Single Responsibility Principle||Keep the design as simple and small as possible|
|OCP The Open Closed Principle||you should be able to extend a class's behavior, without modifying it|
|LSP The Liskov Substitution Principle||derived classes must be substitutable for their base classes|
|ISP The Interface Segregation Principle||make fine grained interfaces that are client specific|
|DIP The Dependency Inversion Principle||depend on abstractions not on concrete implementations|
"Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice.” Christopher Alexander
The term "design pattern" is often used to refer to any pattern which addresses issues of software architecture, design, or programming implementation.
Secure Design Patterns gives the following defincitions.
|Architecture Pattern||Expresses a fundamental structural organization or schema for software systems. It provides a set of predefined subsystems, specifies their responsibilities, and includes rules and guidelines for organizing the relationships between them.||PrivSep (Privilege Separation)|
|Design Patterns||Provides a scheme for refining the subsystems or components of a software system, or the relationships between them. It describes a commonly recurring structure of communicating components that solves a general design problem within a particular context.||Secure Factory|
|Implementation Pattern||Implementation-level patterns address low-level security issues. Patterns in this class are usually applicable to the implementation of specific functions or methods in the system. Implementation-level patterns address the same problem set addressed by the CERT Secure Coding Standards [CERT 2009a] and are often linked to a corresponding secure coding guideline||Clear Sensitive Information|
Architectural-level patterns focus on the high-level allocation of responsibilities between different components of the system and define the interaction between those high-level components.
SEI Secure Architecture Patterns are as follows:
|Architecture Pattern Name||Details|
|Distrustful Decomposition (aka Privilege reduction)||Move separate functions into mutually untrusting programs, thereby reducing the • attack surface of the individual programs that make up the system • functionality and data exposed to an attacker if one of the mutually untrusting programs is compromised|
|PrivSep (Privilege Separation)||Reduce the amount of code that runs with special privilege without affecting or limiting the functionality of the program. The PrivSep pattern is a more specific instance of the Distrustful Decomposition pattern.|
|Defer to Kernel||Clearly separate functionality that requires elevated privileges from functionality that does not require elevated privileges and to take advantage of existing user verification functionality available at the kernel level. Using existing user verification kernel functionality leverages the kernel’s established role in arbitrating security decisions rather than reinventing the means to arbitrate security decisions at the user level|
One of the better known set of Design Patterns for Security is SEI Secure Design Patterns:
SEI Secure Design Patterns defines the following Secure Design Patterns: