Skip to content
Cybersecurity Handbook Pro

Security Models & Principles

Security architecture is the only place where theory survives the first engagement. Every framework — Zero Trust, Bell-LaPadula, defense-in-depth, least privilege — has a specific formal definition, and almost every breach in the last decade is a violation of a 50-year-old principle. SolarWinds failed separation of privilege. Colonial Pipeline failed least privilege (a single VPN account, no MFA). Equifax failed complete mediation (WAF that did not see the API path). This module walks through the formal models so you can read a breach report and name the principle that was violated.

The Core Concept

Section titled “The Core Concept”

Three threads connect every model:

  1. What are we protecting? Confidentiality, Integrity, Availability (CIA), plus Privacy and Non-repudiation as extended dimensions.
  2. Who can do what? Authentication → Authorization → Accounting (AAA), enforced by access control matrices, capabilities, or attributes.
  3. How is the system structured? Defense in depth (layers), separation of duties (roles), least privilege (rights), complete mediation (every access checked).
┌───────────────────────────────────────────────────────────┐
│  CIA Triad                                                 │
│   Confidentiality ── Integrity ── Availability              │
│   (encryption)        (hashing)        (redundancy)         │
│                                                            │
│  AAA                                                       │
│   Authn (who are you?) ── Authz (can you?) ── Acct (log)   │
│                                                            │
│  Saltzer & Schroeder 1975                                  │
│   Economy · Fail-safe defaults · Complete mediation         │
│   Open design · Separation of privilege · Least privilege   │
│   Least common mechanism · Psychological acceptability     │
└───────────────────────────────────────────────────────────┘

How It Works

Section titled “How It Works”

  1. CIA Triad — the three properties every security control protects:

    • Confidentiality: only authorized subjects can read the data. Enforced by encryption (AES-GCM at rest, TLS in transit), access control lists (DACLs on Windows, rwx on POSIX), Mandatory Access Control (SELinux contexts, AppArmor profiles), and information-flow controls (Bell-LaPadula).
    • Integrity: data is not modified by unauthorized subjects, and authorized modifications are not corrupted. Enforced by hashing (SHA-256 of files), MACs (HMAC over messages), digital signatures (Ed25519, ECDSA), and TPM-measured boot.
    • Availability: the system remains usable. Enforced by redundancy (load balancers, RAID), rate limiting (nginx limit_req), DDoS protection (Cloudflare, Arbor), and backups (3-2-1 rule: 3 copies, 2 media, 1 offsite).
    • Privacy and Non-repudiation are commonly added as separate dimensions: privacy = the right to control one’s own data; non-repudiation = a sender cannot deny sending.

  2. Saltzer & Schroeder’s eight principles (1975) — still the foundation of every secure-design checklist:

    • Economy of mechanism: keep the design as simple as possible. Complexity is the enemy of security. (Counter-example: the TLS 1.2 protocol — 80+ cipher suite combinations; TLS 1.3 cut this to 5.)
    • Fail-safe defaults: the default access decision is deny. (Counter-example: S3 buckets defaulting to public between 2006 and 2017.)
    • Complete mediation: every access is checked, not just the first one. (Counter-example: capability tokens cached past their intended lifetime.)
    • Open design: the design is not a secret; only keys are. Kerckhoffs’s principle (1883): the system must remain secure if everything except the key is public knowledge. (Counter-example: proprietary crypto algorithms.)
    • Separation of privilege: a privilege is granted only when multiple conditions are met. (Example: sudo requires both group membership and a TTY.)
    • Least privilege: a subject has only the privileges needed to do its job. (Enforced by Linux capabilities, Windows token privileges, AWS IAM scoped roles.)
    • Least common mechanism: minimize the shared channels between subjects. (Counter-example: a single database used by both the public web tier and the internal admin tier.)
    • Psychological acceptability: security controls must be usable. (Counter-example: a 24-character password rotated every 30 days → users write it on a sticky note.)

  3. Bell-LaPadula (1973) — confidentiality-focused, military origins. Two rules:

    • Simple Security Property (no read up): a subject at clearance L cannot read an object at level L' > L.
    • Confinement Property (no write down): a subject at clearance L cannot write to an object at level L' < L. Prevents high-clearance data from leaking to a lower level.
    • Implementations: SELinux MLS (Multi-Level Security), TS/SCI document handling.

  4. Biba (1977) — the integrity dual of Bell-LaPadula. Two rules:

    • Simple Integrity Property (no read down): a subject at integrity level L cannot read an object at level L' < L (could be corrupted data).
    • Integrity Confinement (no write up): a subject at L cannot write to L' > L (could corrupt higher-integrity data).
    • Real-world example: a low-integrity web form cannot update a high-integrity audit log.

  5. Clark-Wilson (1987) — commercial integrity. Two key concepts:

    • Constrained Data Items (CDIs): data that must be integrity-protected.
    • Transformation Procedures (TPs): the only allowed operations on CDIs.
    • Separation of duties is enforced by requiring two different users to invoke a TP.

  6. Zero Trust Architecture (NIST SP 800-207, 2020). Three principles:

    • Verify explicitly — every access decision is based on identity, context, and policy, not network location. (“The network is no longer the trust boundary.”)
    • Least privilege access — access is granted just-in-time, just-enough, and continuously evaluated.
    • Assume breach — design as if attackers are already inside. Encrypt everything, segment everything, log everything.
    • Implementation: Identity-Aware Proxy (Cloud IAP), BeyondCorp, microsegmentation, SPIFFE/SPIRE workload identity.

  7. Defense in depth — multiple overlapping controls, so failure of one does not compromise the asset. Classic layers:

    • Perimeter (firewall, DDoS scrubbing).
    • Network (segmentation, NAC, IDS).
    • Endpoint (EDR, AV, MDM).
    • Application (WAF, RASP, secure coding).
    • Data (encryption, masking, tokenization).
    • Identity (MFA, conditional access, PAM).
    • The principle is defeated when one layer’s failure exposes the next. (Example: a flat network where an attacker who lands on a single host can pivot anywhere — there is no “depth” after the perimeter.)

  8. AAA — Authentication, Authorization, Accounting.

    • Authentication factors: knowledge (password), possession (token), inherence (biometric), behavior (typing cadence), location (geofence). MFA = two or more distinct factors; “password + security question” is not MFA (both are knowledge).
    • Authorization models: DAC (Discretionary — owner sets ACL), MAC (Mandatory — system-enforced labels), RBAC (Role-Based — role grants permissions), ABAC (Attribute-Based — policy based on subject/resource/environment attributes).
    • Accounting: every event is logged; logs are tamper-evident (WORM storage, signed logs).

Common Techniques

Section titled “Common Techniques”
PrincipleCommon ViolationReal Example
Open design“Security through obscurity” — proprietary cryptoCSS (DVD encryption), A5/1 GSM cipher
Fail-safe defaultsS3 buckets default public2017: Pentagon S3 leak
Least privilegeDomain admin used for daily tasksMost ransomware root-cause analyses
Complete mediationCached auth tokens not re-checkedMicrosoft Exchange ProxyShell (CVE-2021-34473) — auth bypass via path confusion
Separation of privilegeCI/CD pipeline has prod push rightsSolarWinds 2020 — attacker pushed via build server
Defense in depthFlat network post-perimeterColonial Pipeline 2021 — one VPN, no segmentation
Psychological acceptabilityForced 30-day rotation → password reuseNIST SP 800-63B now discourages mandatory rotation
Economy of mechanism80-cipher TLS 1.2 matrixThe BEAST, CRIME, BREACH, DROWN family

Hands-On Commands

Section titled “Hands-On Commands”
Terminal window
# Inspect the current user's least-privilege posture on Linux
id
groups
capsh --print | grep -E '^Cap(Eff|Bnd|Inh)'
sudo -l                                 # what can this user run as root?


# Verify SELinux is enforcing and the current context
getenforce
ls -Z /var/www/html/index.html          # SELinux label on a file
ps -eZ | grep httpd                     # SELinux label on a process


# Verify a Bell-LaPadula-style mandatory access control system
semanage login -l                       # SELinux user → MLS level mapping


# Show the effective access (RBAC) for the current Azure AD user in a subscription
az role assignment list --assignee $(az ad signed-in-user show --query id -o tsv) --all
# Output: roleDefinitionName, scope. Least-privilege means one or two scoped roles.


# Verify Zero Trust: how many "trusted" sources does a service accept?
# Inspect the firewall rules; an implicit trust on a CIDR is a network-location trust, not Zero Trust.
iptables -L INPUT -n -v | head
# Zero Trust equivalent: every request carries an Identity token (e.g., SPIFFE)


# Show the audit trail completeness (accounting)
auditctl -l | head -20                  # Linux audit rules
journalctl --since '1 hour ago' | wc -l # Linux logs
Get-WinEvent -LogName Security -MaxEvents 10000 | Measure-Object | select Count


# Demonstrate separation of privilege: show that sudo requires both group + TTY
echo $TTY
groups | grep -q sudo && echo "user in sudo group"
sudo -k                                # invalidate cached credential
sudo true                               # prompts for password (in TTY only)


# Verify the system is enforcing MFA on interactive logins
grep -E 'password requisite|pam_google' /etc/pam.d/common-auth 2>/dev/null
# Or on AWS:
aws iam get-account-summary | jq '.SummaryMap.UsersQuota, .SummaryMap.AccountMFAEnabled'

Detection — Defender View

Section titled “Detection — Defender View”

The detection angle on principles is not signature-based. It is policy-as-code:

  • Least privilege: alert on identities with broad scopes (Owner on a subscription, domain admin in AD, *:* AWS policy). Use Cloud Security Posture Management (CSPM) tools: Prowler, Scout Suite, Microsoft Defender for Cloud.
  • Defense in depth: alert on flat-network topologies; alert on missing segmentation between tiers (e.g., web tier can reach DB tier on all ports).
  • Fail-safe defaults: alert on new public S3 buckets; alert on 0.0.0.0/0 inbound security groups.
  • Open design: alert on proprietary crypto in use (cert chains with custom curves, encrypted-with-unknown-algorithm blobs).
  • Psychological acceptability: alert on bypass patterns — users who consistently disable MFA, write passwords in wiki pages, etc.

MITRE ATT&CK T1098 — Account Manipulation (when least-privilege is violated, attackers add themselves to privileged groups).

MITRE ATT&CK T1078.004 — Valid Accounts: Cloud (when Zero Trust is not enforced, a single cloud account can pivot across services).

MITRE ATT&CK T1485 — Data Destruction (defense in depth should detect a mass delete across one layer).

MITRE ATT&CK T1070.001 — Indicator Removal on Host: Clear Windows Event Log (when accounting fails, attackers cover tracks).

Wazuh rule 920 / 80792 — A new S3 bucket policy with Principal: "*" was set [verify — requires custom CloudTrail decoder].

Wazuh rule 80791 — A user was added to a privileged group (Linux /etc/group write alert) [verify].

For Zero Trust telemetry: SPIFFE/SPIRE issues an SVID (SPIFFE Verifiable Identity Document) to every workload; an mTLS connection between workloads is the policy decision point. The control plane logs every SVID issuance; that is the audit trail.

Evasion Techniques

Section titled “Evasion Techniques”

Exploiting cached authorization (violating complete mediation). A long-lived OAuth2 refresh token, an AWS session token cached for 12 hours, or a Kerberos TGT valid for 10 hours all violate complete mediation: the access decision was made once and then cached. Zero Trust requires short-lived, just-in-time tokens. Practical implementation: AWS session duration ≤ 1h, OAuth2 access token TTL ≤ 15min with refresh.

Confused-deputy problem (violating separation of privilege). AWS service roles that perform actions on behalf of untrusted users — if the role assumes the caller is authorized without re-checking, the attacker invokes the service with the role’s privileges. The canonical case: CVE-2019-1980 [verify] (the AWS IMDSv1 vs IMDSv2 SSRF family, including the Capital One 2019 breach).

Permission-boundary bypass. AWS allows PermissionsBoundary on a role; an attacker with iam:CreateRole and a permissive boundary on their own role can escalate. Defense: enforce boundaries via SCP (Service Control Policy) at the organization level.

Implicit trust on a flat network. A host on a flat /16 that has implicit allow between any two hosts violates Zero Trust. Defense: microsegmentation via Calico, Cilium, or Azure VNet peerings with NSGs.

Single-factor fallback. A system that “supports MFA” but falls back to password-only when the second factor fails violates least privilege. Defense: hard-fail on MFA error; no fallback path.

EvasionPrinciple violatedHow to detect / prevent
Token cachingComplete mediationShort-lived tokens; refresh with step-up auth
Confused deputySeparation of privilegeCheck caller identity at every boundary
SCP bypassLeast privilegeApply SCP at org root; deny iam:CreateRole without boundary
Flat networkDefense in depthMicrosegmentation; deny by default at L3/L4
MFA fallbackLeast privilegeHard-fail on second factor unavailable

⚠️ What caught me: A red team where the customer had implemented “Zero Trust” — every service called the central IAM service for an access token before any cross-service request. The tokens were 24 hours long, cached client-side, and contained the user’s full entitlement set. An attacker who phished a developer stole the token, then made authenticated calls to every service the developer had access to for the full 24 hours. The customer had implemented authentication, not Zero Trust — they had created a long-lived, high-privilege bearer token and called it “Zero Trust.” Lesson: Zero Trust means verify explicitly and continuously. A 24-hour token is just a slow-moving MFA bypass.

Lab Practice

Section titled “Lab Practice”

VM: Ubuntu 22.04 with selinux-utils, auditd, prowler (AWS scanner), scoutsuite. An AWS sandbox account with the IAM Identity Center enabled.

Objective:

  1. On a Linux VM, install and enable SELinux in enforcing mode. Create a file with MLS context s0:c100,c200 and demonstrate that a user_t (level s0) process cannot read it.
  2. Run prowler aws --compliance cis_aws against the sandbox account; identify three least-privilege violations and remediate one.
  3. Demonstrate Bell-LaPadula “no read up”: create two SELinux logins with different MLS clearances and show that the lower one cannot read the higher’s files.
  4. Configure an AWS IAM role with a 15-minute max session duration; assume the role via aws sts assume-role and show that the token expires.

Expected flag format: flag{selinux_enforcing_prowler_3_findings_no_read_up_session_15m}.

Detection that should fire: SELinux AVC denial log in /var/log/audit/audit.log (when the user attempts the cross-level read); Prowler finding Ensure IAM users are assigned to groups and Ensure no root account access key exists; CloudTrail log showing AssumeRole with Expiration ≤ now + 15min.

Interview Questions

Section titled “Interview Questions”

Conceptual: name the eight Saltzer & Schroeder principles, and for each give one real-world control that enforces it and one common control that violates it.

Technical: explain Bell-LaPadula’s “no write down” rule in terms of why a top-secret clearance holder cannot post a tweet. What model is the dual of this for integrity?

Scenario: a customer implemented MFA on their VPN, then said they were “Zero Trust now.” List three concrete Zero Trust properties they still lack and one technical control for each.

What is the difference between DAC, MAC, RBAC, and ABAC? For each, give one real system that implements it and one attack against it.

Technical: describe the Capital One 2019 breach in terms of (a) which Saltzer & Schroeder principles were violated, (b) which AAA dimension was insufficient, and (c) which Zero Trust property would have prevented it.

Section titled “Related Modules”

→ F11 (Threat Modeling) · F12 (Cyber Kill Chain & MITRE ATT&CK) · BT1 (Blue Team Fundamentals)