security-engineering

name	security-engineering
title	Security Engineering
category	swe-foundations
description	Security engineering principles: threat modeling, cryptography, access control, privacy, secure development, physical/operational security, and economics of trust. Covers adversarial thinking, protocol design, tamper resistance, and assurance.
trigger_conditions	["Use this when designing authentication, authorization, or access control for a system","Use this when threat modeling a new feature, service, or infrastructure change","Use this when choosing or reviewing a cryptographic primitive, protocol, or key management scheme","Use this when handling sensitive data — PII, financial records, credentials, health data","Use this when building systems with physical security requirements (hardware, payments, IoT)","Use this when evaluating security controls for effectiveness vs. security theater","Use this when privacy requirements or inference risks are involved","Use this when writing security requirements, performing a security review, or preparing for audit","Use this when a system involves economic incentives that could misalign with security goals","Use this when assessing assurance claims, compliance requirements, or SDL processes"]
tags	["security","cryptography","access-control","privacy","threat-modeling","phase-2","swe-foundations"]
phase	2
wiki_path	output/wiki/security-engineering/concepts/

Security Engineering

Core Rules

1. Security has four interdependent pillars: Policy (what to protect), Mechanism (how), Assurance (evidence it works), Incentives (who bears cost/gain). Weakness in any one breaks the whole.

2. Always do threat modeling before designing controls. Identify specific adversary categories (nation-state, criminal, insider, opportunist) and scope threats to realistic opponents — generic "attacker" threat models miss key mitigations and over-engineer for irrelevant threats.

3. Never confuse security theater with real protection. Visible controls that look strong but provide no actual resistance waste budget and create false confidence. Test controls against actual attack paths.

4. Access control belongs in the mechanism layer, not just policy. Choose DAC vs MAC vs RBAC based on trust model: DAC for user-controlled data, MAC for multi-level confidentiality, RBAC for organizational roles. TOCTTOU is a common implementation failure — check and use must be atomic.

5. Cryptography is a component, not a solution. Cryptographic strength is useless if key management fails, protocols have logic flaws, or side-channel leakage exposes secrets. Always evaluate the full stack: algorithm + mode + protocol + implementation + key lifecycle.

6. Human factors are not optional. Security mechanisms fail when cognitive load exceeds user capacity (Whitten-Tygar). Apply affordances, nudges, and choice architecture to make the secure path the path of least resistance.

7. Economics drives security outcomes. Misaligned incentives — where the party responsible for security doesn't bear the cost of failure — produce persistent vulnerabilities. Externalities, market lemons, and network lock-in all degrade security. Fix incentives before adding mechanisms.

8. Privacy is contextual integrity, not secrecy. Information flows are appropriate when they match the norms of the context in which data was shared. Re-identification risks exist even in aggregate statistical releases — apply differential privacy for query-based access.

9. Physical security follows Deter-Detect-Alarm-Delay-Respond. Each layer buys time for the next. Tamper-evident beats tamper-proof as a realistic goal — make attacks visible and expensive, not impossible.

10. For high-assurance systems: minimize the Trusted Computing Base (TCB). The smaller the component that must be trusted absolutely, the easier verification becomes. Hardware roots of trust (TPM, enclaves) anchor the chain.

11. Secure development is a lifecycle discipline, not a gate. SDL, DevSecOps, and continuous assurance require integrating threat modeling, static analysis, fuzz testing, and pen-testing at every phase — not just pre-release.