A Guide to Understanding Security Modeling in Trusted Systems
This document provides a guidance as to the formulation of security models for trusted systems at all levels of trust. It helps the developer understand the essential concepts of security modeling, as well as expected content for the model. This document provides guidance on the construction, evaluation, and use of security policy models for automated in formation systems (AIS) used to protect sensitive information whose unauthorized disclosure, alteration, loss, or destruction must be prevented. In this context, sensitive information includes classified information as well as unclassified sensitive information.
What people are saying - Write a review
We haven't found any reviews in the usual places.
access control model accreditation range allow associated automated Cartesian product classification components Computer Security Center contains controlled entities covert channel analysis data structures Database Security DBMS definition of security device discretionary access control discussed document DTLS encapsulation evaluation example explicitly external—interface requirements formal model given higher—level host identified IEEE implementation information flow input label mandatory access control mathematical mathematical proof model interpretation modeling requirements Multics multilevel Multilevel Security named objects National Computer Security NCSC90b network security non—TCB subjects nondisclosure and integrity nondisclosure level noninterference ofthe operating system orderto output Padula partially ordered set philosophy of protection policy enforcement reference monitor rules of operation Section Security and Privacy security attributes security level security model security objectives security policy model security requirements security—critical speciﬁcation storage objects subsystems system security policy TCB subjects TCSEC requirements techniques TRUSIX Trusted Computing Base UNIX verification Xenix
Page 137 - 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 135 - Least Privilege - This principle requires that each subject in a system be granted the most restrictive set of privileges (or lowest clearance) needed for the performance of authorized tasks. The application of this principle limits the damage that can result from accident, error, or unauthorized use.
Page 135 - A means of restricting access to objects based on the sensitivity (as represented by a label) of the information contained in the objects and the formal authorization (ie, clearance) of subjects to access information of such sensitivity.
Page 133 - 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 144 - Verification - The process of comparing two levels of system specification for proper correspondence (eg, security policy model with top-level specification, TLS with source code, or source code with object code). This process may or may not be automated.
Page 141 - Single-level device — a device that is used to process data of a single security level at any one time. Since the device need not be trusted to separate data of different security levels, sensitivity labels do not have to be stored with the data being processed.
Page 4 - A statement of intent with regard to control over access to and dissemination of information, to be known as the security policy, must be precisely defined and implemented for each system that is used to process sensitive information. The security policy must accurately reflect the laws, regulations, and general policies from which it is derived.
Page 100 - The FTLS shall be shown to be an accurate description of the TCB Interface. A convincing argument shall be given that the DTLS is consistent with the model and a combination of formal and informal techniques shall be used to show that the FTLS is consistent with the model. This verification evidence shall be consistent with that provided within the state-of-the-art of the particular Computer Security Center-endorsed formal specification and verification system used.
Page 103 - Device Labels The TCB shall support the assignment of minimum and maximum security levels to all attached physical devices. These security levels shall be used by the TCB to enforce constraints imposed by the physical environments in which the devices are located.
Page 129 - QL3 characteristics and/or features; operational procedures, accountability procedures, and access controls at the central computer facility, remote computer, and terminal facilities; management constraints; physical structures and devices; and personnel and communication controls needed to provide an acceptable level of risk for the AIS and for the data and information contained in the AIS.