The following sections describe the constructs used in representing the assurance classes, families, components, and EALs along with the relationships among them.
Figure 2.1 illustrates the assurance requirements defined in this CC Part 3. Note that the most abstract collection of assurance requirements is referred to as a class. Each class contains assurance families, which then contain assurance components, which in turn contain assurance elements. Classes and families are used to provide a taxonomy for classifying assurance requirements, while components are used to specify assurance requirements in a PP/ST.
Figure 2.1 illustrates the assurance class structure.
Each assurance class is assigned a unique name. The name indicates the topics covered by the assurance class.
A unique short form of the assurance class name is also provided. This is the primary means for referencing the assurance class. The convention adopted is an "A" followed by two letters related to the class name.
Each assurance class has an introductory section that describes the composition of the class and contains supportive text covering the intent of the class.
Each assurance class contains at least one assurance family. The structure of the assurance families is described in the following subclause.
Figure 2.1 - Assurance class/family/component/element hierarchy
Figure 2.1 illustrates the assurance family structure.
Every assurance family is assigned a unique name. The name provides descriptive information about the topics covered by the assurance family. Each assurance family is placed within the assurance class that contains other families with the same intent.
A unique short form of the assurance family name is also provided. This is the primary means used to reference the assurance family. The convention adopted is that the short form of the class name is used, followed by an underscore, and then three letters related to the family name.
The objectives section of the assurance family presents the intent of the assurance family.
This section describes the objectives, particularly those related to the CC assurance paradigm, that the family is intended to address. The description for the assurance family is kept at a general level. Any specific details required for objectives are incorporated in the particular assurance component.
Each assurance family contains one or more assurance components. This subclause of the assurance family describes the components available and explains the distinctions between them. Its main purpose is to differentiate between the assurance components once it has been determined that the assurance family is a necessary or useful part of the assurance requirements for a PP/ST.
Assurance families containing more than one component are levelled and rationale is provided as to how the components are levelled. This rationale is in terms of scope, depth, and/or rigour.
The application notes section of the assurance family, if present, contains additional information for the assurance family. This information should be of particular interest to users of the assurance family (e.g. PP and ST authors, designers of TOEs, evaluators). The presentation is informal and covers, for example, warnings about limitations of use and areas where specific attention may be required.
Each assurance family has at least one assurance component. The structure of the assurance components is provided in the following subclause.
Figure 2.2 illustrates the assurance component structure.
Figure 2.2 - Assurance component structure
The relationship between components within a family is highlighted using a bolding convention. Those parts of the requirements that are new, enhanced or modified beyond the requirements of the previous component within a hierarchy are bolded. The same bolding convention is also used for dependencies.
The component identification section provides descriptive information necessary to identify, categorise, register, and reference a component.
Every assurance component is assigned a unique name. The name provides descriptive information about the topics covered by the assurance component. Each assurance component is placed within the assurance family that shares its security objective.
A unique short form of the assurance component name is also provided. This is the primary means used to reference the assurance component. The convention used is that the short form of the family name is used, followed by a period, and then a numeric character. The numeric characters for the components within each family are assigned sequentially, starting from 1.
The objectives subclause of the assurance component, if present, contains specific objectives for the particular assurance component. For those assurance components that have this subclause, it presents the specific intent of the component and a more detailed explanation of the objectives.
The application notes subclause of an assurance component, if present, contains additional information to facilitate the use of the component.
Dependencies among assurance components arise when a component is not self-sufficient, and relies upon the presence of another component.
Each assurance component provides a complete list of dependencies to other assurance components. Some components may list "No dependencies", to indicate that no dependencies have been identified. The components depended upon may have dependencies on other components.
The dependency list identifies the minimum set of assurance components which are relied upon. Components which are hierarchical to a component in the dependency list may also be used to satisfy the dependency.
In specific situations the indicated dependencies might not be applicable. The PP/ST author, by providing rationale for why a given dependency is not applicable, may elect not to satisfy that dependency.
A set of assurance elements is provided for each assurance component. An assurance element is a security requirement which, if further divided, would not yield a meaningful evaluation result. It is the smallest security requirement recognised in the CC.
Each assurance element is identified as belonging to one of the three sets of assurance elements:
a) Developer action elements: the activities that shall be performed by the developer. This set of actions is further qualified by evidential material referenced in the following set of elements. Requirements for developer actions are identified by appending the letter "D" to the element number.
b) Content and presentation of evidence elements: the evidence required, what the evidence shall demonstrate, and what information the evidence shall convey. Requirements for content and presentation of evidence are identified by appending the letter "C" to the element number.
c) Evaluator action elements: the activities that shall be performed by the evaluator. This set of actions explicitly includes confirmation that the requirements prescribed in the content and presentation of evidence elements have been met. It also includes explicit actions and analysis that shall be performed in addition to that already performed by the developer. Implicit evaluator actions are also to be performed as a result of developer action elements which are not covered by content and presentation of evidence requirements. Requirements for evaluator actions are identified by appending the letter "E" to the element number.
The developer actions and content and presentation of evidence define the assurance requirements that are used to represent a developer's responsibilities in demonstrating assurance in the TOE security functions. By meeting these requirements, the developer can increase confidence that the TOE satisfies the functional and assurance requirements of a PP or ST.
The evaluator actions define the evaluator's responsibilities in the two aspects of evaluation. The first aspect is validation of the PP/ST, in accordance with the classes APE and ASE in chapters 4 and 5. The second aspect is verification of the TOE's conformance with its functional and assurance requirements. By demonstrating that the PP/ST is valid and that the requirements are met by the TOE, the evaluator can provide a basis for confidence that the TOE will meet its security objectives.
The developer action elements, content and presentation of evidence elements, and explicit evaluator action elements, identify the evaluator effort that shall be expended in verifying the security claims made in the ST of the TOE.
Each element represents a requirement to be met. These statements of requirements are intended to be clear, concise, and unambiguous. Therefore, there are no compound sentences: each separable requirement is stated as an individual element.
The elements have been written using the normal dictionary meaning for the terms used, rather than using a number of predefined terms as shorthand which results in implicit requirements. Therefore, elements are written as explicit requirements, with no reserved terms.
In contrast to Part 2, neither assignment nor selection operations are relevant for elements in Part 3 of the CC; however, refinements may be made to Part 3 elements as required.
Figure 2.3 illustrates the EALs and associated structure defined in this Part 3. Note that while the figure shows the contents of the assurance components, it is intended that this information would be included in an EAL by reference to the actual components defined in the CC.
Each EAL is assigned a unique name. The name provides descriptive information about the intent of the EAL.
A unique short form of the EAL name is also provided. This is the primary means used to reference the EAL.
The objectives section of the EAL presents the intent of the EAL.
The application notes section of the EAL, if present, contains information of particular interest to users of the EAL (e.g. PP and ST authors, designers of TOEs targeting this EAL, evaluators). The presentation is informal and covers, for example, warnings about limitations of use and areas where specific attention may be required.
Figure 2.3 - EAL structure
Figure 2.4 - Assurance and assurance level association
A set of assurance components have been chosen for each EAL.
A higher level of assurance than that provided by a given EAL can be achieved by:
a) including additional assurance components from other assurance families; or
b) replacing an assurance component with a higher level assurance component from the same assurance family.
Figure 2.4 illustrates the relationship between the assurance requirements and the assurance levels defined in the CC. While assurance components further decompose into assurance elements, assurance elements cannot be individually referenced by assurance levels. Note that the arrow in the figure represents a reference from an EAL to an assurance component within the class where it is defined.
This Part 3 contains classes of families and components that are grouped on the basis of related assurance. At the start of each class is a diagram that indicates the families in the class and the components in each family.
Figure 2.5 - Sample class decomposition diagram
In Figure 2.5, above, the class as shown contains a single family. The family contains three components that are linearly hierarchical (i.e. component 2 requires more than component 1, in terms of specific actions, specific evidence, or rigour of the actions or evidence). The assurance families in this Part 3 are all linearly hierarchical, although linearity is not a mandatory criterion for assurance families that may be added in the future.
The requirements for protection profile and security target evaluation are treated as assurance classes and are presented using the similar structure as that used for the other assurance classes, described below. One notable difference is the absence of a component levelling section in the associated family descriptions. The reason is that each family has only a single component and therefore no levelling has occurred.
Tables 3.1, 3.2, 3.3 and 3.2 in clause 3 of this Part 3 summarise, for both the APE and ASE classes, their constituent families and abbreviations for each. Narrative summaries for the APE families can be found in CC Part 1, annex B, subclauses B.2.2 through B.2.8, whereas narrative summaries for the ASE families can be found in CC Part 1, annex C, subclauses C.2.2 through C.2.9.
The following is a list of terms which are used in a precise way in this Part 3. They do not merit inclusion in the glossary because they are general English terms and their usage, though restricted to the explanations given below, is in conformance with dictionary definitions. However, those explanations of the terms were used as guidance in the development of this Part 3 and should be helpful for general understanding.
Check -- This term is similar to, but less rigourous than "confirm" or "verify". This term requires a quick determination to be made by the evaluator, perhaps requiring only a cursory analysis, or perhaps no analysis at all.
Coherent -- An entity is logically ordered and has a discernible meaning. For documentation, this addresses both the actual text and the structure of the document, in terms of whether it is understandable by its target audience.
Complete -- All necessary parts of an entity have been provided. In terms of documentation, this means that all relevant information is covered in the documentation, at such a level of detail that no further explanation is required at that level of abstraction.
Confirm -- This term is used to indicate that something needs to be reviewed in detail, and that an independent determination of sufficiency needs to be made. The level of rigour required depends on the nature of the subject matter. This term is only applied to evaluator actions.
Consistent -- This term describes a relationship between two or more entities, indicating that there are no apparent contradictions between these entities.
Counter (verb) -- This term is typically used in the context that a security objective counters a particular threat, but does not necessarily indicate that the threat is completely eradicated as a result.
Demonstrate -- This term refers to an analysis leading to a conclusion, which is less rigourous than a "proof".
Describe -- This term requires that certain, specific details of an entity be provided.
Determine -- This term requires an independent analysis to be made, with the objective of reaching a particular conclusion. The usage of this term differs from "confirm" or "verify", since these other terms imply that an analysis has already been performed which needs to be reviewed, whereas the usage of "determine" implies a truly independent analysis, usually in the absence of any previous analysis having been performed.
Ensure -- This term, used by itself, implies a strong causal relationship between an action and its consequences. This term is typically preceded by the word "helps", which indicates that the consequence is not fully certain, on the basis of that action alone.
Exhaustive -- This term is used in the CC with respect to conducting an analysis or other activity. It is related to "systematic" but is considerably stronger, in that it indicates not only that a methodical approach has been taken to perform the analysis or activity according to an unambiguous plan, but that the plan that was followed is sufficient to ensure that all possible avenues have been exercised.
Explain -- This term differs from both "describe" and "demonstrate". It is intended to answer the question "Why?" without actually attempting to argue that the course of action that was taken was necessarily optimal.
Internally consistent -- There are no apparent contradictions between any aspects of an entity. In terms of documentation, this means that there can be no statements within the documentation that can be taken to contradict each other.
Justification -- This term refers to an analysis leading to a conclusion, but is more rigorous than a demonstration. This term requires significant rigour in terms of very carefully and thoroughly explaining every step of a logical argument.
Mutually supportive -- This term describes a relationship between a group of entities, indicating that the entities possess properties which do not conflict with, and may assist the other entities in performing their tasks. It is not necessary to determine that every individual entity in question directly supports other entities in that grouping; rather, it is a more general determination that is made.
Prove -- This refers to a formal analysis in its mathematical sense. It is completely rigourous in all ways. Typically, "prove" is used when there is a desire to show correspondence between two TSF representations at a high level of rigour.
Specify -- This term is used in the same context as "describe", but is intended to be more rigourous and precise. It is very similar to "define".
Trace (verb) -- This term is used to indicate that an informal correspondence is required between two entities with only a minimal level of rigour.
Verify -- This term is similar in context to "confirm", but has more rigourous connotations. This term when used in the context of evaluator actions indicates that an independent effort is required of the evaluator.
The assurance classes, families, and the abbreviation for each family are shown in Table 2.1.
| Assurance Class |
Assurance Family |
Abbreviated Name |
|---|---|---|
| Class ACM: Configuration management |
CM automation | ACM_AUT |
| CM capabilities | ACM_CAP | |
| CM scope | ACM_SCP | |
| Class ADO: Delivery and operation |
Delivery | ADO_DEL |
| Installation, generation and start-up | ADO_IGS | |
| Class ADV: Development |
Functional specification | ADV_FSP |
| High-level design | ADV_HLD | |
| Implementation representation | ADV_IMP | |
| TSF internals | ADV_INT | |
| Low-level design | ADV_LLD | |
| Representation correspondence | ADV_RCR | |
| Security policy modeling | ADV_SPM | |
| Class AGD: Guidance documents |
Administrator guidance | AGD_ADM |
| User guidance | AGD_USR | |
| Class ALC: Life cycle support |
Development security | ALC_DVS |
| Flaw remediation | ALC_FLR | |
| Life cycle definition | ALC_LCD | |
| Tools and techniques | ALC_TAT | |
| Class ATE: Tests |
Coverage | ATE_COV |
| Depth | ATE_DPT | |
| Functional tests | ATE_FUN | |
| Independent testing | ATE_IND | |
| Class AVA: Vulnerability assessment |
Covert channel analysis | AVA_CCA |
| Misuse | AVA_MSU | |
| Strength of TOE security functions | AVA_SOF | |
| Vulnerability analysis | AVA_VLA |
The following summarises the assurance classes and families of clauses 8-14. These classes and family summaries are presented in the same order as they appear in clauses 8-14.
Configuration management (CM) helps to ensure that the integrity of the TOE is preserved, by requiring discipline and control in the processes of refinement and modification of the TOE and other related information. CM prevents unauthorised modifications, additions, or deletions to the TOE, thus providing assurance that the TOE and documentation used for evaluation are the ones prepared for distribution.
Configuration management automation establishes the level of automation used to control the configuration items.
Configuration management capabilities define the characteristics of the configuration management system.
Configuration management scope indicates the TOE items that need to be controlled by the configuration management system.
Assurance class ADO defines requirements for the measures, procedures, and standards concerned with secure delivery, installation, and operational use of the TOE, ensuring that the security protection offered by the TOE is not compromised during transfer, installation, start-up, and operation.
Delivery covers the procedures used to maintain security during transfer of the TOE to the user, both on initial delivery and as part of subsequent modification. It includes special procedures or operations required to demonstrate the authenticity of the delivered TOE. Such procedures and measures are the basis for ensuring that the security protection offered by the TOE is not compromised during transfer. While compliance with the delivery requirements cannot always be determined when a TOE is evaluated, it is possible to evaluate the procedures that a developer has developed to distribute the TOE to users.
Installation, generation, and start-up requires that the copy of the TOE is configured and activated by the administrator to exhibit the same protection properties as the master copy of the TOE. The installation, generation, and start-up procedures provide confidence that the administrator will be aware of the TOE configuration parameters and how they can affect the TSF.
Assurance class ADV defines requirements for the stepwise refinement of the TSF from the TOE summary specification in the ST down to the actual implementation. Each of the resulting TSF representations provide information to help the evaluator determine whether the functional requirements of the TOE have been met.
The functional specification describes the TSF, and must be a complete and accurate instantiation of the TOE security functional requirements. The functional specification also details the external interface to the TOE. Users of the TOE are expected to interact with the TSF through this interface.
The high-level design is a top level design specification that refines the TSF functional specification into the major constituent parts of the TSF. The high level design identifies the basic structure of the TSF and the major hardware, firmware, and software elements.
The implementation representation is the least abstract representation of the TSF. It captures the detailed internal workings of the TSF in terms of source code, hardware drawings, etc., as applicable.
The TSF internals requirements specify the requisite internal structuring of the TSF.
The low-level design is a detailed design specification that refines the high-level design into a level of detail that can be used as a basis for programming and/or hardware construction.
The representation correspondence is a demonstration of mappings between all adjacent pairs of available TSF representations, from the TOE summary specification through to the least abstract TSF representation that is provided.
Security policy models are structured representations of security policies of the TSP, and are used to provide increased assurance that the functional specification corresponds to the security policies of the TSP, and ultimately to the TOE security functional requirements. This is achieved via correspondence mappings between the functional specification, the security policy model, and the security policies that are modelled.
Assurance class AGD defines requirements directed at the understandability, coverage and completeness of the operational documentation provided by the developer. This documentation, which provides two categories of information, for users and for administrators, is an important factor in the secure operation of the TOE.
Requirements for administrative guidance help ensure that the environmental constraints can be understood by administrators and operators of the TOE. Administrative guidance is the primary means available to the developer for providing the TOE administrators with detailed, accurate information of how to administer the TOE in a secure manner and how to make effective use of the TSF privileges and protection functions.
Requirements for user guidance help ensure that users are able to operate the TOE in a secure manner (e.g. the usage constraints assumed by the PP or ST must be clearly explained and illustrated). User guidance is the primary vehicle available to the developer for providing the TOE users with the necessary background and specific information on how to correctly use the TOE's protection functions. User guidance must do two things. First, it needs to explain what the user-visible security functions do and how they are to be used, so that users are able to consistently and effectively protect their information. Second, it needs to explain the user's role in maintaining the TOE's security.
Assurance class ALC defines requirements for assurance through the adoption of a well defined life-cycle model for all the steps of the TOE development, including flaw remediation procedures and policies, correct use of tools and techniques and the security measures used to protect the development environment.
Development security covers the physical, procedural, personnel, and other security measures used in the development environment. It includes physical security of the development location(s) and controls on the selection and hiring of development staff.
Flaw remediation ensures that flaws discovered by the TOE consumers will be tracked and corrected while the TOE is supported by the developer. While future compliance with the flaw remediation requirements cannot be determined when a TOE is evaluated, it is possible to evaluate the procedures and policies that a developer has in place to track and repair flaws, and to distribute the repairs to consumers.
Life cycle definition establishes that the engineering practices used by a developer to produce the TOE include the considerations and activities identified in the development process and operational support requirements. Confidence in the correspondence between the requirements and the TOE is greater when security analysis and the production of evidence are done on a regular basis as an integral part of the development process and operational support activities. It is not the intent of this component to dictate any specific development process.
Tools and techniques addresses the need to define the development tools being used to analyse and implement the TOE. It includes requirements concerning the development tools and implementation dependent options of those tools.
Assurance class ATE states testing requirements that demonstrate that the TSF satisfies the TOE security functional requirements.
Coverage deals with the completeness of the functional tests performed by the developer on the TOE. It addresses the extent to which the TOE security functions are tested.
Depth deals with the level of detail to which the developer tests the TOE. Testing of security functions is based upon increasing depth of information derived from analysis of the TSF representations.
Functional testing establishes that the TSF exhibits the properties necessary to satisfy the requirements of its ST. Functional testing provides assurance that the TSF satisfies at least the requirements of the chosen functional components. However, functional tests do not establish that the TSF does no more than expected. This family focuses on functional testing performed by the developer.
Independent testing specifies the degree to which the functional testing of the TOE must be performed by a party other than the developer (e.g. a third party). This family adds value by the introduction of tests that are not part of the developers tests.
Assurance class AVA defines requirements directed at the identification of exploitable vulnerabilities. Specifically, it addresses those vulnerabilities introduced in the construction, operation, misuse, or incorrect configuration of the TOE.
Covert channel analysis is directed towards the discovery and analysis of unintended communications channels that can be exploited to violate the intended TSP.
Misuse analysis investigates whether an administrator or user, with an understanding of the guidance documentation, would reasonably be able to determine if the TOE is configured and operating in a manner that is insecure.
Strength of function analysis addresses TOE security functions that are realised by a probabilistic or permutational mechanism (e.g. a password or hash function). Even if such functions cannot be bypassed, deactivated, or corrupted, it may still be possible to defeat them by direct attack. A level or a specific metric may be claimed for the strength of each of these functions. Strength of function analysis is performed to determine whether such functions meet or exceed the claim. For example, strength of function analysis of a password mechanism can demonstrate that the password function meets the strength claim by showing that the password space is sufficiently large.
Vulnerability analysis consists of the identification of flaws potentially introduced in the different refinement steps of the development. It results in the definition of penetration tests through the collection of the necessary information concerning: (1) the completeness of the TSF (does the TSF counter all the postulated threats?) and (2) the dependencies between all security functions. These potential vulnerabilities are assessed through penetration testing to determine whether they could, in practice, be exploitable to compromise the security of the TOE.
The requirements for the maintenance of assurance are treated as an assurance class and are presented using the class structure defined above.
The maintenance of assurance families, and the abbreviation for each family are shown in Table 2.2.
| Assurance Class |
Assurance Family |
Abbreviated Name |
|---|---|---|
| Class AMA: Maintenance of assurance |
Assurance maintenance plan | AMA_AMP |
| TOE component categorisation report | AMA_CAT | |
| Evidence of assurance maintenance | AMA_EVD | |
| Security impact analysis | AMA_SIA |
The following summarises the assurance class and families of clause 16. The class and family summaries are presented in the same order as they appear in clause 16.
Assurance class AMA is aimed at maintaining the level of assurance that the TOE will continue to meet its security target as changes are made to the TOE or its environment. Each of the families in this class identifies developer and evaluator actions that are to be applied after the TOE has been successfully evaluated, although some requirements can be applied at the time of the evaluation.
The assurance maintenance plan identifies the plans and procedures a developer is to implement in order to ensure that the assurance that was established in the evaluated TOE is maintained as changes are made to the TOE or its environment.
The TOE component categorisation report provides a categorisation of the components of a TOE (e.g. TSF subsystems) according to their relevance to security. This categorisation acts as a focus for the developer's security impact analysis.
Evidence of assurance maintenance seeks to establish confidence that the assurance in the TOE is being maintained by the developer, in accordance with the assurance maintenance plan.
Security impact analysis seeks to establish confidence that assurance has been maintained in the TOE through an analysis performed by the developer of the security impact of all changes affecting the TOE since it was evaluated.