SECURE DESIGN PRINCIPLES: How to Build Stuff Against Attacks

By Ted Harrington

It is almost a daily occurrence in today’s society to read a news story about a major company or government entity becoming the next victim of a cyber attack. The security industry is a massive and rapidly-growing one, awareness about security is ever-increasing, and companies and governments do seem to be investing at least some resources in security. So how does this keep happening?

The answer to this condition is not easily consolidated to a single concept; security is a complex pursuit, and thus so too are the reasons for security breakdowns complex. However, there is an overarching theme driving these security breaches: ineffective adherence to secure design principles.

A principle is a fundamental truth; a secure design principle is one upon which systems are built in order to be resilient against attack.   Secure design principles are well established in the academic and research communities, yet many businesses have difficulty implementing these principles successfully, as is evidenced by the widespread, devastating security breaches that continue to plague businesses today.  Proper implementation of secure design principles, taken in context with business objectives and constraints, significantly reduces vulnerability and mitigates risk.   This paper distinguishes between secure design principles, and those that are commonly confused as such, which are referred to as anti-principles.  Each one of these principles or anti-principles has enough textured nuance to warrant its own whitepaper, so for the sake of brevity, the scope of this article focuses solely on defining the primary principles and anti-principles, in order to provide a contextual overview, combined with some advice on how to implement them; additional reading on each principle herein is recommended.

Secure Design Principles

First, it important to define the primary secure design principles.  Different academic, research, or industry institutions may provide slight variations on this list contained, but the overall consensus about how to build systems resilient against attack is relatively consistent across such communities, and has been established for several decades.  Secure design principles include:

  • Least Privilege.  Allow a user only the absolute minimum access required in order to successfully perform his or her function, and nothing more.
  • Privilege Separation.  Divide privileges such that a user must have multiple privileges in order to perform a larger scale compromise.  This requirement of additional privileges reduces risk.
  • Defense in Depth.  Adopt the assumption that a compromise has already occurred, and architect defenses in a way to make broader scale compromise difficult.  Start by identifying the most valuable assets and build layers of protection emanating outwards from there.
  • Trust Reluctance.  Assume all trusted parties (including users, trusted employees, integrated third parties, etc) are or can become malicious; architect defenses accordingly.
  • Open Design.  Understand that the integrity of system security should not rely on secrecy.
  • Economy of Mechanism.  Simplify, in order to create systems that are easier to build, validate and maintain.
  • Complete Mediation.  Ensure that every attempt to access any resource and/or asset be validated for authorization, every time.
  • Least Common Mechanism.  Understand that shared resources introduce shared compromise, and as such, wherever possible, an organization should reduce or eliminate shared attack surfaces.
  • Psychological Acceptability.  Empathize with the user: if security becomes too intrusive for a user to effectively perform his or her role, the user will circumvent the security controls.  Psychological Acceptability balances security and convenience, as after a certain degree of inconvenience, security will actually be undermined by the user.
  • Fail Secure.  Accept the fact that systems fail, and thus, those who build systems should plan for failure.  In the event of failure, the system should default to a secure state, not an insecure one.
  • Secure the Weakest Link.  Identify the easiest point of compromise.  Just as defenders calculate return on resource investment, so too do adversaries.  Modern adversaries choose the weakest link in the security chain, as the easiest path to system compromise. The weakest link is often a trusted third party solution whose integration does not consider Trust Reluctance, discussed above.
  • Reduce Asset Handling. Provide access to only the smallest number of assets your system needs in order to deliver value, and avoid anything else.  This will reduce the reasons an adversary may want to attack you.
  • Build Security In.  Analyze not only financial investment, but also manpower investment.  It is both more effective and less expensive to build security into each stage of the development process, rather than considering it at the end.  At the same time, it is far more effective to build security into the design than trying to bolt it on at the end.
  • Reassessment Iteration.  Revisit security frequently.  Security is an ongoing process that should be visited at very frequent, regular intervals, in order to keep pace with iterative developments in the attack surface and evolutions in adversary tools and techniques.  Annual reassessments are too infrequent; security should be considered on at least a 6 month basis, and in many cases more frequently.


Given the context of secure design principles, it is important to also consider the range of approaches that are commonly misunderstood as valid security measures, but which actually either do not improve system security or in fact reduce it.  Independent Security Evaluators refers to these as anti-principles.

  • Compliance.  Although commonly perceived as one, compliance is not a security measure.  Compliance only works if the enemy you are trying to thwart is the compliance auditor.  Against any other enemy, compliance does not effectively defend.  Compliance is useful in many ways, but as a security measure it is incomplete because it is an attempt apply a uniform model to a collection of companies who are by definition unique; this means that even a compliant system will have gaps in its security assessment.
  • Complexity.  The inverse to Economy of Mechanism, complexity is the enemy of security.  Additional complexity introduces additional bugs, vulnerabilities and attack surfaces.   Beware of falling into the mindset that because the system has many elements to it, the adversary will not be able to figure it out.  The inverse of that perspective is actually true, that all of those moving pieces actually introduce more ways for adversaries to attack.
  • Security Through Obscurity.  That an adversary may not know where to find an asset or how a system operates does not inherently protect the asset.  This is the inverse of Open Design.
  • Security Through Legality.  Regulation and law do not prevent an attack, nor effectively outline measures to be effective in all cases. Strong provisions and penalties in contracts also do not prevent attack.  The threat of fines or imprisonment do not deter attackers who are beyond the reach of the law.  Each of these are important considerations to include in the overall defense paradigm, but are not the entire solution.
  • Deferral of Risk.  In many industries, vendors often look to their customers to articulate requirements.  Inversely, stakeholders and asset owners often expect their vendor partners to come to the relationship with security already understood, considered, and integrated into their solution. However, security is a shared problem; both sides of the equation need to each pursue the common security mission, and should not push it off entirely to other organizations.

Successfully Implementing Secure Design Principles

Once organizations obtain a strong understanding of secure design principles, it is critical that those organizations then effectively integrate them into their defense paradigm, and verify that that these principles are properly implemented.  Although these principles are ostensibly design-level considerations, they each have applicability at multiple phases, including:

  • Design.  At this stage, organizations consider how to architect defenses with secure design principles in mind.  Emphasis is placed on analyzing why a given system exists, for what business purpose, for which users, and thus which assets will be accessible via the system.  Decisions are then made that best integrate the relevant secure design principles into system design.
  • Implementation.  At this stage, organizations now attempt to deploy the design decisions made, into a production system.  Organizations assess the logistical and other real-world considerations that need to be considered in order to successful deploy the system in a manner that is effective in continuing to integrate secure design principles.
  • Maintenance.  At this stage, organizations now determine how to ensure that secure design principles continue to be effectively baked into the solution throughout the iterative development of the system over time.  Adversaries will invent new techniques, previously unknown vulnerabilities in widely used components will be discovered, and the constant development of new features will all combine to continually evolve the attack surface.  Security is an ongoing process that never concludes, and as such, this stage is defined by continual reevaluation of how to best maintain a resilient security posture.

Through the course of all three of these generalized phases, most organizations are already engaging third party security experts to assist with verifying and validating that the secure design principles are effectively considered.  It is important to note, however, that methodology matters: such assessments must be defined by rigorous, manual, white box security assessment, and should avoid falling into the trap of relying on automated scanning, black box penetration testing, or anti-principles such as Compliance, Complexity, Security Through Obscurity, Security Through Legality, or Deferral of Risk.

By adequately considering the underlying secure design principles, organizations of all sizes and financial resources are able to build resilient systems, and adapt the defense posture to keep up with an ever-evolving adversary.

About Ted Harrington

Ted Harrington drives thought leadership initiatives for Independent Security Evaluators (ISE). He has been named both 40 Under 40 (SD Metro) and Executive of the Year (American Business Awards), and organizes popular hacking concept IoT Village.

More About Ted

ITSPmagazine is, and will always be, a free publication. 

Our mission is to raise awareness for cybersecurity by making it understandable, accessible, and part of everyone’s everyday life.  

If you liked this post and wish to contribute to our mission, consider visiting our support page.