Security Target
Common Criteria for Information Technology Security Evaluation, version 3.1 Part 1 (called CC 3.1 or CC) defines the Security Target (ST) as an "implementation-dependent statement of security needs for a specific identified Target of Evaluation (TOE)". In other words, the ST defines boundary and specifies the details of the TOE. In a product evaluation process according to the CC the ST document is provided by the vendor of the product. An ST defines information assurance security and functional requirements for the given information system product, which is called the Target of Evaluation (TOE). An ST is a complete and rigorous description of a security problem in terms of TOE description, threats, assumptions, security objectives, security functional requirements (SFRs), security assurance requirements (SARs), and rationales. The SARs are typically given as a number 1 through 7 called Evaluation Assurance Level (EAL), indicating the depth and rigor of the security evaluation, usually in the form of supporting documentation and testing, that the product meets the SFRs. An ST contains some (but not very detailed) implementation-specific information that demonstrates how the product addresses the security requirements. It may refer to one or more Protection Profiles (PPs). In such a case, the ST must fulfill the generic security requirements given in each of these PPs, and may define further requirements.
Common Criteria for Information Technology Security Evaluation, version 3.1 Part 1 (called CC 3.1 or CC)[1] defines the Security Target (ST) as an "implementation-dependent statement of security needs for a specific identified Target of Evaluation (TOE)". In other words, the ST defines boundary and specifies the details of the TOE. In a product evaluation process according to the CC the ST document is provided by the vendor of the product.
An ST defines information assurance security and functional requirements for the given information system product, which is called the Target of Evaluation (TOE). An ST is a complete and rigorous description of a security problem in terms of TOE description, threats, assumptions, security objectives, security functional requirements (SFRs), security assurance requirements (SARs), and rationales. The SARs are typically given as a number 1 through 7 called Evaluation Assurance Level (EAL), indicating the depth and rigor of the security evaluation, usually in the form of supporting documentation and testing, that the product meets the SFRs.[citation needed]
An ST contains some (but not very detailed) implementation-specific information that demonstrates how the product addresses the security requirements. It may refer to one or more Protection Profiles (PPs). In such a case, the ST must fulfill the generic security requirements given in each of these PPs, and may define further requirements.
Security Target outline
[edit]- Introduction – an overview of what the TOE does, including key features and purpose.
- ST Reference
- TOE Reference
- TOE Overview
- TOE Description
- Conformance Claims – identifies conformance claims for the TOE evaluation.
- CC version conformance claims
- CC Part 2 conformance claims
- CC Part 3 conformance claims
- PP conformance claims – strict conformance or demonstrable conformance
- Security Problem Definition – describes the threats and assumptions about the operational environment. Objective is to demonstrate the security problem intended to be addressed by the TOE and its operational environment.
- Threats – an adverse action performed by a threat agent on an asset. Threat agents are described by aspects such as expertise, resources, opportunity, and motivation.
- Organizational Security Policies (OSP) – OSP is a set of security rules, procedures, or guidelines imposed by an organization in TOEs operational environment.
- Assumptions – made only about the operational environment of the TOE behavior.
- Security Objectives – a concise and abstract statement of the intended solution to the problem specified by the security problem definition. Each security objective must trace back to at least one threat or OSP.
- aspect of security which to achieve is the purpose and objective of using certain mitigation measures, such as confidentiality, integrity, availability, user authenticity, access authorisation, accountability.
- confidentiality, integrity or availability required to support the applicable foundational requirements.-[1] Archived 2018-12-21 at the Wayback Machine
- Security Objectives for the TOE
- Security Objectives for the Operational Environment
- Security Objectives Rationale – a set of justifications that shows that all threats and assumptions are effectively addressed by the security objectives.
- Extended Components Definition – the extended components must consist of measurable and objective elements where conformance can be demonstrated.
- Security Requirements – defines and describes the SFRs from CC Part 2 and SARs from CC Part 3.
- Security Functional Requirements – the SFRs form a clear, unambiguous and well-defined description of the expected security behavior of the TOE.
- Security Assurance Requirements – the SARs form a clear, unambiguous and established description of the expected activities that will be undertaken to gain assurance in the TOE.
- Security Requirements Rationale – the justification for a security objective for the TOE demonstrates that the SFRs are sufficient and necessary.
- TOE Summary Specifications – enables evaluators and potential consumers to gain a general understanding of how the TOE is implemented.
- Security Functions – function of a zone or conduit to prevent unauthorised electronic intervention that can impact or influence the normal functioning of devices and systems within the zone or conduit. TOE summary specification must describe how the TOE meets each SFR.
- TOE Security Specifications – a high-level view of how the developer intends to satisfy each SFR.
See also
[edit]References
[edit]- ^ Common Criteria Portal – http://www.commoncriteriaportal.org/cc/