Раздел: Документация
0 ... 104 105 106 107 108 109 110 ... 117 J.7 TSF physical protection (FPT PHP) TSF physical protection components refer to restrictions on unauthorised physical access to the TSF, and to the deterrence of, and resistance to, unauthorised physical modification, or substitution of the TSF. The requirements in this family ensure that the TSF is protected from physical tampering and interference. Satisfying the requirements of these components results in the TSF being packaged and used in such a manner that physical tampering is detectable, or resistance to physical tampering is measurable based on defined work factors. Without these components, the protection functions of a TSF lose their effectiveness in environments where physical damage cannot be prevented. This component also provides requirements regarding how the TSF must respond to physical tampering attempts. Examples of physical tampering scenarios include mechanical attack, radiation, changing the temperature. User notes It is acceptable for the functions that are available to an authorised user for detecting physical tampering to be available only in an off-line or maintenance mode. Controls should be in place to limit access during such modes to authorised users. As the TSF may not be "operational" during those modes, it may not be able to provide normal enforcement for authorised user access. The physical implementation of a TOE might consist of several structures: for example an outer shielding, cards, and chips. This set of "elements" as a whole must protect (protect, notify and resist) the TSF from physical tampering. This does not mean that all devices must provide these features, but the complete physical construct as a whole should. Although there is only minimal auditing associating with these components, this is solely because there is the potential that the detection and alarm mechanisms may be implemented completely in hardware, below the level of interaction with an audit subsystem (for example, a hardware-based detection system based on breaking a circuit and lighting a light emitting diode (LED) if the circuit is broken when a button is pressed by the authorised user). Nevertheless, a PP/ST author may determine that for a particular anticipated threat environment, there is a need to audit physical tampering. If this is the case, the PP/ST author should include appropriate requirements in the list of audit events. Note that inclusion of these requirements may have implications on the hardware design and its interface to the software. FPTPHP.1 Passive detection of physical attack User application notes FPTPHP.1 should be used when threats from unauthorised physical tampering with parts of the TOE are not countered by procedural methods. It addresses the threat of undetected physical tampering with the TSF. Typically, an authorised user would be given the function to verify whether tampering took place. As written, this component simply provides a TSF capability to detect tampering. The dependency on FMTMOF. 1 is required to specify who can make use of that capability, and how they can make use of that capability. If this function is realised by non-IT mechanisms (e.g. physical inspection) it could be justified that the dependency on FMTMOF. 1 is not satisfied. FPTPHP.2 Notification of physical attack User application notes FPTPHP.2 should be used when threats from unauthorised physical tampering with parts of the TOE are not countered by procedural methods, and it is required that designated individuals be notified of physical tampering. It addresses the threat that physical tampering with TSF elements, although detected, may not be noticed. Operations Assignment: For FPT PHP.2.3, the PP/ST author should provide a list of TSF devices/ elements for which active detection of physical tampering is required. For FPT PHP.2.3, the PP/ST author should designate a user or role that is to be notified when tampering is detected. The type of user or role may vary depending on the particular security administration component (from the FMTMOF.1 family) included in the PP/ST. FPT PHP.3 Resistance to physical attack For some forms of tampering, it is necessary that the TSF not only detects the tampering, but actually resists it or delays the attacker. User application notes This component should be used when TSF devices and TSF elements are expected to operate in an environment where a physical tampering (e.g. observation, analysis, or modification) of the internals of a TSF device or TSF element itself is a threat. Operations Assignment: For FPT PHP.3.1, the PP/ST author should specify tampering scenarios to a list of TSF devices/elements for which the TSF should resist physical tampering. This list may be applied to a defined subset of the TSF physical devices and elements based on considerations such as technology limitations and relative physical exposure of the device. Such subsetting should be clearly defined and justified. Furthermore, the TSF should automatically respond to physical tampering. The automatic response should be such that the policy of the device is preserved; for example, with a confidentiality policy, it would be acceptable to physically disable the device so that the protected information may not be retrieved. For FPT PHP.3.1, the PP/ST author should specify the list of TSF devices/ elements for which the TSF should resist physical tampering in the scenarios that have been identified. J.8 Trusted recovery (FPT RCV) The requirements of this family ensure that the TSF can determine that the TOE is started-up without protection compromise and can recover without protection compromise after discontinuity of operations. This family is important because the start-up state of the TSF determines the protection of subsequent states. Recovery components reconstruct the TSF secure states, or prevent transitions to insecure states, as a direct response to occurrences of expected failures, discontinuity of operation or start-up. Failures that must be generally anticipated include the following: a)Unmaskable action failures that always result in a system crash (e.g. persistent inconsistency of critical system tables, uncontrolled transfers within the TSF code caused by transient failures of hardware or firmware, power failures, processor failures, communication failures). b)Media failures causing part or all of the media representing the TSF objects to become inaccessible or corrupt (e.g. parity errors, disk head crash, persistent read/write failure caused by misaligned disk heads, worn-out magnetic coating, dust on the disk surface). c)Discontinuity of operation caused by erroneous administrative action or lack of timely administrative action (e.g. unexpected shutdowns by turning off power, ignoring the exhaustion of critical resources, inadequate installed configuration). Note that recovery may be from either a complete or partial failure scenario. Although a complete failure might occur in a monolithic operating system, it is less likely to occur in a distributed environment. In such environments, subsystems may fail, but other portions remain operational. Further, critical components may be redundant (disk mirroring, alternative routes), and checkpoints may be available. Thus, recovery is expressed in terms of recovery to a secure state. This family identifies a maintenance mode. In this maintenance mode normal operation might be impossible or severely restricted, as otherwise insecure situations might occur. Typically, only authorised users should be allowed access to this mode but the real details of who can access this mode is a function of Class FMT Security management. If FMT does not put any controls on who can access this mode, then it may be acceptable to allow any user to restore the system if the TOE enters such a state. However, in practice, this is probably not desirable as the user restoring the system has an opportunity to configure the TOE in such a way as to violate the TSP. Mechanisms designed to detect exceptional conditions during operation fall under FPTTST (TSF self test), FPTFLS (Fail secure), and other areas that address the concept of "Software Safety." User notes Throughout this family, the phrase "secure state" is used. This refers to some state in which the TOE has consistent TSF data and a TSF that can correctly enforce the policy. This state may be the initial "boot" of a clean system, or it might be some checkpointed state. 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. 0 ... 104 105 106 107 108 109 110 ... 117
|
