Security TargetEdit

A Security Target is a formal specification used in information security evaluation to describe the security properties of a specific product or system. In frameworks such as the Common Criteria, the Security Target (ST) lays out the scope, the assets to be protected, the threats that must be mitigated, and the criteria against which the product will be tested. The ST is produced by the developer and reviewed by an independent evaluation body to determine whether the product meets the stated security requirements at a given level of assurance. This makes the ST a cornerstone of risk-based procurement, especially for government and critical infrastructure systems.

The purpose of the Security Target is not rhetoric or branding; it is the baseline for objective testing and certification. By documenting the system boundary, security objectives, and the environment in which the system operates, the ST reduces ambiguity and creates a repeatable path from design to evaluation. It also serves as a reference for buyers to compare competing products on a common set of security criteria rather than on marketing claims alone. In practice, an ST anchors the evaluation plan, the tests to be executed, and the evidence that evaluators will review.

Overview

  • What an ST specifies: The Security Target describes the TOE, or Target of Evaluation, and identifies what parts of the system are in scope, what assets are most valuable, and what threats are addressed. It also spells out security objectives for both the user and the system, functional requirements (what the system must do to protect assets) and assurance requirements (how convincingly the system can be shown to meet those requirements). The ST will normally include assumptions about the operating environment, constraints on use, and the boundaries of the evaluated configuration.
  • How it is used: The ST is the primary document that guides testing, analysis, and verification. Evaluators use the ST to design test cases, determine evidence needs (such as engineering drawings, source code, or cryptographic implementations), and judge whether the product meets the stated criteria at a chosen level of assurance, often expressed as an Evaluation Assurance Level (EAL) in CC contexts.
  • Relationship to the TOE and to the evaluation process: The TOE is the subject of evaluation; the ST defines what about the TOE is in scope and what must be demonstrated. The evaluation body assesses whether the compliance claims in the ST are substantiated by testing and analysis.

Structure and Contents

  • Executive description: A concise summary of what the TOE is intended to protect, who will use it, and under what conditions.
  • TOE boundary: A precise delineation of components, interfaces, and operational environments included in the evaluation.
  • Security objectives: High-level goals the TOE must achieve to protect assets, supported by a mapping to lower-level security requirements.
  • Security functional requirements: Concrete functions the TOE must implement to meet its objectives (for example, access control, data confidentiality, integrity checks). These are drawn from established catalogs of requirements used in CC-based evaluations.
  • Security assurance requirements: The processes and evidence required to prove that the TOE meets its security objectives (for instance, design analysis, testing, and vulnerability assessment).
  • Threats, assumptions, and risk context: A description of potential adverse events, assumed attacker capabilities, and the operational environment in which the TOE is expected to operate.
  • Security policies and operational considerations: Any internal rules or procedures that govern secure operation of the TOE.
  • Conformance claims and evidence: The explicit statements about conformance to a Protection Profile or to a set of criteria, along with the supporting documentation and test results.

Relationship to Protection Profiles and the Common Criteria

  • Protection Profiles: A Protection Profile is a repository of security requirements and objectives for a class of devices or applications. When a particular TOE claims conformance to a Protection Profile, the ST should map its own security objectives and requirements to the Profile and show how the TOE satisfies the profile’s expectations. Protection Profiles help align multiple STs with common assurance criteria and streamline procurement.
  • Security Targets and conformance: An ST can assert conformance to a Protection Profile or stand alone if it defines a unique set of requirements. In either case, the ST must provide the evidence needed to verify that the TOE achieves its security objectives at the claimed assurance level.
  • Common Criteria framework: The CC framework provides a structured methodology for defining STs, developing evidence, and conducting evaluation. It emphasizes traceability from security objectives to requirements to test cases, enabling evaluators, buyers, and vendors to speak a common language about security properties and assurance.

Security Target in Procurement and Policy

  • Government and critical infrastructure: STs are widely used in public procurement to specify minimum security expectations for software and hardware products. This helps agencies manage risk, ensure interoperability, and avoid vendor lock-in by providing a transparent, standards-based evaluation framework.
  • Risk-based decision making: By focusing on the threats the system must resist and the assets it must protect, STs support risk-informed budgeting and prioritization for security controls within budgetary constraints.
  • Supply chain considerations: An ST can address supply chain risks by defining requirements for code integrity, build processes, and provenance, thereby improving confidence in distributed products used in national networks.
  • International interoperability: The CC ecosystem promotes cross-border recognition of evaluations. An ST assessed at a given CC level in one jurisdiction can facilitate acceptance in another, reducing duplication of testing and accelerating deployment of secure systems.

Controversies and Debates

  • Costs and complexity: Critics argue that creating precise STs and achieving higher assurance levels can be expensive and slow, potentially delaying innovation. Proponents counter that upfront clarity reduces costly rework later in the lifecycle and lowers long-run risk, especially for critical systems.
  • Paperwork vs. real security: Some observers claim that STs can become bureaucratic artifacts that emphasize documentation over actual security outcomes. Supporters respond that the best STs are tightly linked to verifiable evidence—tests, analyses, and reproducible results—reducing the chance that security claims are unfounded.
  • Standardization vs. flexibility: A debate exists over how rigid CC-based processes should be. Standardization can drive interoperability and vendor competition, but overly prescriptive requirements may impede rapid adaptation to new threats or technologies. Advocates argue that a balanced approach preserves flexibility while maintaining a credible baseline.
  • Privacy, civil liberties, and “woke” criticisms: Critics on the right say that focusing on high-assurance processes like STs protects citizens and critical infrastructure without being bogged down by social-justice critiques that they view as distractions from security outcomes. They argue the core task is risk reduction and defense reliability, not ideological experiments in governance. Proponents of more expansive social considerations contend that security frameworks should address fairness, transparency, and consent, especially in public-sector deployments. From a conservative, risk-management perspective, the counterargument is that Security Target practice is designed to be technically objective and evidence-based, and that allowing politicized or identity-driven concerns to dictate technical requirements can degrade effectiveness. In this view, critics who claim that security frameworks inherently suppress legitimate security improvements can be seen as missing the core function: reducing real-world risk through tested, auditable processes.

International Adoption and Standards

  • Global reach of the CC: The Common Criteria methodology has broad international adoption, with evaluation laboratories and certification bodies operating in multiple regions. The Security Target remains central to how products are assessed, regardless of the country of origin.
  • Alignment with national programs: Many national security and defense programs require STs as part of procurement and export controls, ensuring that traded IT products meet agreed-upon security expectations before deployment in critical sectors.
  • Evolving threats and technology: As technologies advance, STs adapt by updating security objectives, adding relevant functional requirements, and incorporating new assurance practices. This ongoing evolution helps maintain a consistent standard of trust in rapidly changing environments.

See also