Раздел: Документация
0 ... 105 106 107 108 109 110 111 ... 117 FPTRCV.1 Manual recovery In the hierarchy of the trusted recovery family, recovery that requires only manual intervention is the least desirable, for it precludes the use of the system in an unattended fashion. User application notes This component is intended for use in TOEs that do not require unattended recovery to a secure state. The requirements of this component reduce the threat of protection compromise resulting from an attended TOE returning to an insecure state after recovery from a failure or other discontinuity. Evaluator application notes It is acceptable for the functions that are available to an authorised user for trusted recovery to be available only in a maintenance mode. Controls should be in place to limit access during maintenance to authorised users. FPTRCV.2 Automated recovery Automated recovery is considered to be more useful than manual recovery, as it allows the machine to operate in an unattended fashion. User application notes The component FPTRCV.2 extends the feature coverage of FPTRCV.1 by requiring that there be at least one automated method of recovery from failure or service discontinuity. It addresses the threat of protection compromise resulting from an unattended TOE returning to an insecure state after recovery from a failure or other discontinuity. Evaluator application notes It is acceptable for the functions that are available to an authorised user for trusted recovery to be available only in a maintenance mode. Controls should be in place to limit access during maintenance to authorised users. For FPTRCV.2.1, it is the responsibility of the developer of the TSF to determine the set of recoverable failures and service discontinuities. It is assumed that the robustness of the automated recovery mechanisms will be verified. Operations Assignment: For FPTRCV.2.2, the PP/ST author should specify the list of failures or other discontinuities for which automated recovery must be possible. FPTRCV.3 Automated recovery without undue loss Automated recovery is considered to be more useful than manual recovery, but it runs the risk of losing a substantial number of objects. Preventing undue loss of objects provides additional utility to the recovery effort. User application notes The component FPTRCV.3 extends the feature coverage of FPTRCV.2 by requiring that there not be undue loss of TSF data or objects within the TSC. At FPTRCV.2, the automated recovery mechanisms could conceivably recover by deleting all objects and returning the TSF to a known secure state. This type of drastic automated recovery is precluded in FPTRCV.3. This component addresses the threat of protection compromise resulting from an unattended TOE returning to an insecure state after recovery from a failure or other discontinuity with a large loss of TSF data or objects within the TSC. Evaluator application notes It is acceptable for the functions that are available to an authorised user for trusted recovery to be available only in a maintenance mode. Controls should be in place to limit access during maintenance to authorised users. It is assumed that the evaluators will verify the robustness of the automated recovery mechanisms. Operations Assignment: For FPTRCV.3.2, the PP/ST author should specify the list of failures or other discontinuities for which automated recovery must be possible. For FPTRCV.3.3, the PP/ST author should provide a quantification for the amount of loss of TSF data or objects that is acceptable. FPTRCV.4 Function recovery Function recovery requires that if there should be some failure in the TSF, that certain SFs in the TSF should either complete successfully or recover to a secure state. Operations Assignment: In FPTRCV.4.1, the PP/ST author should specify a list the SFs and failure scenarios. In the event that any of the identified failure scenarios happen, the SFs that have been specified must either complete successfully or recover to a consistent and secure state. J.9 Replay detection (FPT RPL) This family addresses detection of replay for various types of entities and subsequent actions to correct. FPTRPL.1 Replay detection User application notes The entities included here are, for example, messages, service requests, service responses, or sessions. Operations Assignment: In FPTRPL.1.1, the PP/ST author should provide a list of identified entities for which detection of replay should be possible. Examples of such entities might include: messages, service requests, service responses, and user sessions. In FPTRPL.1.2, the PP/ST author should specify the list of actions to be taken by the TSF when replay is detected. The potential set of actions that can be taken includes: ignoring the replayed entity, requesting confirmation of the entity from the identified source, and terminating the subject from which the re-played entity originated. 0 ... 105 106 107 108 109 110 111 ... 117
|
