4.2 Control Selection, System Security, and Architecture Risk

Selecting Controls for Real Systems

Control selection is not a shopping exercise. It is a risk management decision that connects assets, threats, vulnerabilities, business impact, compliance duties, operating capability, and cost. A CISSP-level architect should be able to explain why a control belongs in the design, what risk remains, and how the control will be maintained.

Start with the mission of the system. A public marketing site, a hospital medication platform, a trading system, and an industrial controller do not need the same control emphasis. Confidentiality, integrity, availability, privacy, safety, and nonrepudiation compete differently in each environment, and the selected controls should reflect that context.

Controls can be administrative, technical, or physical. Administrative controls include policy, standards, training, vendor requirements, risk acceptance, and change management. Technical controls include access enforcement, encryption, endpoint hardening, network segmentation, vulnerability scanning, and logging. Physical controls include locks, guards, barriers, surveillance, fire suppression, and environmental protections.

Controls also have functional types. Preventive controls try to stop an event, detective controls identify events, corrective controls restore desired conditions, deterrent controls discourage behavior, recovery controls restore service, and compensating controls provide alternate risk reduction when the preferred control is not feasible. Mature designs combine these types instead of relying on one layer.

System security capabilities are the built-in properties that make controls reliable. Secure boot helps ensure trusted firmware and boot components. Hardware roots of trust, TPMs, measured boot, and attestation can support stronger assurance, especially for endpoints, servers, and cloud workloads that must prove their state before receiving access.

Memory protection, process isolation, address space layout randomization, and execution prevention reduce the impact of coding errors and exploitation attempts. These are not substitutes for secure development, but they provide resilience. Security leaders should ask whether high-value workloads run on platforms with modern hardening enabled and monitored.

Trusted paths matter when users or administrators perform sensitive actions. A login prompt, privilege elevation process, or management console must be distinguishable from an imitation. Phishing-resistant authentication, signed administrative tools, hardened jump hosts, and protected management networks all support the idea that critical commands occur through trustworthy channels.

Reference monitors are conceptual enforcement points that mediate access between subjects and objects. For practical architecture, the key properties are always invoked, tamper resistant, and small enough to verify. Modern examples include kernel access checks, hypervisor controls, identity policy engines, API gateways, and storage access policies.

Architecture risk appears where diagrams become too optimistic. A single identity provider may become a systemic failure point. A shared CI/CD runner may become a path into production. A cloud management account may bypass network segmentation. A logging pipeline may collect sensitive data that creates a new privacy and breach exposure.

Risk also appears in inherited trust. If a SaaS platform, managed service, container image, open source library, certificate authority, DNS provider, or outsourced support team is trusted by the architecture, that trust must be deliberate. Contracts, assurance reports, configuration baselines, monitoring, and exit plans help manage what the organization does not directly control.

Use this architecture risk register pattern during design review:

Good control selection includes verification. A design that says encryption is required should identify approved algorithms, key ownership, rotation expectations, exception handling, and where plaintext exists. A design that says logging is required should specify event types, retention, time synchronization, access controls, alerting rules, and privacy constraints.

Compensating controls deserve careful treatment. They are valid when the primary control is infeasible, but they should be documented with scope, rationale, monitoring, expiration, and approval. A compensating control that becomes permanent without review is often a hidden acceptance of risk.

CISSP judgment favors proportionality. Overcontrolling a low-risk system can waste resources and create shadow IT. Undercontrolling a mission-critical system can create unacceptable loss exposure. The security architect should guide stakeholders toward a balanced design that is defensible to auditors, executives, engineers, and operations teams.