This clause provides the discourse on an assurance maintenance paradigm that is supported by the Maintenance of assurance class (AMA). As such it provides helpful information to understand one possible approach to applying the AMA requirements.
Maintenance of assurance is a concept intended to be applied after a TOE has been evaluated and certified against the criteria in clauses 4-5 and 8-14. The maintenance of assurance requirements are aimed at assuring that the TOE will continue to meet its security target as changes are made to the TOE or its environment. Such changes include the discovery of new threats or vulnerabilities, changes in user requirements, the correction of bugs found in the certified TOE, and other updates to the functionality provided.
One way to determine that assurance has been maintained is by a re-evaluation of the TOE. The term 're-evaluation' here refers to an evaluation of a new version of the TOE that addresses all security relevant changes made to the certified version of the TOE and re-uses previous evaluation results where these are still valid. However, in many cases it is unlikely to be practical to perform a re-evaluation of every new version of the TOE in order to ensure that assurance continues to be maintained.
The main goal of class AMA is therefore to define a set of requirements which can be applied to provide confidence that the assurance established in a TOE is being maintained, without always requiring a formal re-evaluation of new versions of the TOE. Class AMA does not remove entirely the need for re-evaluation. In some cases, changes may be so significant that only a re-evaluation can be relied upon to ensure that assurance has been maintained. The requirements of this class thus have a secondary goal of supporting cost-effective re-evaluation of a TOE when this is necessary.
It should be noted that it is possible to re-evaluate any new version of a TOE against the criteria in clauses 4-5 and 8-14 without any of the AMA requirements having been satisfied. However, class AMA includes requirements which can be used in support of any such re-evaluation.
Maintenance developer and evaluator actions are intended to be applied after the TOE has been evaluated and certified although, as described below, some requirements can be applied at the time of the evaluation. For clarity, the following terms are used in this paradigm description:
a) the certified version of the TOE refers to the version that has been evaluated and certified;
b) the current version of the TOE refers to a version that differs in some respect from the certified version; this could be, for example:
a new release of the TOE
the certified version with patches applied to correct subsequently discovered bugs
the same basic version of the TOE, but on a different hardware or software platform.
The developer and evaluator roles in this class are as described in CC Part 1. However, it is not necessarily the case that the evaluator referred to in the requirements of this class will be the same as that which evaluated the certified version of the TOE.
In order to allow assurance to be maintained in a TOE without always requiring a formal re-evaluation, the requirements in this class place an obligation on the developer to maintain evidence that shows that the TOE continues to satisfy its security target (e.g. evidence of developer testing).
This subclause describes one possible approach to the use of the assurance maintenance families and components, intended to illustrate use of the concepts. The example is modeled on an 'assurance maintenance cycle' that may be divided into the following three phases:
a) the acceptance phase, at the start of a cycle, in which the developer's plans and procedures for assurance maintenance during the cycle are established by the developer and independently validated by an evaluator;
b) the monitoring phase, in which the developer provides at one or more points during the cycle evidence that the assurance in the TOE is being maintained in accordance with the established plans and procedures, this evidence of assurance maintenance being independently checked by an evaluator;
c) the re-evaluation phase, completing the cycle, in which an updated version of the TOE is submitted for a re-evaluation based on the changes affecting the TOE since the certified version.
The families within AMA address primarily the first two of these phases, while providing support for the third. These phases are introduced here simply to help describe the application of the assurance maintenance requirements. There is no intention to mandate an assurance maintenance scheme which formally incorporates these phases.
The assurance maintenance cycle is illustrated in Figure 15.1 below.
In this example, a TOE can enter the monitoring phase only when the acceptance phase has been successfully concluded (i.e. the developer's plans and procedures for assurance maintenance have been accepted). If the developer makes changes to these plans or procedures during the monitoring phase then the TOE will need to re-enter the acceptance phase to get the changes accepted.
During the monitoring phase the developer follows the assurance maintenance plans and procedures, conducting an analysis of the security impact of changes affecting the TOE (security impact analysis). At certain points during this phase, an evaluator independently checks (by means of an audit) the developer's work. The developer is required to ensure that the plans and procedures are followed, and that security impact analysis is performed correctly.
Figure 15.1 - Example assurance maintenance cycle
Therefore, once a TOE is in the monitoring phase, it becomes possible to have confidence that the assurance in the TOE has been maintained for new versions of the TOE produced by the developer.
A TOE that is subject to change would not continue in the monitoring phase for an indefinite period: at some point a re-evaluation of the TOE would be necessary. The decision as to when a re-evaluation would be required is dependent on cumulative changes to the TOE as well as especially significant changes. For example, a large number of minor changes could have an impact on assurance equivalent to that of a major change. The developer's assurance maintenance plan defines the scope of the changes that may be made to the TOE during the monitoring phase (see subclause 15.3.1 below).
In a similar way, it would not possible to 'uprate' a TOE (i.e. increase the assurance level) during the monitoring phase: this could only be achieved by means of an evaluation of the TOE (making appropriate reuse of previous evaluation results).
The assurance maintenance status of the TOE will have to be reviewed if it is discovered that the assurance maintenance procedures are not being followed, and that as a result assurance in the TOE is undermined. In some cases the developer may be required to submit the TOE for re-evaluation, and afterwards start a new assurance maintenance cycle.
In the example, the TOE acceptance phase of the assurance maintenance cycle can be refined into the following, which uses the assurance maintenance plan and TOE component categorisation report families from the AMA class.
Figure 15.2 - Example TOE acceptance approach
The TOE monitoring phase of the assurance maintenance cycle would be refined into the following, which uses the Evidence of assurance maintenance and Security impact analysis families of the AMA Class.
Figure 15.3 - Example TOE monitoring approach
The third phase of this example maintenance cycle is the re-evaluation phase, in which the evaluator makes use of the impact analysis and evidence of assurance maintenance to re-examine parts of the TOE, using the assurance components applicable for the target assurance level.
Re-evaluation activities would be scheduled in the AM Plan, or could be required in response to unforseen significant changes to the TOE or its environment for which assurance maintenance activities were considered inappropriate.
To support assurance maintenance approaches the class AMA has been developed, and comprises four families as shown in Table 15.1
| 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 AM Plan provides a clear identification of the baseline for assurance maintenance, in terms of the evaluation results and the definition of the categorisation of TOE components.
The Assurance Maintenance Plan (AM Plan) identifies the plans and procedures a developer implements in order to ensure that the assurance that was established in the certified TOE is maintained as changes are made to the TOE or its environment. An AM Plan covers one assurance maintenance cycle.
The AM Plan defines the scope of changes that can be made to the TOE without triggering a re-evaluation. The specific approach to be followed is scheme dependent, but the following types of change are likely to be outside the scope of the AM Plan and thus might only be addressed by means of a re-evaluation:
a) significant changes to the security target (i.e. significant changes to the security environment, security objectives or security functional requirements, or any increase in the assurance requirements);
b) significant changes to external TSF interfaces categorised as TSP-enforcing;
c) (where the assurance requirements include ADV_HLD.1 or higher components) significant changes to TSF subsystems categorised as TSP-enforcing.
It should be noted that the approach to changes made under maintenance may be influenced by any functions provided by the TOE that help support automated validation of the security of the evaluated configuration. Such functions may prevent inappropriate or damaging changes being applied to an operational TOE.
A more precise specification of the rules is outside the scope of the CC, not least because the definition of what constitutes a significant change will be dependent on the type of TOE evaluated, and on the content of the security target.
The AM Plan is required to define or reference the procedures that will be applied to ensure that assurance in the TOE is maintained during the assurance maintenance cycle. Four types of procedure are identified that should be applied:
a) configuration management procedures, controlling and recording changes to the TOE in support of the developer's security impact analysis, as well as supporting documentation (including the AM Plan itself);
b) procedures to maintain `assurance evidence' (i.e. the maintenance of documentary evidence as required by the appropriate assurance requirements), a key aspect of which is functional testing of the security functions of the TOE, and the developer's regression testing policy in particular;
c) procedures governing the security impact analysis of changes affecting the TOE (Note that this includes changes within the TOE environment, such as new threats or attack methods that may need to be identified and tracked), and the maintenance of the TOE component categorisation report as changes are made;
d) flaw remediation procedures, covering the tracking and correction of reported security flaws (as required by ALC_FLR.1 Basic flaw remediation).
The AM Plan is expected to remain valid until completion of the assurance maintenance cycle (i.e. completion of the scheduled re-evaluation), after which a new AM Plan will be required. The AM Plan is expected to be invalidated if the developer does not follow the plan, or makes changes to the TOE that are outside the scope of the plan, or has to make such changes in order for the TOE to remain effective within its environment. An updated AM Plan should be re-submitted and accepted before a TOE enters a new monitoring phase.
The AM Plan requires the developer to identify a developer security analyst whose responsibility is to monitor the assurance maintenance process. The role may be filled by more than one individual. The developer security analyst is required to be familiar with the TOE, the evaluation results and applicable assurance requirements as an essential prerequisite for fulfilling the role. The requirements do not specify how this level of knowledge and experience should be gained; however, it is likely that a prospective developer security analyst will have to undergo some form of training programme to address any deficiencies in his or her knowledge and experience. The developer security analyst needs to have sufficient authority within the developer's organisation to ensure that the requirements of the AM Plan and its associated procedures are followed.
The aim of the TOE component categorisation report is to complement the AM Plan by providing 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, and also for the subsequent re-evaluation of the TOE.
The checking of the TOE component categorisation report occurs during the acceptance phase; the evaluator checks are applied only in respect of the version of the report for the certified version of the TOE. While the assurance maintenance procedures identified in the AM Plan require the developer to update the TOE component categorisation report as changes are made to the TOE, the evaluators are not required to re-review the document; however, any such updates are likely to be inspected during the monitoring phase.
The TOE component categorisation report covers all TSF representations for the level of assurance being maintained. The TOE component categorisation report also identifies:
a) any hardware, firmware or software components that are external to the TOE (e.g. hardware or software platforms), and that satisfy IT security requirements as defined in the ST;
b) any development tools that, if modified, will have an impact on the required assurance that the TOE satisfies its ST.
The TOE component categorisation report also provides a description of the approach used for the categorisation of TOE components. As a minimum, TOE components are required to be categorised as either TSP-enforcing or non-TSP-enforcing. The description of the categorisation scheme is intended to enable the developer security analyst to decide the category to which any new TOE component should be assigned, and also when to change the category of an existing TOE component following changes to the TOE or its ST.
The initial categorisation of the components of the TOE will be based on evidence provided by the developer in support of the evaluation of the TOE, independently validated by the evaluators. Although maintenance of the document is the responsibility of the developer security analyst, its initial contents may be based on the results of the evaluation of the TOE.
It may be useful for the ST to include AMA_CAT.1 where there is a requirement that assurance be maintained in future versions of the TOE. This applies irrespective of whether assurance maintenance is to be achieved by application of the requirements in this class, or by periodic re-evaluations of the TOE.
Confidence needs to be established that the assurance in the TOE is being maintained by the developer, in accordance with the AM Plan. This is achieved through the provision of evidence that demonstrates that the assurance in the TOE has been maintained, which is independently checked by an evaluator. This check (termed an `AM audit') would typically be applied periodically during the monitoring phase of the TOE's assurance maintenance cycle.
AM audits are conducted in accordance with the schedule defined in the AM Plan. The developer and evaluator actions required by AMA_EVD.1 will therefore be invoked one or more times during the monitoring phase of the assurance maintenance cycle. The evaluators may need to visit the TOE development environment to examine the required evidence, but other ways of performing the checks are not precluded.
The developer is required to provide evidence that the assurance maintenance procedures referred to in the AM Plan are being followed. This will include:
a) configuration management records;
b) documentation referenced by the security impact analysis, including the current version of the TOE component categorisation report, and evidence for all applicable assurance requirements such as design updates, test documentation, new versions of guidance documents, and so on;
c) evidence of the tracking of security flaws.
The evaluator's check of the developer's security impact analysis (required by AMA_SIA.1 on which AMA_EVD.1 depends) will act as a focus for the AM audit. The AM audit will, in turn, provide corroboration of the developer's analysis (and hence confidence in the quality of the analysis), thereby serving to validate the developer's claim that assurance has been maintained in the current version of the TOE.
An AM audit requires the evaluators to confirm that functional testing has been performed on the current version of the TOE. This is highlighted as a separate check because test documentation provides firm evidence that the TOE security functions continue to operate as specified. The evaluators sample the test documentation to confirm that the developer testing shows that the security functions operate as specified, and that the coverage and depth of testing is commensurate with the level of assurance being maintained.
The aim of the security impact analysis is to provide 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 certified. These requirements may be applied during a monitoring phase or a re-evaluation phase.
The developer's security impact analysis is based on the TOE component categorisation report: changes to TSP-enforcing TOE components may have an impact on the assurance that the TOE continues to meet its ST following the changes. All such changes therefore require an analysis of their security impact to show that they do not undermine assurance in the TOE.
The components in this family may be used in support of either a subsequent AM audit or a re-evaluation of the TOE.
For an AM audit, the evaluators' review of the security impact analysis should act as a focus for the subsequent audit activities, which should in turn provide corroboration of the developer's analysis.
The security impact analysis identifies the changes from the certified version of the TOE, in terms of the TOE components which are either new, or which have been modified. The evaluators check the accuracy of this information during either the associated AM audit, or the associated re-evaluation of the TOE.
Provision of the security impact analysis in support of a re-evaluation should reduce the level of evaluator effort needed to establish the required level of assurance in the TOE. Application of AMA_SIA.2, which requires a full examination of the security impact analysis, is likely to provide maximum benefit to the re-evaluation. The precise detailed conditions under which an evaluation authority might wish the security impact analysis to be used in practice in a re-evaluation are beyond the scope of the CC.