Раздел: Документация
0 ... 94 95 96 97 98 99 100 ... 117 Annex I (informative) Privacy (FPR) This class describes the requirements that could be levied to satisfy the users privacy needs, while still allowing the system flexibility as far as possible to maintain sufficient control over the operation of the system. In the components of this class there is flexibility as to whether or not authorised users are covered by the required security functions. For example, a PP/ST author might consider it appropriate not to require protection of the privacy of users against a suitably authorised user. Privacy (FPR) FMT ANO Anonymity
FPR PSE Pseudonymity FPRJJNL Unlinkability FPRJJNO Unobservability  1- 2 Figure I.1 - Privacy class decomposition This class, together with other classes (such as those concerned with audit, access control, trusted path, and non-repudiation) provides the flexibility to specify the desired privacy behaviour. On the other hand, the requirements in this class might impose limitations on the use of the components of other classes, such as FIA or FAU. For example, if authorised users are not allowed to see the user identity (e.g. Anonymity or Pseudonymity), it will obviously not be possible to hold individual 2 1 3 1 3 4 users accountable for any security relevant actions they perform that are covered by the privacy requirements. However, it may still be possible to include audit requirements in a PP/ST, where the fact that a particular security relevant event has occurred is more important than knowing who was responsible for it. Additional information is provided in the application notes for class FAU, where it is explained that the definition of identity in the context of auditing can also be an alias or other information that could identify a user. This class describes four families: Anonymity, Pseudonymity, Unlinkability and Unobservability. Anonymity, Pseudonymity and Unlinkability have a complex interrelationship. When choosing a family, the choice should depend on the threats identified. For some types of privacy threats, pseudonymity will be more appropriate than anonymity (e.g. if there is a requirement for auditing). In addition, some types of privacy threats are best countered by a combination of components from several families. All families assume that a user does not explicitly perform an action that discloses the users own identity. For example, the TSF is not expected to screen the user name in electronic messages or databases. All families in this class have components that can be scoped through operations. These operations allow the PP/ST author to state the cooperating users/subjects to which the TSF must be resistant. An example of an instantiation of anonymity could be: "The TSF shall ensure that the users and/ or subjects are unable to determine the user identity bound to the teleconsulting application". It is noted that the TSF should not only provide this protection against individual users, but also against users cooperating to obtain the information. The strength of the protection provided by this class should be described as strength of function as specified in Annexes B and C of ISO/IEC 15408-1. 0 ... 94 95 96 97 98 99 100 ... 117
|
