Security Architecture Principles
9 fundamental rules for designing secure systems
What is Security Architecture?
Security architecture is the overall system required to protect an organization's IT infrastructure โ including hardware, software specifications, processes, and procedures involved in preventing, mitigating, and investigating threats. Security Architecture Principles are the fundamental rules that should be applied when designing and implementing security controls.
๐๏ธ Security by Design
Security requirements should be considered from the very start of development โ not as an afterthought. Building security in early saves time, money, and effort.
โ๏ธ Simplicity
Reduce complexity in security controls. Simpler systems have fewer mistakes, are easier to manage, and security issues are resolved faster.
๐ง Defense in Depth
Use multiple layers of security. If one control fails or is bypassed, others still protect the system. No single point of failure.
๐ Least Privilege
Grant only the minimum privileges needed for a user or process to do their job. No more, no less.
๐ซ Default Deny
The default setting is to deny all access. Access must be explicitly granted through configuration. Nothing is allowed unless specifically permitted.
๐ Fail Secure
When a system fails, it should fail in a secure state โ blocking access to protect data integrity, even if it causes a denial of service.
| Mode | Result | Risk |
|---|---|---|
| Fail Secure | Access blocked | Denial of service |
| Fail Safe | Control disabled | Illegitimate access |
๐ฅ Separation of Duties
No single person has full control over an entire transaction. Tasks are split or shadowed between multiple people to prevent fraud.
๐ Don't Trust External Systems
External systems are not under your organization's control. Treat them as insecure by default until trust is explicitly established through verification.
๐ก๏ธ Zero Trust
No actor, system, or service โ inside or outside the network โ is trusted by default. Every interaction must be verified before access is granted.
โณ Security is a Process โ Not a Product
Every system has vulnerabilities. The goal is assurance, not perfection. Systems, requirements, and threat contexts all change over time. Secure systems need constant maintenance:
Common Architecture Flaws
Attack types that exploit design and coding weaknesses
๐ก Covert Channels
A covert channel is an attack technique used to transfer information in a secretive, unauthorized, or illicit manner. It can be used to extract information from โ or implant information into โ an organization without detection.
๐ชค Maintenance Hook (Backdoor)
A trapdoor in software that allows developers easy maintenance access โ bypassing normal authentication. Left in production, it becomes a serious vulnerability.
๐ง Salami (Aggregation) Attack
Small attacks that individually go undetected, but add up to one major attack. Also called an incremental attack.
โ๏ธ Data Diddling
Changing data before or during entry into a computer system. The data is altered at the input stage, making it hard to detect after the fact.
๐ Privileged Programs
Programs that can grant users extra privileges beyond what they are already assigned โ creating a pathway for privilege escalation attacks.
๐ ๏ธ How to Protect Against These Flaws
Mechanisms to ensure that failures don't compromise secure operation. The system returns to a known-good secure state after a failure.
Validating and sanitizing all input before it is processed prevents data diddling, injection attacks, and parameter manipulation.
CIA Techniques
Ensuring Confidentiality, Integrity, and Availability
The CIA Triad in Software Design
Software designers use techniques to ensure programs do only what is required and nothing more. When controls fail: affected programs compromise Confidentiality โ unpredictable data changes break Integrity โ data corruption causes loss of Availability.
๐ Confinement Confidentiality
Process confinement restricts a process to reading from and writing to only specific memory locations and resources. Used in operating systems for process isolation and memory protection.
๐ฌ Process Isolation Integrity
Process isolation ensures that the behavior of one process will only affect its own memory and resources. Separate processes cannot interfere with each other.
Each process gets its own virtual memory space. Page tables are disjoint โ no process can access another's memory pages. Virtual addresses for each process start from 0, but map to different physical locations.
โญ Bounds (Authority Levels) Access Control
Each process running on a system is assigned an authority level that tells the OS what the process is allowed to do. The ring model defines privilege levels:
Security Models Overview
Frameworks for specifying and enforcing security policies
A security model is a scheme for specifying and enforcing security policies. It may be based on a formal model of access rights, computation, distributed computing, or no particular theoretical grounding.
Bell-LaPadula vs. Biba
The two most tested security models
๐ต Bell-LaPadula Model Confidentiality
Designed to protect confidentiality in military-style clearance systems. Uses a linear ordering of security levels.
| Level | Subject | Object |
|---|---|---|
| Top Secret | Tamara | Personnel Files |
| Secret | Samuel | E-Mail Files |
| Confidential | Claire | Activity Logs |
| Unclassified | Alice | Telephone Lists |
No Write Down โ A subject cannot write data to a lower classification level (prevents leaking secrets).
โ Claire (Confidential) CANNOT read Personnel or E-Mail Files.
โ Alice (Unclassified) can only read Telephone Lists.
๐ข Biba Model Integrity
Designed to protect data integrity. The opposite philosophy of Bell-LaPadula โ focuses on preventing corruption of higher-integrity data.
No Read Down โ A subject cannot read from a lower integrity level (prevents contamination by untrustworthy data).
| Property | Bell-LaPadula | Biba |
|---|---|---|
| Goal | Confidentiality | Integrity |
| No Read | No Read Up (can't-read-above-your-level) | No-Read-Down-(can't read below your level) |
| No Write | No Write Down (can't-write-below-your-level) | No-Write-Up-(can't write above your level) |
| Use Case | Military / Government classification | Financial / Database integrity systems |
| Limitation | Doesn't-address-integrity | Doesn't address confidentiality |
Biba: Think of a chef โ they won't READ a recipe from a less-experienced cook (No Read Down = no contamination) and can't rewrite the head chef's cookbook (No Write Up = no corruption).
Access Control Matrix
Mapping subjects, objects, and their access rights
An Access Control Matrix is a table that maps subjects (users) to objects (resources) and the rights each subject has over each object.
| Subject \ Object | File 1 | File 2 | File 3 | File 4 | Account 1 | Account 2 |
|---|---|---|---|---|---|---|
| John | Own, R, W | โ | Own, R, W | โ | Inquiry, Credit | โ |
| Alice | R | Own, R, W | W | R | Inquiry, Debit | Inquiry, Credit |
| Bob | R, W | R | โ | Own, R, W | โ | Inquiry, Debit |
If you look at Row "Alice" (her Capability List): File 1 (R), File 2 (Own,R,W), File 3 (W), File 4 (R), Account 1 (Inquiry, Debit), Account 2 (Inquiry, Credit) โ these are all the things Alice can do.
Take-Grant Model
Tracking how rights propagate through a system
The Take-Grant model dictates how rights can be passed between subjects. It's used to determine when rights can change and where privilege leakage occurs.
| Rule | Description | Notation |
|---|---|---|
| Take Rule | Allows a subject to take rights over an object from another subject | "x takes (ฮฑ to z) from y" |
| Grant Rule | Allows a subject to grant rights to an object to another subject | "x grants (ฮฑ to z) to y" |
| Create Rule | Allows a subject to create new rights | "x-creates-(ฮฑ-to)-new-{subject/object}-n" |
| Remove Rule | Allows a subject to remove rights it holds | "x removes (ฮฑ to) y" |