4.4 Security Engineering Principles & Technical Control Implementation

4.4 Security Engineering Principles & Technical Control Implementation

Building secure and resilient information systems requires rigorous application of engineering discipline rather than ad-hoc security patching. Within the ISC2 CGRC body of knowledge, control implementation is anchored in NIST SP 800-160 Volume 1 (Systems Security Engineering) and Volume 2 (Developing Cyber-Resilient Systems), alongside the paradigm-shifting tenets of NIST SP 800-207 (Zero Trust Architecture).

Technical controls directly enforce confidentiality, integrity, and availability within hardware, operating systems, hypervisors, database engines, and applications. GRC practitioners must understand how foundational engineering principles translate into concrete technical configurations across access control, identity management, and cryptography.

---

Systems Security Engineering Principles (NIST SP 800-160)

Security engineering principles provide the structural rules that guide system design, preventing architectural flaws that cannot be solved by operational policies alone. The foundational concepts—originally articulated by Saltzer and Schroeder and expanded by NIST—form the core of secure control implementation:

┌─────────────────────────────────────────────────────────────────────────────┐
│                  FOUNDATIONAL SECURITY ENGINEERING PRINCIPLES               │
├─────────────────────────────────────────────────────────────────────────────┤
│  • Defense-in-Depth: Multi-layered, independent defensive mechanisms        │
│  • Least Privilege: Minimum necessary rights for the shortest duration      │
│  • Separation of Duties: Splitting high-risk operations among roles         │
│  • Fail-Safe Defaults: Default deny posture upon system fault or restart     │
│  • Economy of Mechanism: Maximum architectural simplicity to avoid flaws   │
│  • Complete Mediation: Checking every single request without cached bypass  │
│  • Open Design: Security does not rely on obscurity (Kerckhoffs's Principle)│
│  • Least Common Mechanism: Minimizing shared components across trust levels │
└─────────────────────────────────────────────────────────────────────────────┘

1. Defense-in-Depth

• Implements multiple layers of redundant, diverse security controls across the computing stack (physical perimeter, network boundary, host OS, application runtime, and database encryption). If an adversary breaches the perimeter firewall, host-based intrusion prevention and data-at-rest encryption prevent unauthorized data exfiltration.

2. Principle of Least Privilege (AC-6)

• Users, applications, and system processes are granted only the minimum clearance, privileges, and access permissions strictly necessary to perform authorized mission functions. Privileged accounts (e.g., root, Domain Admin) must not be used for daily productivity tasks (e.g., email, web browsing).

3. Separation of Duties (AC-5)

• Divides critical, high-risk operational capabilities and administrative duties across multiple individuals or roles to prevent single-handed fraud, malicious sabotage, or undetected errors. For example, the individual who authors application source code cannot also hold production database deployment privileges or audit log deletion rights.

4. Fail-Safe Defaults / Fail-Secure (SC-24)

• In the event of a system crash, software exception, power disruption, or communication failure, the system must default to a secure state (access denied, traffic blocked, transactions rolled back) rather than an insecure state (open access). For example, a next-generation firewall that experiences a kernel panic should block all network traffic (fail-closed) rather than passing uninspected packets (fail-open).

5. Economy of Mechanism (Simplicity)

• Security architectures and software modules must be designed to be as simple, compact, and concise as possible. Unnecessary complexity dramatically increases the probability of software flaws, unmanageable edge cases, and configuration drift, making formal verification and assessment virtually impossible.

6. Complete Mediation

• Every single access request to every protected resource or object must be intercepted, evaluated, and authorized against active security policies on every transaction, without relying on cached permissions or assuming subsequent calls within a session remain trusted.

7. Open Design (Kerckhoffs's Principle)

• The security of a cryptographic system or protective architecture must rely solely on the strength of the algorithm and the secrecy of the keys—never on the secrecy of the design or algorithm itself. Proprietary, "security-through-obscurity" mechanisms are inherently untrustworthy.

---

Zero Trust Architecture (NIST SP 800-207)

Traditional enterprise security relied on a "castle-and-moat" perimeter model: everything inside the corporate intranet was treated as trusted, while the outside internet was untrusted. Modern cloud computing, remote workforces, and sophisticated persistent threats invalidate this assumption. Zero Trust Architecture (ZTA) operates on the foundational principle: "Never trust, always verify."

┌─────────────────────────────────────────────────────────────────────────────┐
│                     ZERO TRUST CONTROL & DATA PLANES                        │
│                                                                             │
│     CONTROL PLANE                                                           │
│     ┌─────────────────────────────────────────────────────────────────┐     │
│     │                 Policy Decision Point (PDP)                     │     │
│     │   ┌───────────────────────────┐   ┌─────────────────────────┐   │     │
│     │   │       Policy Engine       │◄──┤  Policy Administrator   │   │     │
│     │   └─────────────┬─────────────┘   └────────────┬────────────┘   │     │
│     └─────────────────┼──────────────────────────────┼────────────────┘     │
│                       │ Context & Threat Telemetry   │ Directives & Tokens  │
│                       ▼                              ▼                      │
│     DATA PLANE                                                              │
│     ┌─────────┐      Untrusted Network       ┌──────────────┐   ┌─────────┐ │
│     │ Subject │ ───────────────────────────► │   Policy     │──►│ Enterprise│
│     │ (User / │       Encrypted Stream       │ Enforcement  │   │ Resource│ │
│     │ Device) │ ◄─────────────────────────── │  Point (PEP) │   │ (App/DB)│ │
│     └─────────┘                              └──────────────┘   └─────────┘ │
└─────────────────────────────────────────────────────────────────────────────┘

The 7 Core Tenets of NIST SP 800-207

1. All data sources and computing services are considered resources.
2. All communication is secured regardless of network location. Internal LAN traffic must be encrypted and authenticated with the same rigor as public internet traffic.
3. Access to individual enterprise resources is granted on a per-session basis. Prior authentication to Resource A grants zero implicit access to Resource B.
4. Access to resources is determined by dynamic policy. Access rules evaluate not just user identity, but device security posture, patch level, behavioral anomaly metrics, geolocation, and requested data sensitivity.
5. The enterprise monitors and measures the integrity and security posture of all owned and associated assets. Non-compliant or compromised endpoints are quarantined dynamically.
6. All resource authentication and authorization are dynamic and strictly enforced before access is allowed. Continual cycle of obtaining access, scanning and evaluating threats, and re-evaluating trust.
7. The enterprise collects as much information as possible about asset posture, network infrastructure, and communications to continuously refine and adapt security policies.

PDP and PEP Mechanics

• Policy Decision Point (PDP): The centralized governance engine composed of:
  • Policy Engine (PE): Evaluates risk signals, threat intelligence feeds, and enterprise rules to render a binary allow/deny access decision.
  • Policy Administrator (PA): Issues commands to the PEP, generating short-lived cryptographic credentials, session tokens, or firewall rules to establish or terminate communication paths.
• Policy Enforcement Point (PEP): The gatekeeper component positioned directly in the data plane (e.g., API gateway, reverse proxy, micro-segmentation agent) that intercepts, inspects, and enforces the connection between subject and resource based on PA instructions.

---

Technical Access Control Models (AC Family)

Selecting and implementing the appropriate access control model enforces the principle of least privilege across diverse operational environments:

┌─────────────────────────────────────────────────────────────────────────────┐
│                     ACCESS CONTROL PARADIGM COMPARISON                      │
├─────────────────────────────────────────────────────────────────────────────┤
│  RBAC (Role-Based)     Subject ──► Assigned Role ──► Permissions            │
│                        Static, predictable, group-based permissions         │
├─────────────────────────────────────────────────────────────────────────────┤
│  ABAC (Attribute-Based) [Subject + Resource + Action + Environment] ──► Rule│
│                        Dynamic, contextual, fine-grained access decisions   │
└─────────────────────────────────────────────────────────────────────────────┘

Role-Based Access Control (RBAC)

• Permissions are bound directly to defined organizational roles (e.g., Billing Analyst, Helpdesk Specialist), and users are assigned to roles based on job responsibilities.
• Strengths: Simple administration, highly structured, well-suited for stable, predictable organizational hierarchies.
• Limitations: Subject to "role explosion" in complex environments requiring hundreds of hyper-specific roles.

Attribute-Based Access Control (ABAC per NIST SP 800-162)

• Evaluates attributes across four dimensions in real time using boolean logic:
  1. Subject Attributes: User role, department, citizenship, clearance level, security training status.
  2. Resource / Object Attributes: Data classification (e.g., Top Secret, CUI, Public), file owner, creation date, project tag.
  3. Action Attributes: Read, Write, Edit, Delete, Export, Execute.
  4. Environmental Attributes: Time of day, client IP address, geographic location, device compliance status, threat level.
• Strengths: Maximum flexibility, fine-grained control, ideal for Zero Trust implementations (e.g., "Allow Read access to CUI financial records ONLY IF user is in Finance Department AND accessing from a corporate-managed laptop AND connecting from within the United States during business hours").

---

Digital Identity and Authentication (IA Family & NIST SP 800-63B)

Authentication establishes trust in the digital identity of a subject. NIST SP 800-63-3 and SP 800-63B (Digital Identity Guidelines: Authentication and Lifecycle Management) establish three standardized Authenticator Assurance Levels (AAL):

[!IMPORTANT] OMB Mandate M-22-09 & NIST SP 800-63B: Federal agencies are strictly mandated to implement phishing-resistant MFA (AAL3) for all enterprise personnel and public-facing systems processing sensitive data. Passwords combined with SMS codes or standard push notifications no longer meet AAL3 requirements.

---

Cryptography and Key Management (SC Family & FIPS 140-3)

Cryptographic mechanisms protect data confidentiality and integrity across storage and transmission pipelines. Federal and high-assurance systems must employ cryptographic modules validated under FIPS 140-3 (Security Requirements for Cryptographic Modules).

┌─────────────────────────────────────────────────────────────────────────────┐
│                     FIPS 140-3 SECURITY LEVELS HIERARCHY                    │
│                                                                             │
│  Level 4: Complete Physical Envelope Protection & Environmental Zeroization │
│  Level 3: Tamper-Resistant Hardware, Physical Enclosures & Identity Auth    │
│  Level 2: Tamper-Evident Coatings/Seals & Role-Based Authentication        │
│  Level 1: Basic Software Cryptographic Algorithms (No Physical Security)    │
└─────────────────────────────────────────────────────────────────────────────┘

FIPS 140-3 Validation Levels

1. Level 1 (Basic Software): Lowest level. Employs at least one approved cryptographic algorithm or security function without requiring physical security mechanisms (e.g., standard commercial cryptographic software libraries).
2. Level 2 (Tamper-Evident Physicality): Adds requirements for physical tamper-evident coatings, seals, or pick-resistant locks on removable covers, alongside role-based authentication.
3. Level 3 (Tamper-Resistant Hardware): Requires physical tamper-detection and response circuitry that zeros out plaintext cryptographic keys (zeroization) upon physical intrusion, alongside identity-based authentication and physical separation of ports.
4. Level 4 (Environmental Envelope): Highest level. Provides complete physical protection envelope designed to detect and withstand environmental anomalies (temperature, voltage variations) with immediate zeroization (used in military missile command and nuclear command modules).

Cryptographic Key Lifecycle (NIST SP 800-57 Part 1)

Cryptographic security depends entirely on the rigorous management of keys throughout their lifecycle:

1. Key Generation: Generated using FIPS-approved Deterministic Random Bit Generators (DRBG) or True Random Number Generators (TRNG) with sufficient entropy.
2. Key Distribution & Establishment: Transported using secure out-of-band channels or established via authenticated key-agreement protocols (e.g., ECDH with forward secrecy).
3. Key Storage: Stored in hardware security modules (HSM) or encrypted using Key Encryption Keys (KEK) under an envelope encryption hierarchy.
4. Key Rotation / Rollover: Regularly rotated based on cryptoperiod limits (data volume or elapsed time) defined in organizational policy.
5. Key Revocation & Destruction (Zeroization): Compromised or expired keys must be securely overwritten and permanently destroyed to prevent retrospective decryption of historical traffic.

Protecting Data-at-Rest and Data-in-Transit

• Data-at-Rest (SC-13, SC-28): Enforces AES-256 encryption in Galois/Counter Mode (GCM) or Cipher Block Chaining (CBC) across storage volumes, database tables (Transparent Data Encryption [TDE]), and application payloads.
• Data-in-Transit (SC-8, SC-13): Enforces TLS 1.3 across all network boundaries, eliminating insecure legacy ciphers (RC4, 3DES), deprecating static RSA key exchanges, and enforcing Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) for Perfect Forward Secrecy (PFS).

---

Real-World RMF Scenario: Engineering ABAC & Hardware MFA

Scenario: A defense health platform processing highly sensitive soldier medical records is deployed in a commercial cloud environment. During Step 3 (Implement), the engineering team deploys standard username/password authentication with SMS OTP and relies on simple IP subnet whitelisting for access control.

GRC Action: The Lead Security Architect and ISSO halt implementation, citing non-compliance with NIST SP 800-207 (Tenet 2: Network location does not imply trust) and NIST SP 800-63B (AAL3 requirement). The architecture is updated to require FIPS 201 PIV smart cards (AAL3 phishing-resistant MFA) and an Attribute-Based Access Control (ABAC) policy engine that evaluates clinician role, patient assignment, and device compliance before granting per-session record decryption keys.

---

Common Exam Traps

• ⚠️ Trap: Assuming FIPS 140-3 Level 1 requires physical tamper seals. Physical tamper evidence begins at Level 2, while automatic zeroization on intrusion begins at Level 3.
• ⚠️ Trap: Confusing Fail-Safe Defaults (Fail-Closed) with High Availability (Fail-Open). From a cybersecurity perspective, failing securely (blocking access when an error occurs) takes precedence over passing uninspected traffic.
• ⚠️ Trap: Believing Zero Trust means having no perimeter at all. ZTA replaces static network perimeters with micro-perimeters and continuous Policy Enforcement Points (PEPs) at every resource interface.