Trustworthy Design

Tags:
Categories:

Security Architecture and Design Principles

The Three Security Elements and Security Design Principles

  • Integrity
  • Availability
  • Confidentiality

Open Design Principle

Open Design

  • The design should not be secret; open designs are more secure.
  • Security does not rely on secrecy.

Fail-Safe Defaults Principle

Fail-safe defaults

  • Access decisions are based on “permit” rather than “deny”.
  • By default, access is denied; protection mechanisms merely identify the subset of allowed actions.
  • Safe failure: any complex system must have an emergency safety mechanism after functional failure; also be careful with error messages and logs to prevent information leakage.
  • Safe by default: in its initial state, the default configuration is secure by providing the least services and systems necessary for maximal safety.

Separation of Privilege Principle

Separation of Privilege

  • A protection mechanism that requires two keys to unlock is more robust and flexible than one that uses only a single key.
  • Goals of privilege separation
  • Prevent conflicts of interest and individual abuse of power
  • Break down a critical privilege into several smaller ones, making the protected object harder to obtain illegally and therefore more secure.
  • Separate responsibilities and authority between different processes

The system can pre-define three roles whose accounts and privileges are independent of one another, thereby separating powers and responsibilities:

  • System Administrator: responsible for day-to-day user management and configuration.
  • Security Administrator: responsible for activating or deactivating user accounts and security configurations.
  • Security Auditor: responsible for auditing the logs of the two roles above and has the right to export these logs, ensuring all system-user actions remain traceable.

Least Privilege Principle

Least Privilege

  • Every user and every program in a system should operate with the smallest set of privileges necessary to accomplish its work.
  • Ensure that applications run at the lowest possible privilege level.
  • When operating various programs such as databases or web servers, make sure they run under or connect via accounts that have the minimal required privileges, not system-level accounts.
  • When creating a new account, assign it a role that grants the least privileges by default.

Economy of Mechanism Principle

Economy of Mechanism

  • Keep the system design and its code as simple and concise as possible.
  • The more complex the software design, the higher the probability of bugs; if the design is kept elegant, the risk of security issues is reduced.
  • Remove unnecessary redundant code and functional modules; retaining them only increases the attack surface.
  • Design reusable components to reduce redundancy.
  • Economical use: keep things simple, elegant, and modular.
  • Avoid over-engineering.

Least Common Mechanism Principle

Least Common Mechanism

  • Avoid scenarios where a resource is shared by many entities as much as possible; the number of sharers and their degree of sharing should be minimized.
  • Shared objects provide potential channels for unwanted information flow and inadvertent interactions; try to avoid shared resources.
  • If one or more entities dislike the service provided by a shared mechanism, they may choose not to use it, preventing indirect attacks from other entities’ bugs.
  • Minimize shared memory
  • Minimize port binding
  • Reduce connections to defend against DoS attacks

Complete Mediation Principle

Complete Mediation

  • This principle demands that every access to every object be checked for authorization each time it occurs.
  • Whenever a subject attempts to access an object, the system must verify—every single time—that the subject holds the necessary permission.
  • Have owners of the resource make the access-control decision whenever possible. For example, a server backend rather than the frontend should check a URL’s permissions.
  • Pay special attention to caching and its checks; one cannot guarantee that cached information has never been tampered with by an attacker—e.g., DNS cache poisoning.

Psychological Acceptability Principle

Psychological Acceptability

  • Security mechanisms may impose additional burdens on users, but such burdens must be minimal and justified.
  • Security mechanisms should be as user-friendly as possible, facilitating users’ interaction and understanding of the system.
  • If the configuration interface is overly complicated, system administrators may accidentally set it wrong and actually decrease security.
  • This principle is generally related to human-computer interaction and user-centered design (UCD) interfaces.

Defense in Depth Principle

Defense in Depth

Defense in Depth is a highly comprehensive defensive principle. It generally requires system architects to integrate and apply various other security design principles, employ multiple and multi-layered security verification mechanisms, and—from a high-level architectural perspective—focus on system-wide defensive strategies, rather than relying on a single security mechanism.