Раздел: Документация
0 ... 101 102 103 104 105 106 107 ... 117 J.1 Underlying abstract machine test (FPT AMT) This family defines the requirements for the TSFs testing of security assumptions made about the underlying abstract machine upon which the TSF relies. This "abstract" machine could be a hardware/firmware platform, or it could be some known and assessed hardware/software combination acting as a virtual machine. Examples of such testing could be testing hardware page protection, sending sample packets across a network to ensure receipt, and verifying the behaviour of the virtual machine interface. These tests can be carried out either in some maintenance state, at start-up, on-line, or continuously. The actions to be taken by the TOE as the result of testing are defined in FPTRCV. User notes The term "underlying abstract machine" typically refers to the hardware components upon which the TSF has been implemented. However, the phrase can also be used to refer to an underlying, previously evaluated hardware and software combination behaving as a virtual machine upon which the TSF relies. The tests of the abstract machine may take various forms: a)Power-On Tests. These are tests that ensure the correct operation of the underlying platform. For hardware and firmware, this might include tests of elements such as memory boards, data paths, buses, control logic, processor registers, communication ports, console interfaces, speakers, and peripherals. For software elements (virtual machine), this would include verification of correct initialisation and behaviour. b)Loadable Tests. These are tests that might be loaded and executed by an authorised user or be activated by specific conditions. This might include processor component stress tests (logic units, calculation units, etc.) and control memory. Evaluator Notes The tests of the underlying abstract machine should be sufficient to test all ofthe characteristics of the underlying abstract machine upon which the TSF relies. FPTAMT.1 Abstract machine testing User application notes This component provides support for the periodic testing of the security assumptions of the underlying abstract machine upon which the TSFs operation depends, by requiring the ability to periodically invoke testing functions. The PP/ST author may refine the requirement to state whether the function should be available in off-line, on-line or maintenance mode. Evaluator application notes It is acceptable for the functions for periodic testing to be available only in an off-line or maintenance mode. Controls should be in place to limit access, during maintenance, to authorised users. Operations Selection: In FPTAMT.1.1 the PP/ST author should specify when the TSF will execute the abstract machine testing, during initial start-up, periodically during normal operation, at the request of an authorised user, or under other conditions. In the case of the latter option, the PP/ST author should refine what those conditions are. The PP/ST author, through this selection, has the ability to indicate the frequency with which the self tests will be run. If the tests are run often, then the end users should have more confidence that the TOE is operating correctly then if the tests are run less frequently. However, this need for confidence that the TOE is operating correctly must be balanced with the potential impact on the availability of the TOE, as often times, self tests may delay the normal operation of a TOE. J.2 Fail secure (FPT FLS) The requirements of this family ensure that the TOE will not violate its TSP in the event of certain types of failures in the TSF. FPTFLS.1 Failure with preservation of secure state User application notes The term "secure state" refers to a state in which the TSF data are consistent and the TSF continues correct enforcement of the TSP. The "secure state" is defined in the TSP model. If the developer provided a clear definition of the secure state and the reason why it should be considered secure, the dependency from FPTFLS.1 to ADVSPM. 1 can be argued away. Although it is desirable to audit situations in which failure with preservation of secure state occurs, it is not possible in all situations. The PP/ST author should specify those situations in which audit is desired and feasible. Failures in the TSF may include "hard" failures, which indicate an equipment malfunction and which may require maintenance, service or repair of the TSF. Failures in the TSF may also include recoverable "soft" failures, which may only require initialisation or resetting of the TSF. Operations Assignment: For FPTFLS.1.1, the PP/ST author should list the types of failures in the TSF for which the TSF should "fail secure," that is, should preserve a secure state and continue to correctly enforce the TSP. 0 ... 101 102 103 104 105 106 107 ... 117
|
