    
Раздел: Документация
0 ... 81 82 83 84 85 86 87 ... 117 Operations Assignment: In FDPITT.3.1, the PP/ST author should specify the access control SFP(s) and/ or information flow control SFP(s) covering the information being transferred and monitored for integrity errors. In FDPITT.3.1, the PP/ST author should specify the type of possible integrity errors to be monitored during transmission of the user data. In FDPITT.3.2, the PP/ST author should specify the action to be taken by the TSF when an integrity error is encountered. An example might be that the TSF should request the resubmission of the user data. The SFP(s) specified in FDPITT.3.1 will be enforced as the actions are taken by the TSF. FDPITT.4 Attribute-based integrity monitoring This component is used in combination with FDPITT.2. It ensures that the TSF checks received user data, that has been transmitted by separate channels (based on values of specified security attributes), for integrity. It allows the PP/ST author to specify actions to be taken upon detection of an integrity error. For example, this component could be used to provide different integrity error detection and action for information at different integrity levels. The PP/ST author has to specify the types of errors that must be detected. The PP/ST author should consider: modification of data, substitution of data, unrecoverable ordering change of data, replay of data, incomplete data, in addition to other integrity errors. The PP/ST author should specify the attributes (and associated transmission channels) that necessitate integrity error monitoring The PP/ST author must specify the actions that the TSF should take on detection of a failure. For example: ignore the user data, request the data again, inform the authorised administrator, reroute traffic for other lines. Operations Assignment: In FDP ITT.4.1, the PP/ST author should specify the access control SFP(s) and/or information flow control SFP(s) covering the information being transferred and monitored for integrity errors. In FDPITT.4.1, the PP/ST author should specify the type of possible integrity errors to be monitored during transmission of the user data. In FDPITT.4.1, the PP/ST author should specify a list of security attributes that require separate transmission channels. This list is used to determine which user data to monitor for integrity errors., based on its security attributes and its transmission channel. This element is directly related to FDPITT.2 Transmission separation by attribute. In FDPITT.4.2, the PP/ST author should specify the action to be taken by the TSF when an integrity error is encountered. An example might be that the TSF should request the resubmission of the user data. The SFP(s) specified in FDPITT.3.1 will be enforced as the actions are taken by the TSF. F.9 Residual information protection (FDP RIP) This family addresses the need to ensure that deleted information is no longer accessible, and that newly-created objects do not contain information from previously used objects within the TOE. This family does not address objects stored off-line. User notes This family requires protection for information that has been logically deleted or released (not available to the user but still within the system and may be recoverable). In particular, this includes information that is contained in an object, as part of the TSF reusable resources, where destruction of the object does not necessarily equate to destruction of the resource or any contents of the resource. It also applies to resources that are serially reused by different subjects within the system. For example, most operating systems typically rely upon hardware registers (resources) to support processes within the system. As processes are swapped from a "run" state to a "sleep" state (and vice versa), these registers are serially reused by different subjects. While this "swapping" action may not be considered an allocation or deallocation of a resource, FDPRIP could apply to such events and resources. FDP RIP typically controls access to information that is not part of any currently defined or accessible object; however, in certain cases this may not be true. For example, object "A" is a file and object "B" is the disk upon which that file resides. If object "A" is deleted, the information from object "A" is under the control of FDPRIP even though it is still part of object "B". It is important to note that FDP RIP applies only to on-line objects and not off-line objects such as those backed-up on tapes. For example, if a file is deleted in the TOE, FDP RIP can be instantiated to require that no residual information exists upon deallocation; however, the TSF cannot extend this enforcement to that same file that exists on the off-line back-up. Therefore that same file is still available. If this is a concern, then the PP/ST author should make sure that the proper environmental objectives are in place to support administrative guidance to address off-line objects. FDPRIP and FDPROL can conflict when FDPRIP is instantiated to require that residual information be cleared at the time the application releases the object to the TSF (i.e. upon deallocation). Therefore, the FDP RIP selection of "deallocation" should not be used with FDP ROL since there would be no information to roll back. The other selection, "unavailability upon allocation", may be used with FDP ROL, but there is the risk that the resource which held the information has been allocated to a new object before the roll back took place. If that were to occur, then the roll back would not be possible. There are no audit requirements in FDP RIP because this is not a user-invokable function. Auditing of allocated or deallocated resources would be auditable as part of the access control SFP or the information flow control SFP operations. This family should apply to the objects specified in the access control SFP(s) or the information flow control SFP(s) as specified by the PP/ST author. 0 ... 81 82 83 84 85 86 87 ... 117 |
