Раздел: Документация
0 ... 64 65 66 67 68 69 70 ... 73 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 AMACAT.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. 15.3.3 Evidence of assurance maintenance 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 TOEs assurance maintenance cycle. AM audits are conducted in accordance with the schedule defined in the AM Plan. The developer and evaluator actions required by AMAEVD.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 evaluators check of the developers 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 developers analysis (and hence confidence in the quality of the analysis), thereby serving to validate the developers 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. 15.3.4 Security impact analysis 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 developers 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 developers 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 ISO/IEC 15408. 0 ... 64 65 66 67 68 69 70 ... 73
|
