A Guide to Understanding Security Modeling in Trusted Systems

Front Cover
DIANE Publishing, 1993 - 159 pages
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.

Contents

III
1
VI
3
VII
5
VIII
7
IX
9
XI
11
XII
14
XIII
24
XXIV
94
XXV
99
XXVII
100
XXVIII
103
XXIX
104
XXX
105
XXXI
107
XXXIII
109

XIV
27
XVI
41
XVII
53
XVIII
61
XIX
66
XX
75
XXII
78
XXIII
86
XXXV
110
XXXVI
113
XXXVII
114
XXXVIII
115
XXXIX
117
XLI
121
XLII
127
XLIII
145

Common terms and phrases

Popular passages

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.

Bibliographic information