Security Requirements and Control Selection

From Requirements to Controls: The Governance Bridge

You know what you need to protect (from risk assessment) and you know the principles that should guide your design (from Module 19). The question now is: how do you select specific controls, and how do you know whether a product actually delivers the security it claims? This module covers the frameworks and evaluation criteria that answer those questions.

Security requirements translate business risk into technical specifications. Control selection translates specifications into implementable safeguards. Without both steps, you have either vague intentions or controls that do not match your actual risks.

This module covers CISSP exam objective 3.3: select controls based upon systems security requirements, and the evaluation criteria that help you assess whether those controls are adequate.

Security Requirements Analysis

Before selecting any control, you need to define what “secure enough” means for the specific system. Security requirements come from multiple sources:

• Regulatory requirements — Laws and regulations that mandate specific protections (HIPAA, PCI DSS, GDPR, SOX)
• Contractual obligations — Service level agreements, client contracts, and partner agreements that specify security expectations
• Organizational policy — Internal standards that define minimum security posture based on risk appetite
• Risk assessment results — Identified threats and vulnerabilities that require mitigation
• Industry standards — Best practices and frameworks (NIST, ISO 27001, CIS Controls) that define expected security levels

Requirements should be specific, measurable, and traceable. “The system must be secure” is not a requirement. “The system must encrypt all data in transit using TLS 1.2 or higher” is a requirement. Each requirement should trace back to a risk, regulation, or business need.

Common Criteria (ISO/IEC 15408)

The Common Criteria is an international standard for evaluating IT product security. It provides a structured way to specify security requirements and evaluate whether products meet them. If you are selecting a firewall, an operating system, or an encryption module, Common Criteria tells you how rigorously that product has been tested.

Key Components

• Target of Evaluation (TOE) — The product or system being evaluated
• Protection Profile (PP) — A document that defines security requirements for a category of products. Think of it as a template: “here is what any firewall needs to do.” Created by customers or user groups, not vendors.
• Security Target (ST) — A document created by the vendor that describes what their specific product claims to do. The ST maps to a Protection Profile and may include additional claims.
• Security Functional Requirements (SFRs) — The specific security functions the TOE must provide (access control, audit, cryptography)
• Security Assurance Requirements (SARs) — How rigorously the TOE has been tested and verified

Evaluation Assurance Levels (EAL)

EAL levels indicate how thoroughly a product was evaluated, not how secure it is. A higher EAL means more rigorous testing, not necessarily better security.

• EAL 1 — Functionally tested. The product works as documented. Minimal assurance.
• EAL 2 — Structurally tested. Design documentation is reviewed.
• EAL 3 — Methodically tested and checked. Development environment is examined.
• EAL 4 — Methodically designed, tested, and reviewed. Source code review included. This is the highest level that is economically feasible for commercial products.
• EAL 5 — Semi-formally designed and tested. Formal analysis techniques begin.
• EAL 6 — Semi-formally verified design and tested.
• EAL 7 — Formally verified design and tested. The highest level, requiring mathematical proof of the design. Extremely expensive and rare.

The management-level takeaway: EAL 4 is the practical ceiling for most commercial procurements. Anything above EAL 4 involves formal methods and dramatically increased cost. When the exam presents a scenario about product procurement and evaluation, EAL 4 is the answer for “highest commercially practical assurance.”

Protection Profiles vs. Security Targets

This distinction appears frequently on the exam:

• Protection Profile (PP) — Written by the customer or industry group. Defines what security capabilities a category of products should have. It is vendor-neutral. Example: “All firewalls purchased by this agency must support stateful inspection, logging, and the ability to deny traffic by default.”
• Security Target (ST) — Written by the vendor. Describes what their specific product does and claims to do. It references the relevant PP and may exceed it. Example: “Our firewall product meets all PP requirements and additionally supports deep packet inspection.”

The PP sets the bar. The ST describes how a specific product meets (or exceeds) that bar. During procurement, you compare the vendor’s ST against your required PP to determine if the product is suitable.

Control Baselines

A control baseline is a starting set of security controls recommended for a system based on its risk categorization. Rather than selecting controls from scratch for every system, you start with a baseline and adjust.

NIST SP 800-53 defines three baselines tied to system impact levels from FIPS 199:

• Low baseline — For systems where a breach would have limited adverse effect. Fewer controls, less stringent configurations.
• Moderate baseline — For systems where a breach would have serious adverse effect. The most commonly applied baseline in government environments.
• High baseline — For systems where a breach would have severe or catastrophic adverse effect. The most controls and strictest configurations.

The baseline provides a starting point, not a final answer. Two additional processes refine the baseline for your specific environment.

Scoping and Tailoring

Baselines are generic. Your systems are specific. Scoping and tailoring bridge that gap.

Scoping

Scoping determines which controls from the baseline apply to your specific system. Not every control is relevant to every system.

• A system that does not process personally identifiable information (PII) may scope out privacy-specific controls
• A system with no wireless connectivity may scope out wireless security controls
• An air-gapped system may scope out internet-facing controls

Scoping is a documented decision: you record which controls you removed and why.

Tailoring

Tailoring modifies the remaining controls to fit your specific environment. This might mean:

• Adjusting control parameters (e.g., changing password length from 8 to 12 characters based on organizational policy)
• Adding supplemental controls not in the baseline but required by your risk assessment
• Specifying implementation details appropriate to your technology stack

The key exam distinction: scoping removes controls that do not apply; tailoring adjusts controls that do apply. Both require documentation and justification.

Compensating Controls

Sometimes you cannot implement the prescribed control. The system is too old, the technology does not support it, or the cost is disproportionate to the risk. A compensating control is an alternative control that provides equivalent protection.

A valid compensating control must:

• Address the same risk as the original control
• Provide equivalent or greater protection — not merely a token effort
• Be documented with a justification for why the original control cannot be implemented
• Be reviewed periodically to determine if the original control can be restored

Example: A legacy system cannot support multi-factor authentication. A compensating control might be network segmentation to isolate the system, enhanced monitoring of all access attempts, and a shorter password rotation cycle. This combination addresses the same risk (unauthorized access) through different means.

Compensating controls are not a permanent excuse. They are a documented, risk-based decision that should be revisited when conditions change — such as a system upgrade that can now support the original control.

Pattern Recognition

Security requirements and control selection questions on the CISSP follow these structures:

• Common Criteria terminology — A question gives you a scenario about product evaluation and asks you to identify the correct term (PP, ST, TOE, EAL). Match the definition to the scenario context.
• EAL level selection — The question asks which EAL is appropriate for a given situation. For commercial products, EAL 4 is the practical maximum. For military/intelligence systems, higher EALs may be specified.
• Baseline adjustment — A system is categorized at a certain impact level, but specific controls do not apply or need modification. You identify whether the adjustment is scoping (removing) or tailoring (modifying).
• Compensating control validity — A scenario describes an alternative control. You determine whether it is a valid compensating control based on whether it addresses the same risk with equivalent protection.

Trap Patterns

Watch for these wrong answers:

• “Higher EAL means more secure” — EAL measures evaluation rigor, not security strength. An EAL 7 product with poor security requirements is less useful than an EAL 4 product with strong ones. The Security Target defines what the product does; EAL defines how thoroughly that claim was tested.
• Confusing Protection Profile with Security Target — PP comes from the customer side (what we need). ST comes from the vendor side (what we provide). If the scenario describes requirements from a buyer, it is a PP. If it describes claims from a vendor, it is an ST.
• “Scoping means weakening security” — Scoping removes controls that are genuinely not applicable. Removing wireless controls from a system with no wireless capability is not weakening security — it is accurate control selection.
• “Any alternative is a compensating control” — A compensating control must address the same risk with equivalent protection. Simply choosing a cheaper or easier control that addresses a different risk does not qualify.
• Treating baselines as mandatory without adjustment — Baselines are starting points. Applying every control from a baseline without scoping and tailoring is wasteful and may miss environment-specific risks that the baseline does not cover.

Scenario Practice

Question 1

A government agency is procuring a new intrusion detection system. The agency has published a document specifying the security functions that any IDS product must provide, including real-time alerting, log integrity, and tamper-resistant configuration storage. Several vendors have submitted proposals referencing this document.

What Common Criteria component did the agency publish?

A. Security Target
B. Target of Evaluation
C. Protection Profile
D. Evaluation Assurance Level

Question 2

An organization categorizes its payroll system as moderate impact under FIPS 199. The security team selects the NIST 800-53 moderate baseline. During implementation, they discover that several controls related to wireless access are included in the baseline, but the payroll system operates on a physically isolated wired network with no wireless components.

What process should the team apply?

A. Tailoring — modify the wireless controls to apply to the wired network
B. Scoping — remove the wireless controls with documentation explaining they are not applicable
C. Apply the wireless controls anyway to maintain baseline compliance
D. Implement compensating controls to replace the wireless security requirements

Question 3

A healthcare organization must implement multi-factor authentication for access to its electronic health records system per regulatory requirements. The legacy EHR system does not support MFA natively. A system replacement is planned for next year. In the interim, the security team proposes placing the EHR behind a VPN that requires MFA, restricting access to specific IP ranges, and implementing enhanced audit logging of all access attempts.

Is this a valid compensating control approach?

A. No — the regulation requires MFA on the EHR system itself, not on a surrounding system
B. No — compensating controls are not permitted for regulatory requirements
C. Yes — the combination addresses the same unauthorized access risk with equivalent protection and is documented with a remediation timeline
D. Yes — any additional security control counts as a compensating control

Key Takeaway

Control selection is a structured process, not a guessing game. Start with requirements (what must be protected and why), use evaluation criteria like Common Criteria to verify product claims, select a baseline matched to the system’s risk level, scope and tailor to fit the specific environment, and document compensating controls when the prescribed approach is not feasible. Every step produces documentation. The exam rewards candidates who understand this as a governance process with traceable decisions, not as a technical shopping exercise.