Раздел: Документация
0 ... 107 108 109 110 111 112 113 ... 117 J.12 State synchrony protocol (FPT SSP) Distributed systems may give rise to greater complexity than monolithic systems through the potential for differences in state between parts of the system, and through delays in communication. In most cases, synchronisation of state between distributed functions involves an exchange protocol, not a simple action. When malice exists in the distributed environment of these protocols, more complex defensive protocols are required. FPTSSP establishes the requirement for certain critical security functions of the TSF to use a trusted protocol. FPTSSP ensures that two distributed parts of the TOE (e.g. hosts) have synchronised their states after a security-relevant action. User notes Some states may never be synchronised, or the transaction cost may be too high for practical use; encryption key revocation is an example, where knowing the state after the revocation action is initiated can never be known. Either the action was taken and acknowledgment cannot be sent, or the message was ignored by hostile communication partners and the revocation never occurred. Indeterminacy is unique to distributed systems. Indeterminacy and state synchrony are related, and the same solution may apply. It is futile to design for indeterminate states; the PP/ST author should express other requirements in such cases (e.g. raise an alarm, audit the event). FPTSSP.1 Simple trusted acknowledgement User application notes In this component, the TSF must supply an acknowledgement to another part of the TSF when requested. This acknowledgement should indicate that one part of a distributed TOE successfully received an unmodified transmission from a different part of the distributed TOE. FPTSSP.2 Mutual trusted acknowledgement User application notes In this component, in addition to the TSF being able to provide an acknowledgement for the receipt of a data transmission, the TSF must comply with a request from another part of the TSF for an acknowledgement to the acknowledgement. For example, the local TSF transmits some data to a remote part of the TSF. The remote part of the TSF acknowledges the successful receipt of the data and requests that the sending TSF confirm that it receives the acknowledgement. This mechanism provides additional confidence that both parts of the TSF involved in the data transmission know that the transmission completed successfully. J.13 Time stamps (FPT STM) This family addresses requirements for a reliable time stamp function within a TOE. User notes It is the responsibility of the PP/ST author to clarify the meaning of the phrase "reliable time stamp", and to indicate where the responsibility lies in determining the acceptance of trust. FPTSTM.1 Reliable time stamps User application notes Some possible uses of this component include providing reliable time stamps for the purposes of audit as well as for security attribute expiration. J.14 Inter-TSF TSF data consistency (FPT TDC) In a distributed or composite system environment, a TOE may need to exchange TSF data (e.g. the SFP-attributes associated with data, audit information, identification information) with another trusted IT Product. This family defines the requirements for sharing and consistent interpretation of these attributes between the TSF of the TOE and that of a different trusted IT Product.0 User notes The components in this family are intended to provide requirements for automated support for TSF data consistency when such data is transmitted between the TSF of the TOE and another trusted IT Product. It is also possible that wholly procedural means could be used to produce security attribute consistency, but they are not provided for here. This family is different from FDPETC and FDPITC, as those two families are concerned only with resolving the security attributes between the TSF and its import/export medium. If the integrity of the TSF data is of concern, requirements should be chosen from the FPTITI family. These components specify requirements for the TSF to be able to detect or detect and correct modifications to TSF data in transit. FPTTDC.1 Inter-TSF basic TSF data consistency User application notes The TSF is responsible for maintaining the consistency of TSF data used by or associated with the specified function and that are common between two or more trusted systems. For example, the TSF data of two different systems may have different conventions internally. For the TSF data to be used properly (e.g. to afford the user data the same protection as within the TOE) by the receiving trusted IT product, the TOE and the other trusted IT product must use a pre-established protocol to exchange TSF data. Operations Assignment: In FPTTDC.1.1, the PP/ST author should define the list of TSF data types, for which the TSF shall provide the capability to consistently interpret, when shared between the TSF and another trusted IT product.0 In FPTTDC.1.2, the PP/ST should assign the list of interpretation rules to be applied by the TSF.0 0 ... 107 108 109 110 111 112 113 ... 117
|
