A Guide to Understanding Trusted Recovery in Trusted Systems
Provides a set of good practices related to trusted recovery. Helps the vendor and evaluator community understand the requirements for trusted recovery at all applicable classes. Includes: failures, discontinuities, and recovery; properties of trusted recovery; design approaches for trusted recovery; impact on trusted recovery; and satisfying requirements. Glossary and bibliography.
What people are saying - Write a review
We haven't found any reviews in the usual places.
ADP system allocated approach to recovery atomic actions B3 and A1 Bell-La Padula model caused Chapter class B3 Computer Security Configuration Management covert channels covery cylinder map data structures database deallocated defined discontinuities of operation discretionary access control disk sectors disk-write operations example failures and discontinuities file system formal fsck functions and interfaces guideline i-node idempotency inconsistent invariants and constraints Life-Cycle Assurance logging maintenance mode media failures mode of operation nonvolatile storage normal mode notions object map object representation operating systems Operational Assurance properties reconstruct consistent recovery mechanisms recovery procedures redundant storage requirements of class satisfied secure input secure state transitions secure-state security invariants security level security testing serializable set of intentions state-machine models state-transition failures system crashes TCB code TCB failures TCB or media TCB primitives TCSEC REQUIREMENTS top-level specification Trusted Distribution trusted facility management trusted processes trusted recovery functions trusted-recovery UNIX updates user-level references
Page 51 - Object is defined as a passive entity that contains or receives information. Access to an object potentially implies access to the information it contains. Examples of objects are: records blocks, pages, segments, files, directories, directory trees, and programs, as well as bits, bytes, words, fields, processors, video displays, keyboards, clocks, printers, network nodes, etc.
Page 50 - A mathematically precise statement of a security policy. To be adequately precise, such a model must represent the initial state of a system, the way in which the system progresses from one state to another, and a definition of a "secure" state of the system. To be acceptable as a basis for a TCB, the model must be supported by a formal proof that if the initial state of the system satisfies the definition of a "secure...
Page 3 - Systems that are used to process or handle classified or other sensitive information must be designed to guarantee correct and accurate interpretation of the security policy and must not distort the intent of that policy.
Page 50 - A means of restricting access to objects based on the identity of subjects and/or groups to which they belong. The controls are discretionary in the sense that a subject with a certain access permission is capable of passing that permission (perhaps indirectly) on to any other subject...
Page 52 - Top-Level Specification (TLS) - A non-procedural description of system behavior at the most abstract level. Typically a functional specification that omits all implementation details. Trap Door - A hidden software or hardware mechanism that permits system protection mechanisms to be circumvented. It is activated in some non-apparent manner (eg, special "random
Page 53 - ... computer system - including hardware, firmware, and software - the combination of which is responsible for enforcing a security policy. A TCB consists of one or more components that together enforce a unified security policy over a product or system. The ability of a TCB to...
Page 49 - Approval/Accreditation - The official authorization that is granted to an ADP system to process sensitive information in its operational environment, based upon comprehensive security evaluation of the system's hardware, firmware, and software security design, configuration, and implementation and of the other system procedural, administrative, physical, TEMPEST, personnel, and communications security controls.
Page 52 - Security Testing - A process used to determine that the security features of a system are implemented as designed and that they are adequate for a proposed application environment. This process includes hands-on functional testing, penetration testing, and verification. See also: Functional Testing, Penetration Testing, Verification.
Page 52 - Subject - An active entity, generally in the form of a person, process, or device that causes information to flow among objects or changes the system state.