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

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 catalogue to meet the requirements. Common catalogues include NIST Special Publication 800-53, ISO/IEC 27002, the CIS Critical Security Controls and, in Canada, the Canadian Centre for Cyber Security's ITSG-33 control catalogue, 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 towards 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 Canada

Canada participates in the Common Criteria through the Canadian Common Criteria Program, run by the Canadian Centre for Cyber Security, part of the Communications Security Establishment. It oversees accredited evaluation facilities and issues certificates that are recognized by other members of the Common Criteria Recognition Arrangement. Cryptographic modules used to protect Government of Canada information are validated under the Cryptographic Module Validation Program, which the Cyber Centre runs jointly with the United States National Institute of Standards and Technology, so the same FIPS 140-3 validation is recognized in both countries.

For systems rather than products, Government of Canada departments follow the Directive on Security Management and the Cyber Centre's IT security risk management guidance, ITSG-33. A system goes through security assessment and authorization: its security controls are assessed against its requirements, residual risks are documented, and a senior official formally accepts those risks and authorizes operation. For cloud services, the Cyber Centre assesses commercial providers against a profile of controls for Protected B data, and departments use those assessments when approving cloud services. Provinces and many private organizations use similar processes, sometimes called security certification and accreditation, even when no law requires them.

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 centre 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 programmes 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.