Fundamental Security Principles: Defense in Depth, Least Privilege & Zero Trust

Building a resilient, defensible enterprise architecture is not achieved by installing a single miraculous security product. Software contains bugs, humans make configuration mistakes, and hardware eventually fails. Professional security architects design systems around established security design principles that ensure that the failure of any single component does not lead to total compromise.

1. Defense in Depth (Layered Defense)

Derived from military strategy, Defense in Depth posits that an organization must deploy multiple independent defensive layers across data, hosts, networks, and perimeters. If an attacker breaches the perimeter firewall, they are immediately confronted by network segmentation, host-based EDR monitoring, encrypted files, and least-privilege IAM controls.

Figure 5.1: Multi-layered Defense in Depth Implementation from Perimeter to Core Data

2. Principle of Least Privilege (PoLP)

The Principle of Least Privilege mandates that every user, process, program, and service account must be granted only the absolute minimum set of privileges, permissions, and network access necessary to perform its legitimate job function, and nothing more:

• Web server runtimes (e.g., Apache, Nginx, Node.js) should never run as the root user or Administrator. They run as dedicated unprivileged system users (e.g. www-data or nobody).
• Database application accounts should only have SELECT, INSERT, UPDATE rights on application tables—never administrative rights like DROP DATABASE or GRANT ALL.
• Developers should not have direct write access to production database clusters. All code and schema updates must transit through authenticated CI/CD pipelines.

3. Zero Trust Architecture (ZTA): "Never Trust, Always Verify"

Traditional perimeter security operated under the outdated "Castle-and-Moat" model: everything outside the company network was untrusted, but everything inside the office LAN was implicitly trusted. Zero Trust Architecture (NIST SP 800-207) dismantles this model entirely by assuming the network is always hostile and already compromised:

4. Additional Foundational Security Principles

• Fail-Safe Defaults: If a security mechanism fails or crashes, its default state must be to deny access rather than allow access. For example, if a firewall encounters a parsing error, it drops the packet.
• Separation of Duties (SoD): High-risk tasks require approval from two distinct individuals (e.g. one developer writes code, a separate senior engineer reviews and approves the pull request).
• Economy of Mechanism: Security mechanisms must be designed as simply and cleanly as possible. Overly complex security architectures invite obscure human misconfigurations.