CDSA

M&E Journal: Secure Design Principles

By Ted Harrington, Executive Partner, Independent Security Evaluators (ISE) –

First, it is important to define the primary secure design principles. Different academic, research or industry institutions may provide slight variations on this list, but the 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 to successfully perform his or her function, and nothing more.

Privilege separation. Divide privileges such that a user must have multiple privileges 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, 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 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 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, 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 six-month basis, and in many cases more frequently.

Anti-principles

Screen Shot 2017-07-11 at 12.55.49 PM 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 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 to apply a uniform model to a collection of companies that are 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 true, that all of those moving pieces 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 to successfully 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 can build resilient systems, and adapt the defense posture to keep up with an ever-evolving adversary.

Click here to translate this article
Click here to download the complete .PDF version of this article
Click here to download the entire Spring 2017 M&E Journal