Secure Design

By embedding security into the very foundation of system architecture and workflows, organizations can proactively identify and mitigate risks, reducing vulnerabilities and minimizing the impact of potential attacks.

Building secure applications starts long before a single line of code is written; it begins at the design stage. The following principles guide teams in making informed, security-conscious decisions throughout the application development lifecycle:

  • Defense in Depth: Security based on having multiple layers of defense that aim to eliminate or minimize vulnerable points, even if there are already other countermeasures in different layers

  • Fail Safe Defaults: An application should preserve the availability, integrity, and confidentiality of information even when there are failures, and be able to revert to a previous safe state

  • Least Privilege: Every user or process should have only the minimal permissions needed to perform their tasks. If necessary, elevated privileges should be assigned only temporarily

  • Separation of Duties: Responsibilities should be divided so that no single individual has control over all parts of a critical process or workflow, establishing specific roles and permissions for distinct tasks

  • Economy of Mechanism: Keep the architecture and processes as simple as possible, as simpler designs are easier to secure and maintain

  • Complete Mediation: Never assume a previous authorization is still valid. Every access request should be revalidated, even if the user has already authenticated

  • Open Design: Security should not depend on the secrecy of the design or implementation. Obscurity or hiding details is not a reliable form of protection

  • Psychological Acceptability: Security features should be user-friendly and not overly intrusive. The more natural and transparent their use, the more effective they will be

  • Weakest Link: An application’s security is defined by its weakest component. A single vulnerability in any one part can compromise the entire system

  • Leveraging Existing Components: If there is already a tool, library, or component that solves a problem securely, use it, don’t reinvent the wheel or add unnecessary complexity

  • Secure by Default: Applications should be secure as soon as they are deployed, with minimum exposure to risk

  • Protect Sensitive Data: Sensitive information must be protected at all times, when stored, transmitted across networks, or displayed to users

  • Trace and Log: All interactions with sensitive resources should be logged, including relevant audit events, ensuring traceability, supporting non-repudiation, and providing visibility in case of incidents

Last updated