NCSC*TG*019
Lib
FOREWORD
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
evaluator.
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
________________
Jr.
16 October 1989
Director
National Computer Security Center
ACKNOWLEDGMENTS
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.
CONTENTS
FOREWORD i
ACKNOWLEDGMENTS ii
1. PURPOSE 1
2. SCOPE 2
QUESTIONNAIRE 4
1. SUBJECTS 4
2. OBJECTS 6
3. HARDWARE ARCHITECTURE 8
4. SOFTWARE 10
5. IDENTIFICATION & AUTHENTICATION (I&A) 14
6. OBJECT REUSE 16
7. DISCRETIONARY ACCESS CONTROL (DAC) POLICY 17
8. LABELS 20
9. MANDATORY ACCESS CONTROL (MAC) 25
10. INTEGRITY 26
11. AUDIT 28
12. MODELING AND ANALYSIS 32
13. TESTING 34
14. OTHER ASSURANCES 37
15. OTHER DOCUMENTATION 40
GLOSSARY 43
REFERENCES 54
INTRODUCTION
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
nformation.
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
questionnaire.
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
management.
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:
Nat
onal Computer Security Center
980
For
t George G. Meade, MD 20755-6000
Att
ention: Chief, Criteria and Technical Guidelines Division
QUESTIONNAIRE
1. SUBJECTS
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
objects.
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
them.
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).
3. HARDWARE ARCHITECTURE
(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?
4. SOFTWARE
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,
etc.
for the TCB design and implementation?
mplemented?
TCB? Provide a brief description of modules and functions in each layer.
How are the lower layers protected from higher layers?
5. IDENTIFICATION & AUTHENTICATION (I&A)
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?
6. OBJECT REUSE
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
7. DISCRETIONARY ACCESS CONTROL (DAC) POLICY
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
mechanism.
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?
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).
9. MANDATORY ACCESS CONTROL (MAC)
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?
10. INTEGRITY
nternal/storage and external/print format? Who can invoke these
mechanisms?
nternal/storage and external/print format? Who can invoke these
mechanisms?
label?
label stored?
label stored?
labels. Why are they not labeled?
are those privileges?
model.
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
mechanisms?
nvoke these mechanisms?
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?
12. MODELING AND ANALYSIS
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
model?
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
methodology.
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?
testing?
channels?
14. OTHER ASSURANCES
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
unspoofable?
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.
15. OTHER DOCUMENTATION
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?
GLOSSARY
Access
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
Audit
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.
Auditor
An authorized individual, or role, with administrative
analyzing the trail of audit events.
Authenticate
(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.
Authorization
The granting of access rights to a user, program, or
Bandwidth
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.
Channel
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.
Data
Information with a specific physical representation.
Data Integrity
The property that data meet an a priori expectation of
quality.
Degauss
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.
Dominate
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
Flaw
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
Lattice
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
Object
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.
Read
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
nformation.
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
condition.
Single-Level Device
An automated information systems device that is used to
Spoofing
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
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.
User
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).
Verification
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.
Write
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.
REFERENCES
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
