Simplicity

From The Secure Arc Wiki

Jump to: navigation, search

Contents

Assertion

Minimise the complexity and therefore potential points of failure, security breaches and obscurity of the system

Rationale

The more moving parts in a system, the more the system is exposed to bugs, misconfiguration, security vulnerabilities and the costs associated with a lack of understanding of how security is and should be enforced.

Building custom security controls is a difficult proposition at best. Where possible existing and proven solutions should be leveraged.

Rather than having a single system that delivers a wide range of unrelated capabilities, the isolation of separate capabilities of a system into separate sub-systems can simplify a solution by dividing and conquering. The understanding of a system can be key to keeping it locked down appropriately and compartmentalising its services can be a legitimate way to achieve that.

Further detailed information is available at OWASP, particularly the How to write insecure code article.

Related References

Policies & Standards

NIST - sp800-42 - Guideline on Network Security Testing

  • Section 3.12 General Information Security Principles
    • Security mechanisms (and information systems in general) should be as simple as possible. Complexity is at the root of many security issues.

OWASP - Guide

  • Section - Security Principles
    • Attack surface area and simplicity go hand in hand. Certain software engineering fads prefer overly complex approaches to what would otherwise be relatively straightforward and simple code. Developers should avoid the use of double negatives and complex architectures when a simpler approach would be faster and simpler.

Design Patterns

Navigation

Personal tools