Раздел: Документация
0 ... 108 109 110 111 112 113 114 ... 117 J.15 Internal TOE TSF data replication consistency (FPT TRC) The requirements of this family are needed to ensure the consistency of TSF data when such data is replicated internal to the TOE. Such data may become inconsistent if an internal channel between parts of the TOE becomes inoperative. If the TOE is internally structured as a network of parts of the TOE, this can occur when parts become disabled, network connections are broken, and so on. User notes The method of ensuring consistency is not specified in this component. It could be attained through a form of transaction logging (where appropriate transactions are "rolled back" to a site upon reconnection); it could be updating the replicated data through a synchronisation protocol. If a particular protocol is necessary for a PP/ST, it can be specified through refinement. It may be impossible to synchronise some states, or the cost of such synchronisation may be too high. Examples of this situation are communication channel and encryption key revocations. Indeterminate states may also occur; if a specific behaviour is desired, it should be specified via refinement. FPTTRC.1 Internal TSF consistency Operations Assignment: In FPTTRC.1.2, the PP/ST author should specify the list of SFs dependent on TSF data replication consistency. J.16 TSF self test (FPT TST) The family defines the requirements for the self-testing of the TSF with respect to some expected correct operation. Examples are interfaces to enforcement functions, and sample arithmetical operations on critical parts of the TOE. These tests can be carried out at start-up, periodically, at the request of an authorised user, or when other conditions are met. The actions to be taken by the TOE as the result of self testing are defined in other families. The requirements of this family are also needed to detect the corruption of TSF executable code (i.e. TSF software) and TSF data by various failures that do not necessarily stop the TOEs operation (which would be handled by other families). These checks must be performed because these failures may not necessarily be prevented. Such failures can occur either because of unforeseen failure modes or associated oversights in the design of hardware, firmware, or software, or because of malicious corruption of the TSF due to inadequate logical and/or physical protection. In addition, use of this component may, with appropriate conditions, help to prevent inappropriate or damaging TSF changes being applied to an operational TOE as the result of maintenance activities. User notes The term "correct operation of the TSF" refers primarily to the operation of the TSF software and the integrity of the TSF data. The abstract machine upon which the TSF software is implemented is tested via dependency on FPRAMT. FPTTST.1 TSF testing User application notes This component provides support for the testing of the critical functions of the TSFs operation by requiring the ability to invoke testing functions and check the integrity of TSF data and executable code. Evaluator application notes It is acceptable for the functions that are available to the authorised user for periodic testing to be available only in an off-line or maintenance mode. Controls should be in place to limit access during these modes to authorised users. Operations Selection: In FPTTST.1 the PP/ST author should specify when the TSF will execute the TSF test; during initial start-up, periodically during normal operation, at the request of an authorised user, at other conditions. In the case of the latter option, the PP/ST author should also assign what those conditions are via the following assignment. Assignment: In FPTTST.1.1 the PP/ST author should, if selected, specify the conditions under which the self test should take place. 0 ... 108 109 110 111 112 113 114 ... 117
|
