Secure Architecture, Layering and Locks

Concept Focus

Enterprise is not just IT. It is the people, platforms, and purpose working toward shared objectives. Security architecture is how we turn that purpose into layered, linked safeguards, strategic (why), tactical (what), and operational (how), without breaking the business.

• Human at the center. Designs that ignore behavior generate bypasses. Designs that respect cognition (least privilege, secure defaults, guardrails that are hard to misuse) get used.
• Enterprise Security Architecture (ESA). A layered blueprint: controls, processes, and procedures woven together. It must align to strategy, enable the business, streamline processes, and measurably improve security outcomes.
• SABSA in one line. A risk-driven, business-first framework to derive security services from business attributes. Start with “what must be true for the business to succeed,” then trace to controls, policies, and metrics that prove it.

Performance building blocks

• Multitasking (1 CPU, time-sliced): one cook juggling orders; the OS scheduler slices CPU time for many processes.
• Multiprocessing (many CPUs / cores): several cooks in parallel kitchens; true concurrency and load balancing.
• Multithreading (threads within one process): one cook with multiple stations; threads share memory to reduce overhead.

Right-sizing these patterns affects threat exposure (shared memory = shared risk), blast radius, and control placement.

Memory, where exploits love to live

• Stack (LIFO, fast, bounded) vs Heap (dynamic, big, slower).
• Risk: buffer overflows, stack smashing, heap spraying.
• Mitigations: input bounds checking; ASLR (randomize addresses), DEP / NX (no code in data pages), stack canaries, hardened allocators, compiler flags, static / dynamic analysis, timely patching.

Firmware, the quiet boss

• Lives in ROM / flash; initializes hardware; bridges OS and hardware.
• Risks: persistence, pre-OS implants, vendor-locked update cycles.
• Controls: Secure / Measured Boot, signed firmware, attestation, update SLAs in contracts, and penalties for security regressions.

The OS trust staircase

User mode → Kernel → Hardware.

• Security kernel: the tiny, privileged enforcer for all access decisions. Applies least privilege and mediates calls to hardware.
• Privilege rings (x86): Ring 0 (kernel, max power) … Ring 3 (apps, least). Higher ring number = lower privilege.

Trusted Computing Base (TCB)

The minimal combo of hardware, firmware, OS, and components that must be right for security to hold. Smaller, verifiable, and monitored is safer. Examples: kernel, drivers with elevated rights, HSM / TPM, critical configs, suid binaries.

Essential protection mechanisms:

• Process isolation (separate address spaces).
• Hardware segmentation / MPU / MMU (enforced boundaries the OS cannot hand-wave away).
• Clear, enforceable policy tied to these mechanisms.

Architecture-level pitfalls

• Race conditions & TOC/TOU: check vs use separated in time. Fix with atomic ops, locking, idempotent flows, secure APIs.
• Covert channels: unauthorized signaling via storage (shared objects) or timing (deliberate delays). Reduce signal / noise, partition resources, schedule deterministically.
• Emanations (TEMPEST): EM / RF leaks; mitigate via shielding (Faraday), control zones, and noise.

Security Models — from theory to enforcement

Security architecture is not just about controls you deploy; it is about the rules of the game. Security models translate policy into provable behavior, setting boundaries for how subjects (users, processes) interact with objects (files, databases, systems).

Bell–LaPadula (BLP): confidentiality first

• Purpose: prevent unauthorized disclosure of classified information.
• No Read Up (Simple Security): users can't read above their clearance.
• No Write Down (Star Property): users can't leak by writing downwards.
• Strong Star: read / write only at the same level.
• Limitations: ignores integrity and fails against covert channels.

Biba: integrity above all

• Purpose: protect data from unauthorized modification.
• No Read Down: high-integrity processes can't consume untrusted data.
• No Write Up: low-integrity processes can't pollute trusted data.
• Invocation Property: low-level code can't call higher-level functions.
• Weakness: does nothing for confidentiality.

Clark–Wilson: commercial integrity

• Purpose: ensure integrity via well-formed transactions and separation of duties.
• CDIs (Constrained Data Items): critical records such as balances and audit logs.
• UDIs (Unconstrained Data Items): untrusted inputs that must be validated.
• TPs (Transformation Procedures): the only trusted way to modify CDIs.
• IVPs (Integrity Verification Procedures): periodic checks for corruption.
• Example: payroll, manager approves and clerk processes, so fraud requires collusion.

Brewer–Nash (Chinese Wall): conflict of interest control

• Purpose: stop users from crossing ethical boundaries (insider trading, consulting conflicts).
• Rule: once you access Client A's sensitive dataset, you're barred from accessing competing Client B's dataset.
• Application: consulting, legal, finance, anywhere conflict of interest is a business risk.

Common Criteria (ISO 15408): proving products are trustworthy

• Protection Profile (PP): “I want”, the customer's security requirements.
• Security Target (ST): “I provide”, the vendor's implementation.
• Target of Evaluation (TOE): the actual system or product tested.
• Evaluation Assurance Level (EAL 1–7): rigor of evaluation, from basic functional tests to formal proofs.
• Takeaway: EAL4 is most common commercially; EAL7 is rare, used only for nuclear or space-grade systems.

Brain Ticklers