Lib FOREWORD The Trusted Product Ev

Found at: 0x1bi.net:70/textfiles/file?hacking/COLORBOOKS/blue.txt

The Trusted Product Evaluation Questionnaire is the latest in a series of 
technical documents that are being published by the National Computer 
Security Center under the Technical Guidelines Programs.  It is the goal 
of the Technical Guidelines Program to assure that each process in the 
Trusted Product Evaluation Program and the features of the Department of 
Defense Trusted Computer Systems Evaluation Criteria will be discussed in 
These publications are designed to provide insight to the Department of 
Defense Trusted Computer Systems Evaluation Criteria requirements for the 
computer security vendor and developer, as well as the technical 
The specific questions in the Trusted Product Evaluation Questionnaire 
concerning the system for a product evaluation.  From the vendor's 
the system applying for evaluation.
As the Director, National Computer Security Center, I invite your 
			16 October 1989
National Computer Security Center
The National Computer Security Center extends special recognition to 
Santosh Chokhani, Ph.D. and Harriet Goldman as the primary authors of this 
Navy) for the development and publication of this guideline.
We wish to thank the many members of the computer security community, who 
enthusiastically gave of their time and technical expertise in reviewing 
this questionnaire and providing valuable comments and suggestions.
	2. SCOPE	2
	8. LABELS	20
	11. AUDIT	28
	13. TESTING	34
The principal goal of the National Computer Security Center (NCSC) is to 
encourage the widespread availability of trusted computer systems.  In 
Trusted Computer System Evaluation Criteria (TCSEC), against which 
computer systems could be evaluated.  The TCSEC was originally published 
on 15 August 1983 as CSC*STD*001*83.  In December 1985 the DoD adopted it, 
Trusted Computer System Evaluation Criteria to be used throughout the DoD. 
 The TCSEC is the standard used for evaluating the effectiveness of 
available level of assurance.  Within divisions C, B, and A there are 
manner to represent different levels of security in these classes.
The NCSC has established an aggressive program to study and implement 
computer security technology and to encourage the widespread availability 
of trusted computer products for use by any organization desiring better 
fulfillment of our country's computer security requirement.  We are 
  1. PURPOSE  
The NCSC is responsible for evaluating commercial products through an 
ndependent evaluation based on TCSEC requirements by a qualified team of
experts and maintaining a list of those products on the Evaluated Products 
List (EPL).  To accomplish this mission, the NCSC Trusted Product 
Evaluation Program has been established to assist vendors in developing, 
testing, and evaluating trusted products for the EPL.
During the evaluation process, the TCSEC for classes C1 through A1 
mplemented as designed and that they are adequate for the specified level
of trust.  In addition, the TCSEC also requires documentation to support a 
the vendor supplies to an evaluation team certain information on system 
Questionnaire (product questionnaire) is to assist system developers and 
vendors as a data gathering tool for *formalizing the data gathering 
Examples in this document are not to be construed as the only 
mplementations that may answer the questionnaire.  The examples are
  2. SCOPE  
The questionnaire will address the TCSEC Criteria Classes C1 thru A1.  In 
an effort to gather a better understanding of the system security, some 
questions in the questionnaire address information in addition to that 
Criteria.  This document is organized by Criteria class subject area.  The 
nformation provided in the questionnaire by the vendor is to assist the
evaluator in obtaining an initial understanding of the system applying for 
evaluation and its security features of the respective Criteria class.  
The product questionnaire is not a statement of requirements, just an 
nformation gathering tool.  This questionnaire should give the vendor an
dea of the information required by the evaluator during the evaluation
evaluation team later on in the evaluation process.
The questionnaire will be initially sent out to the vendor prior to the 
are not pertinent.  Some of the questions may be applicable at the later 
appropriate time.  The vendor will send a completed questionnaire to NCSC 
use the questionnaire during the PTR to seek additional information used 
later on in the evaluation process.  When an evaluation team has reached 
the Design Analysis and IPAR preparation phase, it will use the 
questionnaire to seek specific references in vendor documentation for 
further details on the answers to these questions.
The document is to provide the evaluator an understanding of the various 
and documentation, system security features and their applicability to 
and noncircumventability, and covert channel analysis methods.  Also this 
questionnaire may request information on penetration testing and 
This questionnaire is designed for the operating systems only.  This 
questionnaire does not address networks, subsystems nor data base 
For definition and clarification of the terms used in this document, 
Computer System Evaluation Criteria (DOD 5200.28*STD) and Glossary of 
Computer Security Terms (NCSC*TG*004).
Review of this document will occur periodically or when the need arises.  
Address all proposals for revision through appropriate channels to:
onal Computer Security Center
t George G. Meade, MD 20755-6000
ention:	Chief, Criteria and Technical Guidelines Division
A subject is an active entity in the system, generally in the form of a 
or changes the system state.  A subject can be viewed as a process/domain 
	1.	What are the subjects in your system? 
	2.	When and how are the subjects created?  (For example, they 
can be created or activated when a user logs on or when a process is 
	3.	When and how are the subjects destroyed?  (For example, 
they can be destroyed or deactivated when a process terminates or when the 
user logs off.)
	4.	What are the security attributes of a subject?  (Examples 
of security attributes are user name, group id, sensitivity level, etc.)  
For each type of subject in your system (i.e. user, process, device), what 
mechanisms are available to define and modify these attributes?  Who can 
nvoke these mechanisms?
	5.	What are other privileges a subject can have?  (Examples 
of privileges are: super user, system operator, system administrator, etc. 
 Your operating system may assign numerous other privileges to the 
these privileges?  Who can invoke these mechanisms?  Provide a list of 
	6.	When a subject is created, where do its security 
attributes and privileges originate, i.e., how are the security attributes 
and privileges inherited?  (Questions about security attributes and 
  2. OBJECTS  
Examples of objects in a system are directories, files, segments, 
	7.	List the objects in your system that are protected by the 
Discretionary Access Control (DAC) mechanisms.
	8.	List the objects in your system that are protected by the 
Mandatory Access Control (MAC) mechanisms.
	9.	List the objects that are not protected by either the DAC 
or the MAC mechanism.  Why are they not protected by the DAC or the MAC?  
Describe other mechanisms used to isolate and protect these objects.
	10.	List other shared resources which are not protected by the 
DAC or the MAC mechanism.  (Examples include print queues, interprocess 
communications, etc.)  Why are they not protected by the DAC or the MAC?  
Describe the mechanisms that are used to isolate and protect these 
	11.	How are the various types of objects created (e.g., 
	12.	How are the various types of objects destroyed?
authentication database, print queues).
(14-24) should be answered for each member of the hardware family.  You 
may choose to answer each question for each member of the family, or 
answer each question for a baseline family member and point out the 
controllers, memory, I/O processors, I/O controllers, I/O devices (e.g. 
(both control flow and data flow) among them.
Address Translation Unit, I/O devices and interfaces.
machine state, the executing ring/segment, physical memory location of the 
nstruction, etc.)
to physical) work in your system?
Direct Memory Access (DMA) controllers/devices?  Identify if the address 
translation is done through the memory address translation unit or if the 
logic is part of the controller.  How are the address translation maps 
and/or tables initialized?
the system.
Two possible techniques are rings and segments.
and how is it formed?
 How are they serviced by the system?
The TCB software consists of the elements that are involved in enforcing 
the system security policy.  Examples of the TCB elements include: kernel, 
nterrupt handlers, process manager, I/O handlers, I/O manager,
user/process interface, hardware diagnostics, hardware exercisers, and 
command languages/interfaces (for system generation, operator, 
administrator, users, etc.).  The security kernel consists of the 
mplementing the reference monitor concept, i.e., the ones that mediate
all access to objects by subjects.
Computing Base (TCB) at the element level.
TCB elements.
the TCB elements.
that are outside the TCB.
location where each TCB element resides.
location where the user processes reside.
each mechanism.
their location in terms of ring/segment/physical memory.
are active, ready for execution, suspended, swapped out, etc.)
Describe both hardware and software mechanisms used to manipulate/switch 
the process context.
the directory hierarchy, if any, directory and file attributes.  Also 
dentify all system directories and files, and their access attributes.
Examples of devices include tape drives, non-file-system disks, printers, 
for the TCB design and implementation?
TCB?  Provide a brief description of modules and functions in each layer.  
How are the lower layers protected from higher layers?
dentification at login?  If yes, what information is requested by the
login?  If yes, what information is requested by the system?  How does the 
Where in the system are the algorithms and data for authentication (e.g., 
user/password data base) stored?
the user?  If so, how?
before writing, etc.  When are the storage resources cleared: prior to 
allocation or after deallocation and/or release?  Describe the TCB 
of storage resources include memory pages, cache, disk sectors, magnetic 
tapes, removable disk media, terminals, etc.)
For example, what happens when a process attempts to read past the 
end-of-file (EOF) mark?  In this case, is it possible to read old data by 
controls?  (Examples of mechanisms are:   access control lists, protection 
bits, capabilities, etc.)
user basis?  If so, how?
basis, i.e., exclude individual users?  If so, how?
created?  Can the initial access permission be changed?  If so, by whom 
and how?  (User/owner, system administrator, others.)
the object is created?  (Examples include creator, current owner, system 
administrator, etc.)  How is the permission granted?
user?  If so, by whom and how?  How can the previous owner of the 
excluded from the DAC policy (e.g., IPC files, process 
of access modes are: read, write, delete, owner, execute, append, etc.  
Briefly describe the meaning of each access mode for each class of object.
explicitly defined?
  8. LABELS  
unclassified, confidential, secret, top secret), does your system provide 
for?  What mechanisms are available to define the internal/storage and 
external/print format?  What mechanisms are available to change them?  Who 
can invoke these mechanisms?
FOUO) does your system provide for?  What mechanisms are available to 
are available to change them?  Who can invoke these mechanisms?
label stored?
label stored?
labeled.  Why are they labeled or not labeled?  How are these subjects and 
objects controlled?
being involved in the labeling?  If so, what is the role of the person 
nvolved?  Does this labeling require special privileges?  What are those
outside the TCB?
level associated with an interactive user?  Is the user notification 
current sensitivity label?  What part of the sensitivity label is output?  
Where is this output posted?
changed.  List the users who can invoke these mechanisms/ways.
the users who can invoke these mechanisms.
changed.  List the users who can invoke these mechanisms.
format for the exported label?  How does the TCB ensure that the 
nvoke these mechanisms?
the output?  In other words, does each hardcopy output have banner pages?  
What happens if a banner page output is longer and/or wider than a 
the output?  What happens if the print label is wider and/or longer than 
the space available for the top and/or the bottom?
nontextual type of output such as graphics, maps, and images?
overridden?  Who can override the markings?
n question 13?
output of data that fall outside a device sensitivity range (i.e., 
minimum, maximum).
as read, write, append, delete.
 If not, what information is used to make the MAC decisions?
the MAC policy is not enforced.  Why?
access mechanisms such as:  a. privileges that bypass DAC and MAC, b. DAC, 
c. MAC, d. other access mechanisms in lieu of DAC and/or MAC?
can invoke the functions to designate and change them?  How are these 
levels used by the system in various labeling functions and MAC decisions? 
nternal/storage and external/print format?  Who can invoke these
nternal/storage and external/print format?  Who can invoke these
label stored?
label stored?
labels.  Why are they not labeled?
are those privileges?
ntegrity policy?  If not, what information is used to enforce the
ntegrity policy?
the integrity policy is not enforced.  Why?
  11. AUDIT  
form) of audit data flow in terms of how the data are created, 
transmitted, stored, and viewed for analysis.  How are the audit logs 
nvoke these mechanisms?
events auditable:  attempted logins, logouts, creation of subjects, 
ntroduction of the object into user address space or, e.g., file open),
accesses that exploit covert storage channels, change in the device 
n device minimum or maximum level, override of banner page or page top
and bottom markings, assumption of the role of security administrator.
Which are not?  Examples of trusted users are system operator, account 
administrator, system security officer/administrator, auditor, system 
following data recorded for each event: date, time, user, user sensitivity 
level, object, object sensitivity level, object DAC information (e.g., 
ACL), type of event, invoked or not invoked, why not invoked, success or 
failure in execution, terminal identification, etc?
the audit record?
activities being audited?  Who can invoke these mechanisms?
(i.e., selection of events, subjects, objects, etc., to be audited)?  What 
auditing?  Examples of parameters are: individual or group of subjects, 
ndividual objects, subjects within a sensitivity range, objects within a
mmediately for all processes, for new processes)?
analyzed and reduced) audit information?  Who can invoke these tools?  
What do the tools do in terms of audit data reduction?  What are the 
nternal formats of audit records.  What are the formats of the
there a trusted mechanism to view/output the audit log?
tools, techiques and methodologies are available to correlate these logs?
user) is notified when the audit log gets full?  What options are 
available to handle the situation?
becomes full?  Examples of the TCB options are: halt the system, do not 
the system goes down?  Are the data recovered as part of the system 
accumulation of events that require real-time notification?  Who can 
nvoke these mechanisms?  Who gets the real-time notification?  What
actions/options are available to the individual being notified?  What does 
the TCB do about the event and the process that caused this alert?
for completion of the Verification Plan.
are represented in the formal model.  Examples include: MAC, DAC, 
verify through formal means the model against its axioms?
of the TCB are represented by the DTLS?
dentify, analyze, calculate, and reduce the bandwidths of data flows in
violation of the system security policy?  How are the occurrences of these 
flow violations audited?
that the DTLS is consistent with the formal security policy model?
TCB are represented by the FTLS?
verify or show that the FTLS is consistent with the formal security policy 
dentify the implemented code modules that correspond to the FTLS?
that the code is correctly implemented vis- a-vis the FTLS?
  13. TESTING  
of the system hardware and firmware?  What elements of the system hardware 
are tested through these routines?  What elements of the system firmware 
are tested through these routines?  What elements of the system hardware 
and firmware are not tested through these routines?
testing include boundary and anomalous conditions?  Is the emphasis on 
operation of the system hardware and firmware?  The latter may require 
more of the same testing or different kinds of testing.
they run in stand-alone mode?
nclude powerup, booting, rebooting, etc.
the methodol-ogy, include various testing steps such as unit, module, 
ntegration, subsystem, system testing.  For each step, provide a
nclude the following information:  system configuration for testing,
nclude nominal, boundary, and anomalous values for each input?  What
about the combinations of inputs?  Describe the test coverage criteria.
concept of func-tional testing, structural testing, or a combination of 
the two?
combination of the two) will be used to do the functional and/or 
not plan to use them, how do you plan to show consistency among FTLS, 
DTLS, and the code?
n terms of organizational responsibilities, procedures, and tools and
techniques (automated, manual, or a combination of the two).  Describe the 
version control or  other philosophy to ensure that the elements represent 
a consistent system, i.e., object code represents the source code, which 
n turn represents the FTLS and DTLS, etc.  If the CM system is different
for some of the elements listed under Question 25, answer this question 
for each of the elements.
as well as the system life-cycle phase (e.g. design, development, testing).
Management.  List the TCB elements that are not under CM.  Examples of TCB 
elements are: hardware elements, firmware elements, formal security policy 
model, FTLS, DTLS, design data and documentation, source code, object 
code, software engineering environment, test plans, Security Features 
User's Guide, Trusted Facilities Manual, etc.
the CM elements.
	164.	When (e.g., before user authentication) and how (e.g. by 
typing a specific control character sequence) can the trusted path be 
nvoked by the user?  What TCB elements are involved in establishing the
trusted path?
	165.	List separately the functions that can be performed by 
each of the trusted users such as the operator, security administrator, 
accounts administrator, auditor, systems programmer, etc.  For each of 
these persons/roles, list the system data bases that can be accessed and 
their access modes.  For each of these roles, also list the privileges 
	166.	How does the TCB recognize that a user has assumed one of 
the above-mentioned trusted roles?  Which of the above-mentioned functions 
can be performed without the TCB recognizing this role?
	167.	When and how does the TCB invoke the trusted path?  What 
TCB elements are involved in establishing the trusted path?
	168.	How does the TCB ensure that the trusted path is 
	169.	How does the system recovery work?  What system resources 
(e.g., memory, disks blocks, files) are protected prior to and during the 
can cause this to occur?  How long can the system keep running in this 
mode?  How does an operator get the system back to full operation?  What 
ensure the integrity of the TCB elements (hardware, firmware, software, 
courier, electronic seals, physical seals, etc.
 Provide a list of documents that capture the system design.  For each 
annotated outline.  Provide a schedule for development of the design 
(SFUG), a brief description of its contents, or an annotated outline.  
Does the document describe the protection mechanisms available to the 
users?  Does it include examples of how to use the protection mechanisms 
n conjunction with one another to meet the user security objectives?
brief description of its contents, or an annotated outline.  Provide a 
the evaluated configuration?  Does it contain procedures for configuring 
each of the devices, for connecting them, and for configuring the entire 
configuration?  Does it list the procedures for securely configuring them 
out and for disconnecting them?
values for a secure TCB generation?
bases that are to be controlled?  Does it list how these are controlled?  
Does it list the consequences of granting access to them as warnings?
log?  Does it describe how the audit log can be turned on, turned off, 
combined, and backed up?  Does it describe how to detect the audit log is 
the loss of audit data?
and the format of the audit records?  Does it describe how the audit 
tool output?
of hard-copy outputs?
etc.  Examples of trusted processes are device queue manipulation, user 
users, changing user security profile, setting up defaults for 
terms of functions, subjects, objects, sensitivity levels, and/or a 
combination of them, etc.  Examples of data bases are user security 
the security kernel?
		A specific type of interaction between a subject and an 
object that results in the flow of information from one to the other.
Access List
		A list of users, programs, and/or processes and the 
Administrative User
		A user assigned to supervise all or a portion of an ADP 
		To conduct the independent review and examination of 
Audit Trail
		A chronological record of system activities that is 
operation, a procedure, or an event in a transaction from its inception to 
final results.
		An authorized individual, or role, with administrative 
analyzing the trail of audit events.
		(1) To verify the identity of a user, device, or other 
entity in a computer system, often as a prerequisite to allowing access to 
		(2) To verify the integrity of data that have been stored, 
transmitted, or otherwise exposed to possible unauthorized modification.
Authenticated User
		A user who has accessed an ADP system with a valid 
dentifier and authentication combination.
		The granting of access rights to a user, program, or 
		A characteristic of a communication channel that is the 
amount of information that can be passed through it in a given amount of 
time, usually expressed in bits per second.
Bell-LaPadula Model
		A formal state transition model of computer security 
model, the entities in a computer system are divided into abstract sets of 
access modes of subjects to objects are in accordance with a specific 
mode is allowed, the clearance of a subject is compared to the 
classification of the object, and a determination is made as to whether 
the subject is authorized for the specific access mode.  The 
clearance/classification scheme is expressed in terms of a lattice.  See 
Star Property (*-property) and Simple Security Property.
		An information transfer path within a system.  May also 
Covert Channel
		A communication channel that allows two cooperating 
Covert Storage Channel
		A covert channel that involves the direct or indirect 
channels typically involve a finite resource (e.g., sectors on a disk) 
that is shared by two subjects at different security levels.
Covert Timing Channel
		A covert channel in which one process signals information 
to another by modulating its own use of system resources (e.g., CPU time) 
n such a way that this manipulation affects the real response time
observed by the second process.
Coverage Analysis
		Qualitative or quantitative assessment of the extent to 
Condition, Test Data, Security Policy Model.
		Information with a specific physical representation.
Data Integrity
		The property that data meet an a priori expectation of 
		To reduce magnetic flux density to zero by applying a 
Descriptive Top Level Specification (DTLS)
		A top-level specification that is written in a natural 
language (e.g.,English), an informal program design notation, or a 
combination of the two.
Discretionary Access Control (DAC)
		A means of restricting access to objects based on the 
dentity and need-to-know of the user, process 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 
ndirectly) on to any other subject.
		Security level S1 is said to dominate security level S2 if 
the hierarchical classification of S1 is greater than or equal to that of 
S2 and the nonhierarchical categories of S1 include all those of S2 as a 
Exploitable Channel
		Any channel that is usable or detectable by subjects 
external to the Trusted Computing Base whose purpose is to violate the 
		An error of commission, omission, or oversight in a system 
that allows protection mechanisms to be bypassed.
Flaw Hypothesis Methodology
		A system analysis and penetration technique in which 
flaws in the system are hypothesized.  The list of hypothesized flaws is 
exists and, assuming a flaw does exist, on the ease of exploiting it and 
on the extent of control or compromise it would provide.  The prioritized 
list is used to direct a penetration attack against the system.
Formal Proof
		A complete and convincing mathematical argument, 
truth of a theorem or set of theorems.
Formal Security Policy Model
		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 
a "secure" state and if all assumptions required by the model hold, then 
all future states of the system will be secure.  Some formal modeling 
techniques include:  state transition models, temporal logic models, 
Formal Top-Level Specification (FTLS)
		A Top-Level Specification that is written in a formal 
mathematical language to allow theorems showing the correspondence of the 
formally proven.
Formal Verification
		The process of using formal proofs to demonstrate the 
consistency  between a formal specification of a system and a formal 
Functional Testing
		The segment of security testing in which the advertised 
mechanisms of a system are tested, under operational conditions, for 
correct operation.
		The process that enables recognition of an entity by a 
		Sound, unimpaired or perfect condition.
		Hardware, firmware, and software features within a system 
that restrict access to resources (hardware, software, and data) to 
authorized subjects only (persons, programs, or devices).
		The containment of subjects and objects in a system in 
		A partially ordered set for which every pair of elements 
Least Privilege
		This principle requires that each subject in a system be 
needed for the performance of authorized tasks.  The application of this 
unauthorized use.
Mandatory Access Control (MAC)
		A means of restricting access to objects based on the 
the objects and the formal authorization (i.e., clearance) of subjects to 
access information of such sensitivity.
Multilevel Device
		A device that is used in a manner that permits it to 
compromise.  To accomplish this, sensitivity labels are normally stored on 
the same physical medium and in the same form (i.e., machine-readable or 
		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 tree, and programs, as well as bits, bytes, 
network nodes.
Object Reuse
		The reassignment and reuse of a storage medium (e.g., page 
frame, disk sector, magnetic tape) that once contained one or more 
objects.  To be securely reused and assigned to a new subject, storage 
media must contain no residual data (magnetic remanence) from the 
object(s) previously contained in the media.
		The successful act of bypassing the security mechanisms of 
a system.
		A program in execution.
		Those portions of the TCB whose normal function is to deal 
operation is esssential to the protection of data on the system.
		A fundamental operation that results only in the flow of 
nformation from an object to a subject.
Read Access (Privilege)
		Permission to read information.
Reference Monitor Concept
		An access-control concept that refers to an abstract 
machine that mediates all accesses to objects by subjects.
Security Level
		The combination of a hierarchical classification and a set 
of nonhierarchical categories that represents the sensitivity of 
Security Policy
		The set of laws, rules, and practices that regulate how an 
organization manages, protects, and distributes sensitive information.
Security Policy Model
		A formal presentation of the security policy enforced by 
the system.  It must identify the set of rules and practices that regulate 
See Bell-La Padula Model and Formal Security Policy Model.
Security-Relevant Event
		Any event that attempts to change the security state of 
the system, (e.g., change discretionary access controls, change the 
that attempts to violate the security policy of the system, (e.g., too 
many attempts to log in, attempts to violate the mandatory access control 
limits of a device, attempts to downgrade a file).
Security Testing
		A process used to determine that the security features of 
a system are implemented as designed.  This includes hands-on functional 
testing, penetration testing, and verification.
Simple Security Property
		A Bell-La Padula security model rule allowing a subject 
Single-Level Device
		An automated information systems device that is used to 
		An attempt to gain access to a system by posing as an 
authorized user.  Synonymous with impersonating, masquerading or mimicking.
Star Property
		A Bell-La Padula security model rule allowing a subject 
		An active entity, generally in the form of a person, 
changes the system state.  Technically, a process/domain pair.
Subject Security Level
		A subject's security level is equal to the security level 
of the objects to which it has both read and write access.  A subject's 
Terminal Identification
		The means used to provide unique identification of a 
terminal to a system.
Test Condition
		A statement defining a constraint that must be satisfied 
by the program under test.
Test Data
		The set of specific objects and variables that must be 
used to demonstrate that a program produces a set of given outcomes.
Test Plan
		A document or a section of a document which describes the 
test conditions, data, and coverage of a particular test of group of 
tests.  See also: Test Condition, Test Data, Coverage Analysis.
Test Procedure (Script)
		A set of steps necessary to carry out one or a group of 
tests. These include steps for test environment initialization, test 
execution, and result analysis.  The test procedures are carried out by 
test operators.
Test Program
		A program which implements the test conditions when 
nitialized with the test data and which collects the results produced by
the program being tested.
Top-Level Specification (TLS)
		A nonprocedural description of system behavior at the most 
abstract level, typically, a functional specification that omits all 
mplementation details.
Trusted Computer System
		A system that employs sufficient hardware and software 
ntegrity measures to allow its use for processing simultaneously a range
of sensitive or classified information.
Trusted Computing Base (TCB)
		The totality of protection mechanisms within a computer 
a trusted computer system.  The ability of a trusted computing base to 
correctly enforce a security policy depends solely on the mechanisms 
of parameters (e.g., a user's clearance) re-lated to the security policy.
Trusted Path
		A mechanism by which a person at a terminal can 
communicate directly with the Trusted Computing Base.  This mechanism can 
only be activated by the person or the Trusted Computing Base and cannot 
be imitated by untrusted software.
		Person or process accessing an AIS either by direct 
connections (i.e., via terminals), or indirect connections (i.e., prepare 
nput data or receive output that is not reviewed for content or
classification by a responsible individual).
		The process of comparing two levels of system 
top-level specification, TLS with source code, or source code with object 
code).  This process may or may not be automated.
		A fundamental operation that results only in the flow of 
nformation from a subject to an object.
Write Access (Privilege)
		Permission to write an object.
Criteria, DoD 5200.28*STD, December 1985.
Resource Sharing ADP Systems, DoD 5200.28*M, revised June 1979.
Evaluation Management Plan," 1 October 1985.
of Computer Security Terms, 21 October 1988.
Maintenance Phase * Program Document, 23 June 1989