Selecting controls and evaluating systems: requirements, Common Criteria and authorization in the US

Sub-domain 3.3 asks you to select controls based on systems security requirements. Behind that short phrase sits a whole discipline: turning business needs and risks into security requirements, choosing controls that meet them, gaining independent assurance that products and systems actually provide those controls, and formally accepting the remaining risk before a system goes live. This lesson walks through that path, from requirements to evaluation schemes such as the Common Criteria to the authorization processes governments use, and shows how a private organization can borrow the same ideas.

From requirements to controls

Security requirements come from several sources. Business requirements describe what the system must do and how critical it is. Legal and regulatory requirements, such as privacy laws or payment card rules, impose specific obligations. Contractual requirements come from customers and partners. Risk assessments identify threats that must be reduced to an acceptable level. And organizational policies and standards set baseline expectations, such as encryption of all laptops. Good requirements are specific and testable: users must authenticate with phishing-resistant multifactor authentication before accessing customer records is a requirement; the system must be secure is not.

Requirements are usually split into functional and assurance requirements. Functional requirements describe what security features the system must have, such as audit logging, role-based access or encryption. Assurance requirements describe how much confidence we need that those features work correctly, which drives the depth of design review, testing, documentation and independent evaluation. A low-risk internal wiki may need only basic functional controls and vendor testing; a system that protects classified information or controls a power grid needs high assurance, and much more evidence.

Controls are then chosen from a catalog to meet the requirements. Common catalogs include NIST Special Publication 800-53, ISO/IEC 27002, the CIS Critical Security Controls and, in Canada, the Canadian Center for Cyber Security's ITSG-33 control catalog, which is closely based on NIST 800-53. Architects start from a baseline matched to the system's categorization and then tailor it, adding controls for specific threats and removing or replacing controls that do not apply, with documented justification. A compensating control may meet the intent of a required control in a different way, as long as it provides comparable protection.

Evaluation criteria: from the Orange Book to the Common Criteria

How can a buyer know that a firewall or operating system really enforces the security it claims? Governments answered this by creating evaluation criteria and independent laboratories. The first was the United States Trusted Computer System Evaluation Criteria, known as TCSEC or the Orange Book, published by the Department of Defense in 1983 and revised in 1985. It rated systems in divisions from D, minimal protection, through C, discretionary protection, and B, mandatory protection, to A1, verified design. The Orange Book was part of a series of guides known as the Rainbow Series; the Red Book applied it to networks. Europe developed the Information Technology Security Evaluation Criteria, ITSEC, in 1991, which separated functionality from assurance, and Canada published its own Canadian Trusted Computer Product Evaluation Criteria, CTCPEC, in 1993.

These national schemes were merged into the Common Criteria for Information Technology Security Evaluation, standardized as ISO/IEC 15408, with the companion evaluation methodology ISO/IEC 18045. The Common Criteria separate what a product must do from how much assurance is needed. A protection profile states implementation-independent security requirements for a class of products, such as firewalls or smart cards, often written by governments or industry groups. A vendor writes a security target describing exactly what its product, the target of evaluation, claims to do, usually by claiming conformance to a protection profile. Accredited laboratories evaluate the product against the security target, and a national certification body issues a certificate.

Assurance in the Common Criteria was traditionally expressed as evaluation assurance levels from EAL1, functionally tested, to EAL7, formally verified design and tested. Higher levels require more design documentation, more developer testing, more vulnerability analysis and, at the top, formal mathematical methods. Most commercial products are evaluated at EAL2 to EAL4. In recent years many nations have moved away from choosing EALs toward collaborative protection profiles, which set specific security requirements and test activities for a technology type, so a product either meets the profile or does not. The Common Criteria Recognition Arrangement lets certificates issued in one member country be recognized in others, which saves vendors from repeating evaluations.

Product assurance and authorization in the US

In the United States the Common Criteria scheme is run by the National Information Assurance Partnership, NIAP, a partnership of NIST and the National Security Agency. NIAP publishes protection profiles for many product types and maintains a product compliant list; national security systems must generally use NIAP-validated products where a profile exists. Cryptographic modules are validated under the Cryptographic Module Validation Program, run jointly by NIST and the Canadian Center for Cyber Security, against FIPS 140-3. Federal agencies must use validated cryptography to protect sensitive information.

For systems rather than products, federal agencies follow the NIST Risk Management Framework in SP 800-37: categorize the system, select, implement and assess controls from SP 800-53, then an authorizing official formally accepts the residual risk and grants an authorization to operate, followed by continuous monitoring. The Federal Information Security Modernization Act requires this for federal systems. For cloud services, the Federal Risk and Authorization Management Program, FedRAMP, provides a standard assessment that agencies can reuse; its FedRAMP 20x initiative, launched in 2025, aims to speed up authorizations through automation. The Department of Defense adds its own requirements, including the Cybersecurity Maturity Model Certification for contractors.

Certification, accreditation and authorization

Older study materials distinguish certification from accreditation. Certification is the technical evaluation of a system's security features against requirements, producing evidence about how well the controls work. Accreditation, now usually called authorization, is the management decision to accept the residual risk and allow the system to operate. The distinction matters: technical staff can certify, but only an official with the authority and accountability for the risk should authorize. Authorization is not permanent. It may be time-limited, it should be revisited when the system or threat changes significantly, and modern programs replace periodic reauthorization with ongoing authorization based on continuous monitoring. An interim authorization to operate allows a system to run for a limited period while issues are fixed.

Choosing products and services in practice

Private organizations rarely require Common Criteria certificates, but they can still apply the same thinking. Before buying, define security requirements and include them in requests for proposal. Ask for independent evidence: certificates, FIPS 140-3 validation for encryption, SOC 2 Type II reports or ISO/IEC 27001 certification for service providers, and penetration test summaries. Check the scope of any certificate carefully, because a product may have been evaluated only in one configuration or version, and a provider's ISO certificate may cover one data center rather than the service you are buying. Then verify after purchase by configuring the product as it was evaluated and testing it in your own environment.

Thinking like a manager

In scenarios about selecting controls, look for answers that begin with requirements and risk rather than products. When a question asks who accepts residual risk, the answer is a senior official or authorizing official, not the security team or the vendor. When it asks how to gain confidence that a product does what it claims, independent evaluation such as the Common Criteria or validated cryptography is the strongest evidence. And remember that a certificate is only as useful as its scope.

Evaluation is not the end of assurance

A certificate or authorization describes a product or system at a point in time and in a specific configuration. Common Criteria certificates name the evaluated version and the security target's assumptions, such as a trusted administrator or a protected network; deploying a different version, enabling unevaluated features or ignoring those assumptions means the evaluation no longer describes what you run. Validated cryptographic modules similarly must be operated in their approved mode. For this reason, mature programs treat evaluation as one input among several. They read the security target and the evaluation report to understand what was tested, compare the assumptions with their own environment, and record any gaps in the risk assessment. After deployment, continuous monitoring checks that configurations stay within the authorized baseline, that patches do not invalidate critical assumptions, and that new threats are assessed. When significant changes occur, such as a move to a new hosting provider or a major version upgrade, the system owner revisits the authorization rather than relying on the original decision. A manager's answer on the exam usually reflects this: assurance is maintained over the life of a system, not purchased once.