home *** CD-ROM | disk | FTP | other *** search
/ Cuteskunk BBS / cuteskunk.zip / cuteskunk / unsorted2 / hacking / orange.txt < prev    next >
Text File  |  2003-06-29  |  328KB  |  6,551 lines
  1.  
  2. orange-boot.txt: No such file or directory
  3. % cat orange.boo
  4. orange.boo: No such file or directory
  5. % cat orange-book.txt
  6.                                                                  CSC-STD-001-83
  7.                                                            Library No. S225,711
  8.  
  9.  
  10.  
  11.  
  12.  
  13.                              DEPARTMENT OF DEFENSE
  14.  
  15.                 TRUSTED COMPUTER SYSTEM EVALUATION CRITERIA
  16.  
  17.  
  18.  
  19.  
  20.  
  21.  
  22.  
  23.                                 15 August 1983
  24.  
  25.  
  26.  
  27.                                                                  CSC-STD-001-83
  28.  
  29.  
  30.  
  31.  
  32.  
  33.  
  34.                                FOREWORD
  35.  
  36.  
  37. This publication, "Department of Defense Trusted Computer System Evaluation
  38. Criteria," is being issued by the DoD Computer Security Center under the
  39. authority of and in accordance with DoD Directive 5215.1, "Computer Security
  40. Evaluation Center." The criteria defined in this document constitute a uniform
  41. set of basic requirements and evaluation classes for assessing the
  42. effectiveness of security controls built into Automatic Data Processing (ADP)
  43. systems.  These criteria are intended for use in the evaluation and selection
  44. of ADP systems being considered for the processing and/or storage and
  45. retrieval of sensitive or classified information by the Department of Defense.
  46. Point of contact concerning this publication is the Office of Standards and
  47. Products, Attention: Chief, Computer Security Standards.
  48.  
  49.  
  50.  
  51.  
  52.  
  53. ____________________________                                     15 August 1983
  54. Melville H. Klein
  55. Director
  56. DoD Computer Security Center
  57.  
  58.  
  59.  
  60.  
  61.                            ACKNOWLEDGMENTS
  62.  
  63.  
  64. Special recognition is extended to Sheila L. Brand, DoD Computer Security
  65. Center (DoDCSC), who integrated theory, policy, and practice into and directed
  66. the production of this document.
  67.  
  68. Acknowledgment is also given for the contributions of: Grace Hammonds and
  69. Peter S. Tasker, the MITRE Corp., Daniel J. Edwards, Col. Roger R. Schell,
  70. Marvin Schaefer, DoDCSC, and Theodore M. P. Lee, Sperry UNIVAC, who as
  71. original architects formulated and articulated the technical issues and
  72. solutions presented in this document; Jeff Makey and Warren F. Shadle,
  73. DoDCSC, who assisted in the preparation of this document; James P. Anderson,
  74. James P. Anderson & Co., Steven B. Lipner, Digital Equipment Corp., Clark
  75. Weissman, System Development Corp., LTC Lawrence A. Noble, formerly U.S. Air
  76. Force, Stephen T. Walker, formerly DoD, Eugene V. Epperly, DoD, and James E.
  77. Studer, formerly Dept. of the Army, who gave generously of their time and
  78. expertise in the review and critique of this document; and finally, thanks are
  79. given to the computer industry and others interested in trusted computing for
  80. their enthusiastic advice and assistance throughout this effort.
  81.  
  82.  
  83.  
  84.  
  85.                           TABLE OF CONTENTS
  86.  
  87. FOREWORD. . . . . . . . . . . . . . . . . . . . . . . . . . . .i
  88. ACKNOWLEDGMENTS . . . . . . . . . . . . . . . . . . . . . . . ii
  89. PREFACE . . . . . . . . . . . . . . . . . . . . . . . . . . . .v
  90. INTRODUCTION. . . . . . . . . . . . . . . . . . . . . . . . . .1
  91.  
  92.                         PART I: THE CRITERIA
  93. Section
  94. 1.0  DIVISION D:    MINIMAL PROTECTION. . . . . . . . . . . . .9
  95. 2.0  DIVISION C:    DISCRETIONARY PROTECTION. . . . . . . . . 11
  96.      2.1   Class (C1):  Discretionary Security Protection . . 12
  97.      2.2   Class (C2):  Controlled Access Protection. . . . . 15
  98. 3.0  DIVISION B:    MANDATORY PROTECTION. . . . . . . . . . . 19
  99.      3.1   Class (B1):  Labeled Security Protection . . . . . 20
  100.      3.2   Class (B2):  Structured Protection . . . . . . . . 26
  101.      3.3   Class (B3):  Security Domains. . . . . . . . . . . 33
  102. 4.0  DIVISION A:    VERIFIED PROTECTION . . . . . . . . . . . 41
  103.      4.1   Class (A1):  Verified Design . . . . . . . . . . . 42
  104.      4.2   Beyond Class (A1). . . . . . . . . . . . . . . . . 51
  105.  
  106.                  PART II: RATIONALE AND GUIDELINES
  107.  
  108. 5.0  CONTROL OBJECTIVES FOR TRUSTED COMPUTER SYSTEMS. . . . . 55
  109.      5.1   A Need for Consensus . . . . . . . . . . . . . . . 56
  110.      5.2   Definition and Usefulness. . . . . . . . . . . . . 56
  111.      5.3   Criteria Control Objective . . . . . . . . . . . . 56
  112. 6.0  RATIONALE BEHIND THE EVALUATION CLASSES. . . . . . . . . 63
  113.      6.1   The Reference Monitor Concept. . . . . . . . . . . 64
  114.      6.2   A Formal Security Policy Model . . . . . . . . . . 64
  115.      6.3   The Trusted Computing Base . . . . . . . . . . . . 65
  116.      6.4   Assurance. . . . . . . . . . . . . . . . . . . . . 65
  117.      6.5   The Classes. . . . . . . . . . . . . . . . . . . . 66
  118. 7.0  THE RELATIONSHIP BETWEEN POLICY AND THE CRITERIA . . . . 69
  119.      7.1   Established Federal Policies . . . . . . . . . . . 70
  120.      7.2   DoD Policies . . . . . . . . . . . . . . . . . . . 70
  121.      7.3   Criteria Control Objective For Security Policy . . 71
  122.      7.4   Criteria Control Objective for Accountability. . . 74
  123.      7.5   Criteria Control Objective for Assurance . . . . . 76
  124. 8.0  A GUIDELINE ON COVERT CHANNELS . . . . . . . . . . . . . 79
  125. 9.0  A GUIDELINE ON CONFIGURING MANDATORY ACCESS CONTROL
  126.      FEATURES . . . . . . . . . . . . . . . . . . . . . . . . 81
  127. 10.0  A GUIDELINE ON SECURITY TESTING . . . . . . . . . . . . 83
  128.       10.1 Testing for Division C . . . . . . . . . . . . . . 84
  129.       10.2 Testing for Division B . . . . . . . . . . . . . . 84
  130.       10.3 Testing for Division A . . . . . . . . . . . . . . 85
  131. APPENDIX A:  Commercial Product Evaluation Process. . . . . . 87
  132. APPENDIX B:  Summary of Evaluation Criteria Divisions . . . . 89
  133. APPENDIX C:  Sumary of Evaluation Criteria Classes. . . . . . 91
  134. APPENDIX D:  Requirement Directory. . . . . . . . . . . . . . 93
  135.  
  136. GLOSSARY. . . . . . . . . . . . . . . . . . . . . . . . . . .109
  137.  
  138. REFERENCES. . . . . . . . . . . . . . . . . . . . . . . . . .115
  139.  
  140.  
  141.  
  142.  
  143.                                 PREFACE
  144.  
  145.  
  146. The trusted computer system evaluation criteria defined in this document
  147. classify systems into four broad hierarchical divisions of enhanced security
  148. protection.  They provide a basis for the evaluation of effectiveness of
  149. security controls built into automatic data processing system products.  The
  150. criteria were developed with three objectives in mind: (a) to provide users
  151. with a yardstick with which to assess the degree of trust that can be placed
  152. in computer systems for the secure processing of classified or other sensitive
  153. information; (b) to provide guidance to manufacturers as to what to build into
  154. their new, widely-available trusted commercial products in order to satisfy
  155. trust requirements for sensitive applications; and (c) to provide a basis for
  156. specifying security requirements in acquisition specifications.  Two types of
  157. requirements are delineated for secure processing: (a) specific security
  158. feature requirements and (b) assurance requirements.  Some of the latter
  159. requirements enable evaluation personnel to determine if the required features
  160. are present and functioning as intended.  Though the criteria are
  161. application-independent, it is recognized that the specific security feature
  162. requirements may have to be interpreted when applying the criteria to specific
  163. applications or other special processing environments.  The underlying
  164. assurance requirements can be applied across the entire spectrum of ADP system
  165. or application processing environments without special interpretation.
  166.  
  167.  
  168. INTRODUCTION
  169.  
  170. Historical Perspective
  171.  
  172. In October 1967, a task force was assembled under the auspices of the Defense
  173. Science Board to address computer security safeguards that would protect
  174. classified information in remote-access, resource-sharing computer systems.
  175. The Task Force report, "Security Controls for Computer Systems," published in
  176. February 1970, made a number of policy and technical recommendations on
  177. actions to be taken to reduce the threat of compromise of classified
  178. information processed on remote-access computer systems.[34]  Department of
  179. Defense Directive 5200.28 and its accompanying manual DoD 5200.28-M, published
  180. in 1972 and 1973 respectivley, responded to one of these recommendations by
  181. establishing uniform DoD policy, security requirements, administrative
  182. controls, and technical measures to protect classified information processed
  183. by DoD computer systems.[8;9]  Research and development work undertaken by the
  184. Air Force, Advanced Research Projects Agency, and other defense agencies in
  185. the early and mid 70's developed and demonstrated solution approaches for the
  186. technical problems associated with controlling the flow of information in
  187. resource and information sharing computer systems.[1]  The DoD Computer
  188. Security Initiative was started in 1977 under the auspices of the Under
  189. Secretary of Defense for Research and Engineering to focus DoD efforts
  190. addressing computer security issues.[33]
  191.  
  192. Concurrent with DoD efforts to address computer security issues, work was
  193. begun under the leadership of the National Bureau of Standards (NBS) to define
  194. problems and solutions for building, evaluating, and auditing secure computer
  195. systems.[17]  As part of this work NBS held two invitational workshops on the
  196. subject of audit and evaluation of computer security.[20;28]  The first was
  197. held in March 1977, and the second in November of 1978.  One of the products
  198. of the second workshop was a definitive paper on the problems related to
  199. providing criteria for the evaluation of technical computer security
  200. effectiveness.[20]  As an outgrowth of recommendations from this report, and in
  201. support of the DoD Computer Security Initiative, the MITRE Corporation began
  202. work on a set of computer security evaluation criteria that could be used to
  203. assess the degree of trust one could place in a computer system to protect
  204. classified data.[24;25;31]  The preliminary concepts for computer security
  205. evaluation were defined and expanded upon at invitational workshops and
  206. symposia whose participants represented computer security expertise drawn from
  207. industry and academia in addition to the government.  Their work has since
  208. been subjected to much peer review and constructive technical criticism from
  209. the DoD, industrial research and development organizations, universities, and
  210. computer manufacturers.
  211.  
  212. The DoD Computer Security Center (the Center) was formed in January 1981 to
  213. staff and expand on the work started by the DoD Computer Security
  214. Initiative.[15]  A major goal of the Center as given in its DoD Charter is to
  215. encourage the widespread availability of trusted computer systems for use by
  216. those who process classified or other sensitive information.[10]  The criteria
  217. presented in this document have evolved from the earlier NBS and MITRE
  218. evaluation material.
  219.  
  220.  
  221. Scope
  222.  
  223. The trusted computer system evaluation criteria defined in this document apply
  224. to both trusted general-purpose and trusted embedded (e.g., those dedicated to
  225. a specific application) automatic data processing (ADP) systems.  Included are
  226. two distinct sets of requirements: 1) specific security feature requirements;
  227. and 2) assurance requirements.  The specific feature requirements encompass
  228. the capabilities typically found in information processing systems employing
  229. general-purpose operating systems that are distinct from the applications
  230. programs being supported.  The assurance requirements, on the other hand,
  231. apply to systems that cover the full range of computing environments from
  232. dedicated controllers to full range multilevel secure resource sharing
  233. systems.
  234.  
  235.  
  236. Purpose
  237.  
  238. As outlined in the Preface, the criteria have been developed for a number of
  239. reasons:
  240.  
  241.            * To provide users with a metric with which to evaluate the
  242.            degree of trust that can be placed in computer systems for
  243.            the secure processing of classified and other sensitive
  244.            information.
  245.  
  246.            * To provide guidance to manufacturers as to what security
  247.            features to build into their new and planned, commercial
  248.            products in order to provide widely available systems that
  249.            satisfy trust requirements for sensitive applications.
  250.  
  251.            * To provide a basis for specifying security requirements in
  252.            acquisition specifications.
  253.  
  254. With respect to the first purpose for development of the criteria, i.e.,
  255. providing users with a security evaluation metric, evaluations can be
  256. delineated into two types: (a) an evaluation can be performed on a computer
  257. product from a perspective that excludes the application environment; or, (b)
  258. it can be done to assess whether appropriate security measures have been taken
  259. to permit the system to be used operationally in a specific environment.  The
  260. former type of evaluation is done by the Computer Security Center through the
  261. Commercial Product Evaluation Process.  That process is described in Appendix
  262. A.
  263.  
  264. The latter type of evaluation, i.e., those done for the purpose of assessing a
  265. system's security attributes with respect to a specific operational mission,
  266. is known as a certification evaluation.  It must be understood that the
  267. completion of a formal product evaluation does not constitute certification or
  268. accreditation for the system to be used in any specific application
  269. environment.  On the contrary, the evaluation report only provides a trusted
  270. computer system's evaluation rating along with supporting data describing the
  271. product system's strengths and weaknesses from a computer security point of
  272. view.  The system security certification and the formal approval/accreditation
  273. procedure, done in accordance with the applicable policies of the issuing
  274. agencies, must still be followed-before a system can be approved for use in
  275. processing or handling classified information.[8;9]
  276.  
  277. The trusted computer system evaluation criteria will be used directly and
  278. indirectly in the certification process.  Along with applicable policy, it
  279. will be used directly as the basis for evaluation of the total system and for
  280. specifying system security and certification requirements for new
  281. acquisitions.  Where a system being evaluated for certification employs a
  282. product that has undergone a Commercial Product Evaluation, reports from that
  283. process will be used as input to the certification evaluation.  Technical data
  284. will be furnished to designers, evaluators and the Designated Approving
  285. Authorities to support their needs for making decisions.
  286.  
  287.  
  288. Fundamental Computer Security Requirements
  289.  
  290. Any discussion of computer security necessarily starts from a statement of
  291. requirements, i.e., what it really means to call a computer system "secure."
  292. In general, secure systems will control, through use of specific security
  293. features, access to information such that only properly authorized
  294. individuals, or processes operating on their behalf, will have access to read,
  295. write, create, or delete information.  Six fundamental requirements are
  296. derived from this basic statement of objective: four deal with what needs to
  297. be provided to control access to information; and two deal with how one can
  298. obtain credible assurances that this is accomplished in a trusted computer
  299. system.
  300.  
  301.                                 POLICY
  302.  
  303. Requirement 1 - SECURITY POLICY - There must be an explicit and well-defined
  304. security policy enforced by the system.  Given identified subjects and
  305. objects, there must be a set of rules that are used by the system to determine
  306. whether a given subject can be permitted to gain access to a specific object.
  307. Computer systems of interest must enforce a mandatory security policy that can
  308. effectively implement access rules for handling sensitive (e.g., classified)
  309. information.[7]  These rules include requirements such as: No person lacking
  310. proper personnel security clearance shall obtain access to classified
  311. information.  In addition, discretionary security controls are required to
  312. ensure that only selected users or groups of users may obtain access to data
  313. (e.g., based on a need-to-know).
  314.  
  315. Requirement 2 - MARKING - Access control labels must be associated with
  316. objects.  In order to control access to information stored in a computer,
  317. according to the rules of a mandatory security policy, it must be possible to
  318. mark every object with a label that reliably identifies the object's
  319. sensitivity level (e.g., classification), and/or the modes of access accorded
  320. those subjects who may potentially access the object.
  321.  
  322.                           ACCOUNTABILITY
  323.  
  324. Requirement 3 - IDENTIFICATION - Individual subjects must be identified.  Each
  325. access to information must be mediated based on who is accessing the
  326. information and what classes of information they are authorized to deal with.
  327. This identification and authorization information must be securely maintained
  328. by the computer system and be associated with every active element that
  329. performs some security-relevant action in the system.
  330.  
  331. Requirement 4 - ACCOUNTABILITY - Audit information must be selectively kept
  332. and protected so that actions affecting security can be traced to the
  333. responsible party.  A trusted system must be able to record the occurrences of
  334. security-relevant events in an audit log.  The capability to select the audit
  335. events to be recorded is necessary to minimize the expense of auditing and to
  336. allow efficient analysis.  Audit data must be protected from modification and
  337. unauthorized destruction to permit detection and after-the-fact investigations
  338. of security violations.
  339.  
  340.                              ASSURANCE
  341.  
  342. Requirement 5 - ASSURANCE - The computer system must contain hardware/software
  343. mechanisms that can be independently evaluated to provide sufficient assurance
  344. that the system enforces requirements 1 through 4 above.  In order to assure
  345. that the four requirements of Security Policy, Marking, Identification, and
  346. Accountability are enforced by a computer system, there must be some
  347. identified and unified collection of hardware and software controls that
  348. perform those functions.  These mechanisms are typically embedded in the
  349. operating system and are designed to carry out the assigned tasks in a secure
  350. manner.  The basis for trusting such system mechanisms in their operational
  351. setting must be clearly documented such that it is possible to independently
  352. examine the evidence to evaluate their sufficiency.
  353.  
  354. Requirement 6 - CONTINUOUS PROTECTION - The trusted mechanisms that enforce
  355. these basic requirements must be continuously protected against tampering
  356. and/or unauthorized changes.  No computer system can be considered truly
  357. secure if the basic hardware and software mechanisms that enforce the security
  358. policy are themselves subject to unauthorized modification or subversion.  The
  359. continuous protection requirement has direct implications throughout the
  360. computer system's life-cycle.
  361.  
  362. These fundamental requirements form the basis for the individual evaluation
  363. criteria applicable for each evaluation division and class.  The interested
  364. reader is referred to Section 5 of this document, "Control Objectives for
  365. Trusted Computer Systems," for a more complete discussion and further
  366. amplification of these fundamental requirements as they apply to
  367. general-purpose information processing systems and to Section 7 for
  368. amplification of the relationship between Policy and these requirements.
  369.  
  370.  
  371. Structure of the Document
  372.  
  373. The remainder of this document is divided into two parts, four appendices, and
  374. a glossary.  Part I (Sections 1 through 4) presents the detailed criteria
  375. derived from the fundamental requirements described above and relevant to the
  376. rationale and policy excerpts contained in Part II.
  377.  
  378. Part II (Sections 5 through 10) provides a discussion of basic objectives,
  379. rationale, and national policy behind the development of the criteria, and
  380. guidelines for developers pertaining to: mandatory access control rules
  381. implementation, the covert channel problem, and security testing.  It is
  382. divided into six sections.  Section 5 discusses the use of control objectives
  383. in general and presents the three basic control objectives of the criteria.
  384. Section 6 provides the theoretical basis behind the criteria.  Section 7 gives
  385. excerpts from pertinent regulations, directives, OMB Circulars, and Executive
  386. Orders which provide the basis for many trust requirements for processing
  387. nationally sensitive and classified information with computer systems.
  388. Section 8 provides guidance to system developers on expectations in dealing
  389. with the covert channel problem.  Section 9 provides guidelines dealing with
  390. mandatory security.  Section 10 provides guidelines for security testing.
  391. There are four appendices, including a description of the Trusted Computer
  392. System Commercial Products Evaluation Process (Appendix A), summaries of the
  393. evaluation divisions (Appendix B) and classes (Appendix C), and finally a
  394. directory of requirements ordered alphabetically.  In addition, there is a
  395. glossary.
  396.  
  397.  
  398. Structure of the Criteria
  399.  
  400. The criteria are divided into four divisions: D, C, B, and A ordered in a
  401. hierarchical manner with the highest division (A) being reserved for systems
  402. providing the most comprehensive security.  Each division represents a major
  403. improvement in the overall confidence one can place in the system for the
  404. protection of sensitive information.  Within divisions C and B there are a
  405. number of subdivisions known as classes.  The classes are also ordered in a
  406. hierarchical manner with systems representative of division C and lower
  407. classes of division B being characterized by the set of computer security
  408. mechanisms that they possess.  Assurance of correct and complete design and
  409. implementation for these systems is gained mostly through testing of the
  410. security- relevant portions of the system.  The security-relevant portions of
  411. a system are referred to throughout this document as the Trusted Computing
  412. Base (TCB).  Systems representative of higher classes in division B and
  413. division A derive their security attributes more from their design and
  414. implementation structure.  Increased assurance that the required features are
  415. operative, correct, and tamperproof under all circumstances is gained through
  416. progressively more rigorous analysis during the design process.
  417.  
  418. Within each class, four major sets of criteria are addressed.  The first three
  419. represent features necessary to satisfy the broad control objectives of
  420. Security Policy, Accountability, and Assurance that are discussed in Part II,
  421. Section 5.  The fourth set, Documentation, describes the type of written
  422. evidence in the form of user guides, manuals, and the test and design
  423. documentation required for each class.
  424.  
  425. A reader using this publication for the first time may find it helpful to
  426. first read Part II, before continuing on with Part I.
  427.  
  428.  
  429.  
  430.  
  431.                         PART I:  THE CRITERIA
  432.  
  433. Highlighting (UPPERCASE) is used in Part I to indicate criteria not contained
  434. in a lower class or changes and additions to already defined criteria.  Where
  435. there is no highlighting, requirements have been carried over from lower
  436. classes without addition or modification.
  437.  
  438.  
  439.  
  440. 1.0  DIVISION D:    MINIMAL PROTECTION
  441.  
  442. This division contains only one class.  It is reserved for those systems that
  443. have been evaluated but that fail to meet the requirements for a higher
  444. evaluation class.
  445.  
  446.  
  447.  
  448. 2.0 DIVISION C:  DISCRETIONARY PROTECTION
  449.  
  450. Classes in this division provide for discretionary (need-to-know) protection
  451. and, through the inclusion of audit capabilities, for accountability of
  452. subjects and the actions they initiate.
  453.  
  454.  
  455. 2.1  CLASS (C1):   DISCRETIONARY SECURITY PROTECTION
  456.  
  457. The Trusted Computing Base (TCB) of a class (C1) system nominally satisfies
  458. the discretionary security requirements by providing separation of users and
  459. data.  It incorporates some form of credible controls capable of enforcing
  460. access limitations on an individual basis, i.e., ostensibly suitable for
  461. allowing users to be able to protect project or private information and to
  462. keep other users from accidentally reading or destroying their data.  The
  463. class (C1) environment is expected to be one of cooperating users processing
  464. data at the same level(s) of sensitivity.  The following are minimal
  465. requirements for systems assigned a class (C1) rating:
  466.  
  467. 2.1.1  SECURITY POLICY
  468.  
  469.      2.1.1.1   Discretionary Access Control
  470.  
  471.                THE TCB SHALL DEFINE AND CONTROL ACCESS BETWEEN NAMED USERS AND
  472.              NAMED OBJECTS (E.G., FILES AND PROGRAMS) IN THE ADP SYSTEM.  THE
  473.              ENFORCEMENT MECHANISM (E.G., SELF/GROUP/PUBLIC CONTROLS, ACCESS 
  474.              CONTROL LISTS) SHALL ALLOW USERS TO SPECIFY AND CONTROL SHARING 
  475.              OF THOSE OBJECTS BY NAMED INDIVIDUALS OR DEFINED GROUPS OR BOTH.
  476.  
  477. 2.1.2  ACCOUNTABILITY
  478.  
  479.      2.1.2.1   Identification and Authentication
  480.  
  481.                THE TCB SHALL REQUIRE USERS TO IDENTIFY THEMSELVES TO IT BEFORE
  482.              BEGINNING TO PERFORM ANY OTHER ACTIONS THAT THE TCB IS EXPECTED 
  483.              TO MEDIATE.  FURTHERMORE, THE TCB SHALL USE A PROTECTED 
  484.              MECHANISM (E.G., PASSWORDS) TO AUTHENTICATE THE USER'S IDENTITY.
  485.              THE TCB SHALL PROTECT AUTHENTICATION DATA SO THAT IT CANNOT BE 
  486.              ACCESSED BY ANY UNAUTHORIZED USER.
  487.  
  488. 2.1.3  ASSURANCE
  489.  
  490.      2.1.3.1   Operational Assurance
  491.  
  492.         2.1.3.1.1  System Architecture
  493.  
  494.                      THE TCB SHALL MAINTAIN A DOMAIN FOR ITS OWN EXECUTION
  495.                  THAT PROTECTS IT FROM EXTERNAL INTERFERENCE OR TAMPERING
  496.                  (E.G., BY MODIFICATION OF ITS CODE OR DATA STRUCTURES). 
  497.                  RESOURCES CONTROLLED BY THE TCB MAY BE A DEFINED SUBSET 
  498.                  OF THE SUBJECTS AND OBJECTS IN THE ADP SYSTEM.
  499.  
  500.         2.1.3.1.2  System Integrity
  501.  
  502.                      HARDWARE AND/OR SOFTWARE FEATURES SHALL BE PROVIDED THAT
  503.                  CAN BE USED TO PERIODICALLY VALIDATE THE CORRECT OPERATION
  504.                  OF THE ON-SITE HARDWARE AND FIRMWARE ELEMENTS OF THE TCB.
  505.  
  506.      2.1.3.2   Life-Cycle Assurance
  507.  
  508.         2.1.3.2.1  Security Testing
  509.  
  510.                      THE SECURITY MECHANISMS OF THE ADP SYSTEM SHALL BE TESTED
  511.                  AND FOUND TO WORK AS CLAIMED IN THE SYSTEM DOCUMENTATION. 
  512.                  TESTING SHALL BE DONE TO ASSURE THAT THERE ARE NO OBVIOUS
  513.                  WAYS FOR AN UNAUTHORIZED USER TO BYPASS OR OTHERWISE 
  514.                  DEFEAT THE SECURITY PROTECTION MECHANISMS OF THE TCB.
  515.                  (SEE THE SECURITY TESTING GUIDELINES.)
  516.  
  517. 2.1.4  DOCUMENTATION
  518.  
  519.      2.1.4.1   Security Features User's Guide
  520.  
  521.                A SINGLE SUMMARY, CHAPTER, OR MANUAL IN USER DOCUMENTATION
  522.              SHALL DESCRIBE THE PROTECTION MECHANISMS PROVIDED BY THE TCB,
  523.              GUIDELINES ON THEIR USE, AND HOW THEY INTERACT WITH ONE ANOTHER.
  524.  
  525.      2.1.4.2   Trusted Facility Manual
  526.  
  527.                A MANUAL ADDRESSED TO THE ADP SYSTEM ADMINISTRATOR SHALL
  528.              PRESENT CAUTIONS ABOUT FUNCTIONS AND PRIVILEGES THAT SHOULD BE 
  529.              CONTROLLED WHEN RUNNING A SECURE FACILITY.
  530.  
  531.      2.1.4.3   Test Documentation
  532.  
  533.                THE SYSTEM DEVELOPER SHALL PROVIDE TO THE EVALUATORS A DOCUMENT
  534.              THAT DESCRIBES THE TEST PLAN AND RESULTS OF THE SECURITY 
  535.              MECHANISMS' FUNCTIONAL TESTING.
  536.  
  537.      2.1.4.4   Design Documentation
  538.  
  539.                DOCUMENTATION SHALL BE AVAILABLE THAT PROVIDES A DESCRIPTION OF
  540.              THE MANUFACTURER'S PHILOSOPHY OF PROTECTION AND AN EXPLANATION 
  541.              OF HOW THIS PHILOSOPHY IS TRANSLATED INTO THE TCB.  IF THE TCB 
  542.              IS COMPOSED OF DISTINCT MODULES, THE INTERFACES BETWEEN THESE 
  543.              MODULES SHALL BE DESCRIBED.
  544.  
  545.  
  546. 2.2  CLASS (C2):    CONTROLLED ACCESS PROTECTION
  547.  
  548. Systems in this class enforce a more finely grained discretionary access
  549. control than (C1) systems, making users individually accountable for their
  550. actions through login procedures, auditing of security-relevant events, and
  551. resource isolation.  The following are minimal requirements for systems
  552. assigned a class (C2) rating:
  553.  
  554. 2.2.1  SECURITY POLICY
  555.  
  556.      2.2.1.1   Discretionary Access Control
  557.  
  558.                The TCB shall define and control access between named users and
  559.              named objects (e.g., files and programs) in the ADP system.  The
  560.              enforcement mechanism (e.g., self/group/public controls, access
  561.              control lists) shall allow users to specify and control sharing
  562.              of those objects by named individuals, or defined groups OF 
  563.              INDIVIDUALS, or by both.  THE DISCRETIONARY ACCESS CONTROL
  564.              MECHANISM SHALL, EITHER BY EXPLICIT USER ACTION OR BY DEFAULT,
  565.              PROVIDE THAT OBJECTS ARE PROTECTED FROM UNAUTHORIZED ACCESS. 
  566.              THESE ACCESS CONTROLS SHALL BE CAPABLE OF INCLUDING OR EXCLUDING
  567.              ACCESS TO THE GRANULARITY OF A SINGLE USER.  ACCESS PERMISSION 
  568.              TO AN OBJECT BY USERS NOT ALREADY POSSESSING ACCESS PERMISSION
  569.              SHALL ONLY BE ASSIGNED BY AUTHORIZED USERS.
  570.  
  571.      2.2.1.2   Object Reuse
  572.  
  573.                WHEN A STORAGE OBJECT IS INITIALLY ASSIGNED, ALLOCATED, OR
  574.              REALLOCATED TO A SUBJECT FROM THE TCB'S POOL OF UNUSED STORAGE
  575.              OBJECTS, THE TCB SHALL ASSURE THAT THE OBJECT CONTAINS NO DATA
  576.              FOR WHICH THE SUBJECT IS NOT AUTHORIZED.
  577.  
  578. 2.2.2  ACCOUNTABILITY
  579.  
  580.      2.2.2.1   Identification and Authentication
  581.  
  582.                The TCB shall require users to identify themselves to it before
  583.              beginning to perform any other actions that the TCB is expected
  584.              to mediate.  Furthermore, the TCB shall use a protected 
  585.              mechanism (e.g., passwords) to authenticate the user's identity.
  586.              The TCB shall protect authentication data so that it cannot be
  587.              accessed by any unauthorized user.  THE TCB SHALL BE ABLE TO
  588.              ENFORCE INDIVIDUAL ACCOUNTABILITY BY PROVIDING THE CAPABILITY TO
  589.              UNIQUELY IDENTIFY EACH INDIVIDUAL ADP SYSTEM USER.  THE TCB 
  590.              SHALL ALSO PROVIDE THE CAPABILITY OF ASSOCIATING THIS IDENTITY
  591.              WITH ALL AUDITABLE ACTIONS TAKEN BY THAT INDIVIDUAL.
  592.  
  593.      2.2.2.2   Audit
  594.  
  595.                THE TCB SHALL BE ABLE TO CREATE, MAINTAIN, AND PROTECT FROM
  596.              MODIFICATION OR UNAUTHORIZED ACCESS OR DESTRUCTION AN AUDIT 
  597.              TRAIL OF ACCESSES TO THE OBJECTS IT PROTECTS.  THE AUDIT DATA
  598.              SHALL BE PROTECTED BY THE TCB SO THAT READ ACCESS TO IT IS
  599.              LIMITED TO THOSE WHO ARE AUTHORIZED FOR AUDIT DATA.  THE TCB
  600.              SHALL BE ABLE TO RECORD THE FOLLOWING TYPES OF EVENTS: USE OF
  601.              IDENTIFICATION AND AUTHENTICATION MECHANISMS, INTRODUCTION OF 
  602.              OBJECTS INTO A USER'S ADDRESS SPACE (E.G., FILE OPEN, PROGRAM
  603.              INITIATION), DELETION OF OBJECTS, AND ACTIONS TAKEN BY
  604.              COMPUTER OPERATORS AND SYSTEM ADMINISTRATORS AND/OR SYSTEM
  605.              SECURITY OFFICERS.  FOR EACH RECORDED EVENT, THE AUDIT RECORD
  606.              SHALL IDENTIFY: DATE AND TIME OF THE EVENT, USER, TYPE OF 
  607.              EVENT, AND SUCCESS OR FAILURE OF THE EVENT.  FOR 
  608.              IDENTIFICATION/AUTHENTICATION EVENTS THE ORIGIN OF REQUEST
  609.              (E.G., TERMINAL ID) SHALL BE INCLUDED IN THE AUDIT RECORD.  FOR
  610.              EVENTS THAT INTRODUCE AN OBJECT INTO A USER'S ADDRESS SPACE AND
  611.              FOR OBJECT DELETION EVENTS THE AUDIT RECORD SHALL INCLUDE THE 
  612.              NAME OF THE OBJECT.  THE ADP SYSTEM ADMINISTRATOR SHALL BE ABLE
  613.              TO SELECTIVELY AUDIT THE ACTIONS OF ANY ONE OR MORE USERS BASED
  614.              ON INDIVIDUAL IDENTITY.
  615.  
  616. 2.2.3  ASSURANCE
  617.  
  618.      2.2.3.1   Operational Assurance
  619.  
  620.         2.2.3.1.1  System Architecture
  621.  
  622.                      The TCB shall maintain a domain for its own execution
  623.                  that protects it from external interference or tampering
  624.                  (e.g., by modification of its code or data structures). 
  625.                  Resources controlled by the TCB may be a defined subset
  626.                  of the subjects and objects in the ADP system.  THE TCB
  627.                  SHALL ISOLATE THE RESOURCES TO BE PROTECTED SO THAT THEY
  628.                  ARE SUBJECT TO THE ACCESS CONTROL AND AUDITING 
  629.                  REQUIREMENTS.
  630.  
  631.         2.2.3.1.2  System Integrity
  632.  
  633.                      Hardware and/or software features shall be provided that
  634.                  can be used to periodically validate the correct operation
  635.                  of the on-site hardware and firmware elements of the TCB.
  636.  
  637.      2.2.3.2   Life-Cycle Assurance
  638.  
  639.         2.2.3.2.1  Security Testing
  640.  
  641.                      The security mechanisms of the ADP system shall be tested
  642.                  and found to work as claimed in the system documentation.
  643.                  Testing shall be done to assure that there are no obvious
  644.                  ways for an unauthorized user to bypass or otherwise
  645.                  defeat the security protection mechanisms of the TCB.
  646.                  TESTING SHALL ALSO INCLUDE A SEARCH FOR OBVIOUS FLAWS THAT
  647.                  WOULD ALLOW VIOLATION OF RESOURCE ISOLATION, OR THAT WOULD
  648.                  PERMIT UNAUTHORIZED ACCESS TO THE AUDIT OR AUTHENTICATION
  649.                  DATA.  (See the Security Testing guidelines.)
  650.  
  651. 2.2.4  DOCUMENTATION
  652.  
  653.      2.2.4.1   Security Features User's Guide
  654.  
  655.                A single summary, chapter, or manual in user documentation
  656.              shall describe the protection mechanisms provided by the TCB, 
  657.              guidelines on their use, and how they interact with one another.
  658.  
  659.      2.2.4.2   Trusted Facility Manual
  660.  
  661.                A manual addressed to the ADP system administrator shall
  662.              present cautions about functions and privileges that should be
  663.              controlled when running a secure facility.  THE PROCEDURES FOR
  664.              EXAMINING AND MAINTAINING THE AUDIT FILES AS WELL AS THE
  665.              DETAILED AUDIT RECORD STRUCTURE FOR EACH TYPE OF AUDIT EVENT
  666.              SHALL BE GIVEN.
  667.  
  668.      2.2.4.3   Test Documentation
  669.  
  670.                The system developer shall provide to the evaluators a document
  671.              that describes the test plan and results of the security 
  672.              mechanisms' functional testing.
  673.  
  674.      2.2.4.4   Design Documentation
  675.  
  676.                Documentation shall be available that provides a description of
  677.              the manufacturer's philosophy of protection and an explanation
  678.              of how this philosophy is translated into the TCB.  If the TCB
  679.              is composed of distinct modules, the interfaces between these
  680.              modules shall be described.
  681.  
  682.  
  683.  
  684. 3.0  DIVISION B:    MANDATORY PROTECTION
  685.  
  686. The notion of a TCB that preserves the integrity of sensitivity labels and
  687. uses them to enforce a set of mandatory access control rules is a major
  688. requirement in this division.  Systems in this division must carry the
  689. sensitivity labels with major data structures in the system.  The system
  690. developer also provides the security policy model on which the TCB is based
  691. and furnishes a specification of the TCB.  Evidence must be provided to
  692. demonstrate that the reference monitor concept has been implemented.
  693.  
  694.  
  695. 3.1  CLASS (B1):    LABELED SECURITY PROTECTION
  696.  
  697. Class (B1) systems require all the features required for class (C2).  In
  698. addition, an informal statement of the security policy model, data labeling,
  699. and mandatory access control over named subjects and objects must be present.
  700. The capability must exist for accurately labeling exported information.  Any
  701. flaws identified by testing must be removed.  The following are minimal
  702. requirements for systems assigned a class (B1) rating:
  703.  
  704. 3.1.1  SECURITY POLICY
  705.  
  706.      3.1.1.1   Discretionary Access Control
  707.  
  708.                The TCB shall define and control access between named users and
  709.              named objects (e.g., files and programs) in the ADP system.  
  710.              The enforcement mechanism (e.g., self/group/public controls, 
  711.              access control lists) shall allow users to specify and control
  712.              sharing of those objects by named individuals, or defined groups
  713.              of individuals, or by both.  The discretionary access control
  714.              mechanism shall, either by explicit user action or by default,
  715.              provide that objects are protected from unauthorized access. 
  716.              These access controls shall be capable of including or excluding
  717.              access to the granularity of a single user.  Access permission
  718.              to an object by users not already possessing access permission
  719.              shall only be assigned by authorized users.
  720.  
  721.      3.1.1.2   Object Reuse
  722.  
  723.                When a storage object is initially assigned, allocated, or
  724.              reallocated to a subject from the TCB's pool of unused storage
  725.              objects, the TCB shall assure that the object contains no data
  726.              for which the subject is not authorized.
  727.  
  728.      3.1.1.3   Labels
  729.  
  730.                SENSITIVITY LABELS ASSOCIATED WITH EACH SUBJECT AND STORAGE
  731.              OBJECT UNDER ITS CONTROL (E.G., PROCESS, FILE, SEGMENT, DEVICE)
  732.              SHALL BE MAINTAINED BY THE TCB.  THESE LABELS SHALL BE USED AS
  733.              THE BASIS FOR MANDATORY ACCESS CONTROL DECISIONS.  IN ORDER TO
  734.              IMPORT NON-LABELED DATA, THE TCB SHALL REQUEST AND RECEIVE FROM
  735.              AN AUTHORIZED USER THE SECURITY LEVEL OF THE DATA, AND ALL SUCH
  736.              ACTIONS SHALL BE AUDITABLE BY THE TCB.
  737.  
  738.         3.1.1.3.1  Label Integrity
  739.  
  740.                      SENSITIVITY LABELS SHALL ACCURATELY REPRESENT SECURITY
  741.                  LEVELS OF THE SPECIFIC SUBJECTS OR OBJECTS WITH WHICH THEY
  742.                  ARE ASSOCIATED.  WHEN EXPORTED BY THE TCB, SENSITIVITY
  743.                  LABELS SHALL ACCURATELY AND UNAMBIGUOUSLY REPRESENT THE
  744.                  INTERNAL LABELS AND SHALL BE ASSOCIATED WITH THE 
  745.                  INFORMATION BEING EXPORTED.
  746.  
  747.         3.1.1.3.2  Exportation of Labeled Information
  748.  
  749.                      THE TCB SHALL DESIGNATE EACH COMMUNICATION CHANNEL AND
  750.                  I/O DEVICE AS EITHER SINGLE-LEVEL OR MULTILEVEL.  ANY
  751.                  CHANGE IN THIS DESIGNATION SHALL BE DONE MANUALLY AND
  752.                  SHALL BE AUDITABLE BY THE TCB.  THE TCB SHALL MAINTAIN
  753.                  AND BE ABLE TO AUDIT ANY CHANGE IN THE CURRENT SECURITY
  754.                  LEVEL ASSOCIATED WITH A SINGLE-LEVEL COMMUNICATION 
  755.                  CHANNEL OR I/O DEVICE.
  756.  
  757.              3.1.1.3.2.1  Exportation to Multilevel Devices
  758.  
  759.                             WHEN THE TCB EXPORTS AN OBJECT TO A MULTILEVEL I/O
  760.                         DEVICE, THE SENSITIVITY LABEL ASSOCIATED WITH THAT
  761.                         OBJECT SHALL ALSO BE EXPORTED AND SHALL RESIDE ON
  762.                         THE SAME PHYSICAL MEDIUM AS THE EXPORTED 
  763.                         INFORMATION AND SHALL BE IN THE SAME FORM 
  764.                         (I.E., MACHINE-READABLE OR  HUMAN-READABLE FORM).
  765.                         WHEN THE TCB EXPORTS OR IMPORTS AN OBJECT OVER A
  766.                         MULTILEVEL COMMUNICATION CHANNEL, THE PROTOCOL 
  767.                         USED ON THAT CHANNEL SHALL PROVIDE FOR THE
  768.                         UNAMBIGUOUS PAIRING BETWEEN THE SENSITIVITY LABELS
  769.                         AND THE ASSOCIATED INFORMATION THAT IS SENT OR 
  770.                         RECEIVED.
  771.  
  772.              3.1.1.3.2.2  Exportation to Single-Level Devices
  773.  
  774.                         SINGLE-LEVEL I/O DEVICES AND SINGLE-LEVEL
  775.                         COMMUNICATION CHANNELS ARE NOT REQUIRED TO 
  776.                         MAINTAIN THE SENSITIVITY LABELS OF THE INFORMATION
  777.                         THEY PROCESS.  HOWEVER, THE TCB SHALL INCLUDE A 
  778.                         MECHANISM BY WHICH THE TCB AND AN AUTHORIZED USER
  779.                         RELIABLY COMMUNICATE TO DESIGNATE THE SINGLE
  780.                         SECURITY LEVEL OF INFORMATION IMPORTED OR EXPORTED
  781.                         VIA SINGLE-LEVEL COMMUNICATION CHANNELS OR I/O 
  782.                         DEVICES.
  783.  
  784.              3.1.1.3.2.3  Labeling Human-Readable Output
  785.  
  786.                         THE ADP SYSTEM ADMINISTRATOR SHALL BE ABLE TO
  787.                         SPECIFY THE PRINTABLE LABEL NAMES ASSOCIATED WITH
  788.                         EXPORTED SENSITIVITY LABELS.  THE TCB SHALL MARK
  789.                         THE BEGINNING AND END OF ALL HUMAN-READABLE, PAGED,
  790.                         HARDCOPY OUTPUT (E.G., LINE PRINTER OUTPUT) WITH
  791.                         HUMAN-READABLE SENSITIVITY LABELS THAT PROPERLY*
  792.                         REPRESENT THE SENSITIVITY OF THE OUTPUT.  THE TCB
  793.                         SHALL, BY DEFAULT, MARK THE TOP AND BOTTOM OF EACH
  794.                         PAGE OF HUMAN-READABLE, PAGED, HARDCOPY OUTPUT
  795.                         (E.G., LINE PRINTER OUTPUT) WITH HUMAN-READABLE
  796.                         SENSITIVITY LABELS THAT PROPERLY* REPRESENT THE
  797.                         OVERALL SENSITIVITY OF THE OUTPUT OR THAT PROPERLY*
  798.                         REPRESENT THE SENSITIVITY OF THE INFORMATION ON THE
  799.                         PAGE.  THE TCB SHALL, BY DEFAULT AND IN AN
  800.                         APPROPRIATE MANNER, MARK OTHER FORMS OF HUMAN-
  801.                         READABLE OUTPUT (E.G., MAPS, GRAPHICS) WITH HUMAN-
  802.                         READABLE SENSITIVITY LABELS THAT PROPERLY*
  803.                         REPRESENT THE SENSITIVITY OF THE OUTPUT.  ANY 
  804.                         OVERRIDE OF THESE MARKING DEFAULTS SHALL BE 
  805.                         AUDITABLE BY THE TCB.
  806.  
  807.  
  808.            _____________________________________________________________
  809.            * THE HIERARCHICAL CLASSIFICATION COMPONENT IN HUMAN-READABLE
  810.            SENSITIVITY LABELS SHALL BE EQUAL TO THE GREATEST
  811.            HIERARCHICAL CLASSIFICATION OF ANY OF THE INFORMATION IN THE
  812.            OUTPUT THAT THE LABELS REFER TO;  THE NON-HIERARCHICAL
  813.            CATEGORY COMPONENT SHALL INCLUDE ALL OF THE NON-HIERARCHICAL
  814.            CATEGORIES OF THE INFORMATION IN THE OUTPUT THE LABELS REFER
  815.            TO, BUT NO OTHER NON-HIERARCHICAL CATEGORIES.
  816.            _____________________________________________________________
  817.  
  818.  
  819.      3.1.1.4   Mandatory Access Control
  820.  
  821.                THE TCB SHALL ENFORCE A MANDATORY ACCESS CONTROL POLICY OVER
  822.              ALL SUBJECTS AND STORAGE OBJECTS UNDER ITS CONTROL (E.G., 
  823.              PROCESSES, FILES, SEGMENTS, DEVICES).  THESE SUBJECTS AND 
  824.              OBJECTS SHALL BE ASSIGNED SENSITIVITY LABELS THAT ARE A
  825.              COMBINATION OF HIERARCHICAL CLASSIFICATION LEVELS AND
  826.              NON-HIERARCHICAL CATEGORIES, AND THE LABELS SHALL BE USED AS
  827.              THE BASIS FOR MANDATORY ACCESS CONTROL DECISIONS.  THE TCB 
  828.              SHALL BE ABLE TO SUPPORT TWO OR MORE SUCH SECURITY LEVELS.
  829.              (SEE THE MANDATORY ACCESS CONTROL GUIDELINES.) THE FOLLOWING
  830.              REQUIREMENTS SHALL HOLD FOR ALL ACCESSES BETWEEN SUBJECTS AND
  831.              OBJECTS CONTROLLED BY THE TCB: A SUBJECT CAN READ AN OBJECT
  832.              ONLY IF THE HIERARCHICAL CLASSIFICATION IN THE SUBJECT'S
  833.              SECURITY LEVEL IS GREATER THAN OR EQUAL TO THE HIERARCHICAL
  834.              CLASSIFICATION IN THE OBJECT'S SECURITY LEVEL AND THE NON-
  835.              HIERARCHICAL CATEGORIES IN THE SUBJECT'S SECURITY LEVEL INCLUDE
  836.              ALL THE NON-HIERARCHICAL CATEGORIES IN THE OBJECT'S SECURITY
  837.              LEVEL.  A SUBJECT CAN WRITE AN OBJECT ONLY IF THE HIERARCHICAL
  838.              CLASSIFICATION IN THE SUBJECT'S SECURITY LEVEL IS LESS THAN OR
  839.              EQUAL TO THE HIERARCHICAL CLASSIFICATION IN THE OBJECT'S
  840.              SECURITY LEVEL AND ALL THE NON-HIERARCHICAL CATEGORIES IN THE
  841.              SUBJECT'S SECURITY LEVEL ARE INCLUDED IN THE NON- HIERARCHICAL
  842.              CATEGORIES IN THE OBJECT'S SECURITY LEVEL.
  843.  
  844. 3.1.2  ACCOUNTABILITY
  845.  
  846.      3.1.2.1   Identification and Authentication
  847.  
  848.                The TCB shall require users to identify themselves to it before
  849.              beginning to perform any other actions that the TCB is expected
  850.              to mediate.  Furthermore, the TCB shall MAINTAIN AUTHENTICATION
  851.              DATA THAT INCLUDES INFORMATION FOR VERIFYING THE IDENTITY OF 
  852.              INDIVIDUAL USERS (E.G., PASSWORDS) AS WELL AS INFORMATION FOR
  853.              DETERMINING THE CLEARANCE AND AUTHORIZATIONS OF INDIVIDUAL
  854.              USERS.  THIS DATA SHALL BE USED BY THE TCB TO AUTHENTICATE the
  855.              user's identity AND TO DETERMINE THE SECURITY LEVEL AND 
  856.              AUTHORIZATIONS OF SUBJECTS THAT MAY BE CREATED TO ACT ON BEHALF
  857.              OF THE INDIVIDUAL USER.  The TCB shall protect authentication
  858.              data so that it cannot be accessed by any unauthorized user.  
  859.              The TCB shall be able to enforce individual accountability by
  860.              providing the capability to uniquely identify each individual
  861.              ADP system user.  The TCB shall also provide the capability of
  862.              associating this identity with all auditable actions taken by
  863.              that individual.
  864.  
  865.      3.1.2.2   Audit
  866.  
  867.                The TCB shall be able to create, maintain, and protect from
  868.              modification or unauthorized access or destruction an audit
  869.              trail of accesses to the objects it protects.  The audit data
  870.              shall be protected by the TCB so that read access to it is
  871.              limited to those who are authorized for audit data.  The TCB
  872.              shall be able to record the following types of events: use of
  873.              identification and authentication mechanisms, introduction of
  874.              objects into a user's address space (e.g., file open, program
  875.              initiation), deletion of objects, and actions taken by computer
  876.              operators and system administrators and/or system security
  877.              officers.  THE TCB SHALL ALSO BE ABLE TO AUDIT ANY OVERRIDE OF
  878.              HUMAN-READABLE OUTPUT MARKINGS.  FOR each recorded event, the
  879.              audit record shall identify: date and time of the event, user,
  880.              type of event, and success or failure of the event.  For 
  881.              identification/authentication events the origin of request
  882.              (e.g., terminal ID) shall be included in the audit record.
  883.              For events that introduce an object into a user's address space
  884.              and for object deletion events the audit record shall include
  885.              the name of the object AND THE OBJECT'S SECURITY LEVEL.  The 
  886.              ADP system administrator shall be able to selectively audit the
  887.              actions of any one or more users based on individual identity
  888.              AND/OR OBJECT SECURITY LEVEL.
  889.  
  890. 3.1.3  ASSURANCE
  891.  
  892.      3.1.3.1   Operational Assurance
  893.  
  894.         3.1.3.1.1  System Architecture
  895.  
  896.                      The TCB shall maintain a domain for its own execution
  897.                  that protects it from external interference or tampering
  898.                  (e.g., by modification of its code or data structures). 
  899.                  Resources controlled by the TCB may be a defined subset
  900.                  of the subjects and objects in the ADP system.  THE TCB
  901.                  SHALL MAINTAIN PROCESS ISOLATION THROUGH THE PROVISION OF
  902.                  DISTINCT ADDRESS SPACES UNDER ITS CONTROL.  The TCB shall
  903.                  isolate the resources to be protected so that they are
  904.                  subject to the access control and auditing requirements.
  905.  
  906.         3.1.3.1.2  System Integrity
  907.  
  908.                      Hardware and/or software features shall be provided that
  909.                  can be used to periodically validate the correct operation
  910.                  of the on-site hardware and firmware elements of the TCB.
  911.  
  912.      3.1.3.2   Life-Cycle Assurance
  913.  
  914.         3.1.3.2.1  Security Testing
  915.  
  916.                      THE SECURITY MECHANISMS OF THE ADP SYSTEM SHALL BE TESTED
  917.                  AND FOUND TO WORK AS CLAIMED IN THE SYSTEM DOCUMENTATION. 
  918.                  A TEAM OF INDIVIDUALS WHO THOROUGHLY UNDERSTAND THE
  919.                  SPECIFIC IMPLEMENTATION OF THE TCB SHALL SUBJECT ITS
  920.                  DESIGN DOCUMENTATION, SOURCE CODE, AND OBJECT CODE TO
  921.                  THOROUGH ANALYSIS AND TESTING.  THEIR OBJECTIVES SHALL BE:
  922.                  TO UNCOVER ALL DESIGN AND IMPLEMENTATION FLAWS THAT WOULD
  923.                  PERMIT A SUBJECT EXTERNAL TO THE TCB TO READ, CHANGE, OR
  924.                  DELETE DATA NORMALLY DENIED UNDER THE MANDATORY OR
  925.                  DISCRETIONARY SECURITY POLICY ENFORCED BY THE TCB; AS WELL
  926.                  AS TO ASSURE THAT NO SUBJECT (WITHOUT AUTHORIZATION TO DO
  927.                  SO) IS ABLE TO CAUSE THE TCB TO ENTER A STATE SUCH THAT
  928.                  IT IS UNABLE TO RESPOND TO COMMUNICATIONS INITIATED BY
  929.                  OTHER USERS.  ALL DISCOVERED FLAWS SHALL BE REMOVED OR
  930.                  NEUTRALIZED AND THE TCB RETESTED TO DEMONSTRATE THAT THEY
  931.                  HAVE BEEN ELIMINATED AND THAT NEW FLAWS HAVE NOT BEEN
  932.                  INTRODUCED.  (SEE THE SECURITY TESTING GUIDELINES.)
  933.  
  934.         3.1.3.2.2  Design Specification and Verification
  935.  
  936.                      AN INFORMAL OR FORMAL MODEL OF THE SECURITY POLICY
  937.                  SUPPORTED BY THE TCB SHALL BE MAINTAINED THAT IS SHOWN TO
  938.                  BE CONSISTENT WITH ITS AXIOMS.
  939.  
  940. 3.1.4  DOCUMENTATION
  941.  
  942.      3.1.4.1   Security Features User's Guide
  943.  
  944.                A single summary, chapter, or manual in user documentation
  945.              shall describe the protection mechanisms provided by the TCB,
  946.              guidelines on their use, and how they interact with one another.
  947.  
  948.      3.1.4.2   Trusted Facility Manual
  949.  
  950.                A manual addressed to the ADP system administrator shall
  951.              present cautions about functions and privileges that should be
  952.              controlled when running a secure facility.  The procedures for
  953.              examining and maintaining the audit files as well as the
  954.              detailed audit record structure for each type of audit event
  955.              shall be given.  THE MANUAL SHALL DESCRIBE THE OPERATOR AND
  956.              ADMINISTRATOR FUNCTIONS RELATED TO SECURITY, TO INCLUDE CHANGING
  957.              THE SECURITY CHARACTERISTICS OF A USER.  IT SHALL PROVIDE 
  958.              GUIDELINES ON THE CONSISTENT AND EFFECTIVE USE OF THE PROTECTION
  959.              FEATURES OF THE SYSTEM, HOW THEY INTERACT, HOW TO SECURELY
  960.              GENERATE A NEW TCB, AND FACILITY PROCEDURES, WARNINGS, AND
  961.              PRIVILEGES THAT NEED TO BE CONTROLLED IN ORDER TO OPERATE THE 
  962.              FACILITY IN A SECURE MANNER.
  963.  
  964.      3.1.4.3   Test Documentation
  965.  
  966.                The system developer shall provide to the evaluators a document
  967.              that describes the test plan and results of the security 
  968.              mechanisms' functional testing.
  969.  
  970.      3.1.4.4   Design Documentation
  971.  
  972.                Documentation shall be available that provides a description of
  973.              the manufacturer's philosophy of protection and an explanation
  974.              of how this philosophy is translated into the TCB.  If the TCB
  975.              is composed of distinct modules, the interfaces between these
  976.              modules shall be described.  AN INFORMAL OR FORMAL DESCRIPTION
  977.              OF THE SECURITY POLICY MODEL ENFORCED BY THE TCB SHALL BE
  978.              AVAILABLE AND AN EXPLANATION PROVIDED TO SHOW THAT IT IS 
  979.              SUFFICIENT TO ENFORCE THE SECURITY POLICY.  THE SPECIFIC TCB 
  980.              PROTECTION MECHANISMS SHALL BE IDENTIFIED AND AN EXPLANATION
  981.              GIVEN TO SHOW THAT THEY SATISFY THE MODEL.
  982.  
  983.  
  984. 3.2  CLASS (B2):    STRUCTURED PROTECTION
  985.  
  986. In class (B2) systems, the TCB is based on a clearly defined and documented
  987. formal security policy model that requires the discretionary and mandatory
  988. access control enforcement found in class (B1) systems be extended to all
  989. subjects and objects in the ADP system.  In addition, covert channels are
  990. addressed.  The TCB must be carefully structured into protection-critical and
  991. non- protection-critical elements.  The TCB interface is well-defined and the
  992. TCB design and implementation enable it to be subjected to more thorough
  993. testing and more complete review.  Authentication mechanisms are strengthened,
  994. trusted facility management is provided in the form of support for system
  995. administrator and operator functions, and stringent configuration management
  996. controls are imposed.  The system is relatively resistant to penetration.  The
  997. following are minimal requirements for systems assigned a class (B2) rating:
  998.  
  999. 3.2.1  SECURITY POLICY
  1000.  
  1001.      3.2.1.1   Discretionary Access Control
  1002.  
  1003.                The TCB shall define and control access between named users and
  1004.              named objects (e.g., files and programs) in the ADP system.
  1005.              The enforcement mechanism (e.g., self/group/public controls,
  1006.              access control lists) shall allow users to specify and control
  1007.              sharing of those objects by named individuals, or defined
  1008.              groups of individuals, or by both.  The discretionary access
  1009.              control mechanism shall, either by explicit user action or by
  1010.              default, provide that objects are protected from unauthorized
  1011.              access.  These access controls shall be capable of including
  1012.              or excluding access to the granularity of a single user.
  1013.              Access permission to an object by users not already possessing
  1014.              access permission shall only be assigned by authorized users.
  1015.  
  1016.      3.2.1.2   Object Reuse
  1017.  
  1018.                When a storage object is initially assigned, allocated, or
  1019.              reallocated to a subject from the TCB's pool of unused storage
  1020.              objects, the TCB shall assure that the object contains no data
  1021.              for which the subject is not authorized.
  1022.  
  1023.      3.2.1.3   Labels
  1024.  
  1025.                Sensitivity labels associated with each ADP SYSTEM RESOURCE
  1026.              (E.G., SUBJECT, STORAGE OBJECT) THAT IS DIRECTLY OR INDIRECTLY
  1027.              ACCESSIBLE BY SUBJECTS EXTERNAL TO THE TCB shall be maintained
  1028.              by the TCB.  These labels shall be used as the basis for
  1029.              mandatory access control decisions.  In order to import non-
  1030.              labeled data, the TCB shall request and receive from an
  1031.              authorized user the security level of the data, and all such
  1032.              actions shall be auditable by the TCB.
  1033.  
  1034.         3.2.1.3.1  Label Integrity
  1035.  
  1036.                  Sensitivity labels shall accurately represent security
  1037.                  levels of the specific subjects or objects with which
  1038.                  they are associated.  When exported by the TCB,
  1039.                  sensitivity labels shall accurately and unambiguously
  1040.                  represent the internal labels and shall be associated
  1041.                  with the information being exported.
  1042.  
  1043.         3.2.1.3.2  Exportation of Labeled Information
  1044.  
  1045.                  The TCB shall designate each communication channel and
  1046.                  I/O device as either single-level or multilevel.  Any
  1047.                  change in this designation shall be done manually and
  1048.                  shall be auditable by the TCB.  The TCB shall maintain
  1049.                  and be able to audit any change in the current security
  1050.                  level associated with a single-level communication
  1051.                  channel or I/O device.
  1052.  
  1053.              3.2.1.3.2.1  Exportation to Multilevel Devices
  1054.  
  1055.                         When the TCB exports an object to a multilevel I/O
  1056.                         device, the sensitivity label associated with that
  1057.                         object shall also be exported and shall reside on
  1058.                         the same physical medium as the exported 
  1059.                         information and shall be in the same form (i.e., 
  1060.                         machine-readable or human-readable form).  When
  1061.                         the TCB exports or imports an object over a
  1062.                         multilevel communication channel, the protocol
  1063.                         used on that channel shall provide for the
  1064.                         unambiguous pairing between the sensitivity labels
  1065.                         and the associated information that is sent or
  1066.                         received.
  1067.  
  1068.              3.2.1.3.2.2  Exportation to Single-Level Devices
  1069.  
  1070.                         Single-level I/O devices and single-level
  1071.                         communication channels are not required to 
  1072.                         maintain the sensitivity labels of the
  1073.                         information they process.  However, the TCB shall
  1074.                         include a mechanism by which the TCB and an
  1075.                         authorized user reliably communicate to designate
  1076.                         the single security level of information imported
  1077.                         or exported via single-level communication 
  1078.                         channels or I/O devices.
  1079.  
  1080.              3.2.1.3.2.3  Labeling Human-Readable Output
  1081.  
  1082.                         The ADP system administrator shall be able to
  1083.                         specify the printable label names associated with
  1084.                         exported sensitivity labels.  The TCB shall mark
  1085.                         the beginning and end of all human-readable, paged,
  1086.                         hardcopy output (e.g., line printer output) with
  1087.                         human-readable sensitivity labels that properly*
  1088.                         represent the sensitivity of the output.  The TCB
  1089.                         shall, by default, mark the top and bottom of each
  1090.                         page of human-readable, paged, hardcopy output
  1091.                         (e.g., line printer output) with human-readable
  1092.                         sensitivity labels that properly* represent the
  1093.                         overall sensitivity of the output or that 
  1094.                         properly* represent the sensitivity of the
  1095.                         information on the page.  The TCB shall, by
  1096.                         default and in an appropriate manner, mark other
  1097.                         forms of human-readable output (e.g., maps,
  1098.                         graphics) with human-readable sensitivity labels
  1099.                         that properly* represent the sensitivity of the
  1100.                         output.  Any override of these marking defaults
  1101.                         shall be auditable by the TCB.
  1102.            _____________________________________________________________
  1103.            * The hierarchical classification component in human-readable
  1104.            sensitivity labels shall be equal to the greatest
  1105.            hierarchical classification of any of the information in the
  1106.            output that the labels refer to;  the non-hierarchical
  1107.            category component shall include all of the non-hierarchical
  1108.            categories of the information in the output the labels refer
  1109.            to, but no other non-hierarchical categories.
  1110.            _____________________________________________________________
  1111.  
  1112.  
  1113.         3.2.1.3.3  Subject Sensitivity Labels
  1114.  
  1115.                  THE TCB SHALL IMMEDIATELY NOTIFY A TERMINAL USER OF EACH
  1116.                  CHANGE IN THE SECURITY LEVEL ASSOCIATED WITH THAT USER
  1117.                  DURING AN INTERACTIVE SESSION.  A TERMINAL USER SHALL BE
  1118.                  ABLE TO QUERY THE TCB AS DESIRED FOR A DISPLAY OF THE
  1119.                  SUBJECT'S COMPLETE SENSITIVITY LABEL.
  1120.  
  1121.         3.2.1.3.4  Device Labels
  1122.  
  1123.                  THE TCB SHALL SUPPORT THE ASSIGNMENT OF MINIMUM AND
  1124.                  MAXIMUM SECURITY LEVELS TO ALL ATTACHED PHYSICAL DEVICES.
  1125.                  THESE SECURITY LEVELS SHALL BE USED BY THE TCB TO ENFORCE
  1126.                  CONSTRAINTS IMPOSED BY THE PHYSICAL ENVIRONMENTS IN WHICH
  1127.                  THE DEVICES ARE LOCATED.
  1128.  
  1129.      3.2.1.4   Mandatory Access Control
  1130.  
  1131.                The TCB shall enforce a mandatory access control policy over
  1132.              all RESOURCES (I.E., SUBJECTS, STORAGE OBJECTS, AND I/O DEVICES)
  1133.              THAT ARE DIRECTLY OR INDIRECTLY ACCESSIBLE BY SUBJECTS EXTERNAL
  1134.              TO THE TCB.  These subjects and objects shall be assigned
  1135.              sensitivity labels that are a combination of hierarchical
  1136.              classification levels and non-hierarchical categories, and the
  1137.              labels shall be used as the basis for mandatory access control
  1138.              decisions.  The TCB shall be able to support two or more such
  1139.              security levels.  (See the Mandatory Access Control guidelines.)
  1140.              The following requirements shall hold for all accesses between
  1141.              ALL SUBJECTS EXTERNAL TO THE TCB AND ALL OBJECTS DIRECTLY OR
  1142.              INDIRECTLY ACCESSIBLE BY THESE SUBJECTS: A subject can read an
  1143.              object only if the hierarchical classification in the subject's
  1144.              security level is greater than or equal to the hierarchical
  1145.              classification in the object's security level and the non-
  1146.              hierarchical categories in the subject's security level include
  1147.              all the non-hierarchical categories in the object's security
  1148.              level.  A subject can write an object only if the hierarchical
  1149.              classification in the subject's security level is less than or
  1150.              equal to the hierarchical classification in the object's
  1151.              security level and all the non-hierarchical categories in the
  1152.              subject's security level are included in the non-hierarchical
  1153.              categories in the object's security level.
  1154.  
  1155. 3.2.2  ACCOUNTABILITY
  1156.  
  1157.      3.2.2.1   Identification and Authentication
  1158.  
  1159.                The TCB shall require users to identify themselves to it before
  1160.              beginning to perform any other actions that the TCB is expected
  1161.              to mediate.  Furthermore, the TCB shall maintain authentication
  1162.              data that includes information for verifying the identity of
  1163.              individual users (e.g., passwords) as well as information for
  1164.              determining the clearance and authorizations of individual
  1165.              users.  This data shall be used by the TCB to authenticate the
  1166.              user's identity and to determine the security level and
  1167.              authorizations of subjects that may be created to act on behalf
  1168.              of the individual user.  The TCB shall protect authentication
  1169.              data so that it cannot be accessed by any unauthorized user.
  1170.              The TCB shall be able to enforce individual accountability by
  1171.              providing the capability to uniquely identify each individual
  1172.              ADP system user.  The TCB shall also provide the capability of
  1173.              associating this identity with all auditable actions taken by
  1174.              that individual.
  1175.  
  1176.         3.2.2.1.1  Trusted Path
  1177.  
  1178.                  THE TCB SHALL SUPPORT A TRUSTED COMMUNICATION PATH
  1179.                  BETWEEN ITSELF AND USER FOR INITIAL LOGIN AND
  1180.                  AUTHENTICATION.  COMMUNICATIONS VIA THIS PATH SHALL BE
  1181.                  INITIATED EXCLUSIVELY BY A USER.
  1182.  
  1183.      3.2.2.2   Audit
  1184.  
  1185.                The TCB shall be able to create, maintain, and protect from
  1186.              modification or unauthorized access or destruction an audit
  1187.              trail of accesses to the objects it protects.  The audit data
  1188.              shall be protected by the TCB so that read access to it is
  1189.              limited to those who are authorized for audit data.  The TCB
  1190.              shall be able to record the following types of events: use of
  1191.              identification and authentication mechanisms, introduction of
  1192.              objects into a user's address space (e.g., file open, program
  1193.              initiation), deletion of objects, and actions taken by computer
  1194.              operators and system administrators and/or system security
  1195.              officers.  The TCB shall also be able to audit any override of
  1196.              human-readable output markings.  For each recorded event, the
  1197.              audit record shall identify: date and time of the event, user,
  1198.              type of event, and success or failure of the event.  For
  1199.              identification/authentication events the origin of request
  1200.              (e.g., terminal ID) shall be included in the audit record.  For
  1201.              events that introduce an object into a user's address space and
  1202.              for object deletion events the audit record shall include the
  1203.              name of the object and the object's security level.  The ADP
  1204.              system administrator shall be able to selectively audit the
  1205.              actions of any one or more users based on individual identity
  1206.              and/or object security level.  THE TCB SHALL BE ABLE TO AUDIT
  1207.              THE IDENTIFIED EVENTS THAT MAY BE USED IN THE EXPLOITATION OF
  1208.              COVERT STORAGE CHANNELS.
  1209.  
  1210. 3.2.3  ASSURANCE
  1211.  
  1212.      3.2.3.1   Operational Assurance
  1213.  
  1214.         3.2.3.1.1  System Architecture
  1215.  
  1216.                  THE TCB SHALL MAINTAIN A DOMAIN FOR ITS OWN EXECUTION
  1217.                  THAT PROTECTS IT FROM EXTERNAL INTERFERENCE OR TAMPERING
  1218.                  (E.G., BY MODIFICATION OF ITS CODE OR DATA STRUCTURES).
  1219.                    THE TCB SHALL MAINTAIN PROCESS ISOLATION THROUGH THE
  1220.                  PROVISION OF DISTINCT ADDRESS SPACES UNDER ITS CONTROL.
  1221.                  THE TCB SHALL BE INTERNALLY STRUCTURED INTO WELL-DEFINED
  1222.                  LARGELY INDEPENDENT MODULES.  IT SHALL MAKE EFFECTIVE USE
  1223.                  OF AVAILABLE HARDWARE TO SEPARATE THOSE ELEMENTS THAT ARE
  1224.                  PROTECTION-CRITICAL FROM THOSE THAT ARE NOT.  THE TCB
  1225.                  MODULES SHALL BE DESIGNED SUCH THAT THE PRINCIPLE OF LEAST
  1226.                  PRIVILEGE IS ENFORCED.  FEATURES IN HARDWARE, SUCH AS
  1227.                  SEGMENTATION, SHALL BE USED TO SUPPORT LOGICALLY DISTINCT
  1228.                  STORAGE OBJECTS WITH SEPARATE ATTRIBUTES (NAMELY:
  1229.                  READABLE, WRITEABLE).  THE USER INTERFACE TO THE TCB 
  1230.                  SHALL BE COMPLETELY DEFINED AND ALL ELEMENTS OF THE TCB
  1231.                  IDENTIFIED.
  1232.  
  1233.         3.2.3.1.2  System Integrity
  1234.  
  1235.                  Hardware and/or software features shall be provided that
  1236.                  can be used to periodically validate the correct 
  1237.                  operation of the on-site hardware and firmware elements 
  1238.                  of the TCB.
  1239.  
  1240.         3.2.3.1.3  Covert Channel Analysis
  1241.  
  1242.                  THE SYSTEM DEVELOPER SHALL CONDUCT A THOROUGH SEARCH FOR
  1243.                  COVERT STORAGE CHANNELS AND MAKE A DETERMINATION (EITHER
  1244.                  BY ACTUAL MEASUREMENT OR BY ENGINEERING ESTIMATION) OF
  1245.                  THE MAXIMUM BANDWIDTH OF EACH IDENTIFIED CHANNEL.  (SEE
  1246.                  THE COVERT CHANNELS GUIDELINE SECTION.)
  1247.  
  1248.         3.2.3.1.4  Trusted Facility Management
  1249.  
  1250.                  THE TCB SHALL SUPPORT SEPARATE OPERATOR AND ADMINISTRATOR
  1251.                  FUNCTIONS.
  1252.  
  1253.      3.2.3.2   Life-Cycle Assurance
  1254.  
  1255.         3.2.3.2.1  Security Testing
  1256.  
  1257.                  The security mechanisms of the ADP system shall be tested
  1258.                  and found to work as claimed in the system documentation. 
  1259.                  A team of individuals who thoroughly understand the
  1260.                  specific implementation of the TCB shall subject its
  1261.                  design documentation, source code, and object code to
  1262.                  thorough analysis and testing.  Their objectives shall be:
  1263.                  to uncover all design and implementation flaws that would
  1264.                  permit a subject external to the TCB to read, change, or
  1265.                  delete data normally denied under the mandatory or
  1266.                  discretionary security policy enforced by the TCB; as well
  1267.                  as to assure that no subject (without authorization to do
  1268.                  so) is able to cause the TCB to enter a state such that it
  1269.                  is unable to respond to communications initiated by other
  1270.                  users.  THE TCB SHALL BE FOUND RELATIVELY RESISTANT TO
  1271.                  PENETRATION.  All discovered flaws shall be CORRECTED and
  1272.                  the TCB retested to demonstrate that they have been
  1273.                  eliminated and that new flaws have not been introduced.
  1274.                  TESTING SHALL DEMONSTRATE THAT THE TCB IMPLEMENTATION IS
  1275.                  CONSISTENT WITH THE DESCRIPTIVE TOP-LEVEL SPECIFICATION. 
  1276.                  (See the Security Testing Guidelines.)
  1277.  
  1278.         3.2.3.2.2  Design Specification and Verification
  1279.  
  1280.                  A FORMAL model of the security policy supported by the
  1281.                  TCB shall be maintained that is PROVEN consistent with
  1282.                  its axioms.  A DESCRIPTIVE TOP-LEVEL SPECIFICATION (DTLS)
  1283.                  OF THE TCB SHALL BE MAINTAINED THAT COMPLETELY AND
  1284.                  ACCURATELY DESCRIBES THE TCB IN TERMS OF EXCEPTIONS, ERROR
  1285.                  MESSAGES, AND EFFECTS.  IT SHALL BE SHOWN TO BE AN
  1286.                  ACCURATE DESCRIPTION OF THE TCB INTERFACE.
  1287.  
  1288.         3.2.3.2.3  Configuration Management
  1289.  
  1290.                  DURING DEVELOPMENT AND MAINTENANCE OF THE TCB, A
  1291.                  CONFIGURATION MANAGEMENT SYSTEM SHALL BE IN PLACE THAT
  1292.                  MAINTAINS CONTROL OF CHANGES TO THE DESCRIPTIVE TOP-LEVEL
  1293.                  SPECIFICATION, OTHER DESIGN DATA, IMPLEMENTATION
  1294.                  DOCUMENTATION, SOURCE CODE, THE RUNNING VERSION OF THE
  1295.                  OBJECT CODE, AND TEST FIXTURES AND DOCUMENTATION.  THE
  1296.                  CONFIGURATION MANAGEMENT SYSTEM SHALL ASSURE A CONSISTENT
  1297.                  MAPPING AMONG ALL DOCUMENTATION AND CODE ASSOCIATED WITH
  1298.                  THE CURRENT VERSION OF THE TCB.  TOOLS SHALL BE PROVIDED
  1299.                  FOR GENERATION OF A NEW VERSION OF THE TCB FROM SOURCE
  1300.                  CODE.  ALSO AVAILABLE SHALL BE TOOLS FOR COMPARING A 
  1301.                  NEWLY GENERATED VERSION WITH THE PREVIOUS TCB VERSION IN
  1302.                  ORDER TO ASCERTAIN THAT ONLY THE INTENDED CHANGES HAVE
  1303.                  BEEN MADE IN THE CODE THAT WILL ACTUALLY BE USED AS THE
  1304.                  NEW VERSION OF THE TCB.
  1305.  
  1306. 3.2.4  DOCUMENTATION
  1307.  
  1308.      3.2.4.1   Security Features User's Guide
  1309.  
  1310.                A single summary, chapter, or manual in user documentation
  1311.              shall describe the protection mechanisms provided by the TCB,
  1312.              guidelines on their use, and how they interact with one another.
  1313.  
  1314.      3.2.4.2   Trusted Facility Manual
  1315.  
  1316.                A manual addressed to the ADP system administrator shall
  1317.              present cautions about functions and privileges that should be
  1318.              controlled when running a secure facility.  The procedures for
  1319.              examining and maintaining the audit files as well as the
  1320.              detailed audit record structure for each type of audit event
  1321.              shall be given.  The manual shall describe the operator and
  1322.              administrator functions related to security, to include 
  1323.              changing the security characteristics of a user.  It shall
  1324.              provide guidelines on the consistent and effective use of the
  1325.              protection features of the system, how they interact, how to
  1326.              securely generate a new TCB, and facility procedures, warnings,
  1327.              and privileges that need to be controlled in order to operate
  1328.              the facility in a secure manner.  THE TCB MODULES THAT CONTAIN
  1329.              THE REFERENCE VALIDATION MECHANISM SHALL BE IDENTIFIED.  THE
  1330.              PROCEDURES FOR SECURE GENERATION OF A NEW TCB FROM SOURCE AFTER
  1331.              MODIFICATION OF ANY MODULES IN THE TCB SHALL BE DESCRIBED.
  1332.  
  1333.      3.2.4.3   Test Documentation
  1334.  
  1335.                The system developer shall provide to the evaluators a document
  1336.              that describes the test plan and results of the security
  1337.              mechanisms' functional testing.  IT SHALL INCLUDE RESULTS OF
  1338.              TESTING THE EFFECTIVENESS OF THE METHODS USED TO REDUCE COVERT
  1339.              CHANNEL BANDWIDTHS.
  1340.  
  1341.      3.2.4.4   Design Documentation
  1342.  
  1343.                Documentation shall be available that provides a description of
  1344.              the manufacturer's philosophy of protection and an explanation
  1345.              of how this philosophy is translated into the TCB.  THE
  1346.              interfaces between THE TCB modules shall be described.  A
  1347.              FORMAL description of the security policy model enforced by the
  1348.              TCB shall be available and PROVEN that it is sufficient to
  1349.              enforce the security policy.  The specific TCB protection 
  1350.              mechanisms shall be identified and an explanation given to show
  1351.              that they satisfy the model.  THE DESCRIPTIVE TOP-LEVEL
  1352.              SPECIFICATION (DTLS) SHALL BE SHOWN TO BE AN ACCURATE 
  1353.              DESCRIPTION OF THE TCB INTERFACE.  DOCUMENTATION SHALL DESCRIBE
  1354.              HOW THE TCB IMPLEMENTS THE REFERENCE MONITOR CONCEPT AND GIVE
  1355.              AN EXPLANATION WHY IT IS TAMPERPROOF, CANNOT BE BYPASSED, AND
  1356.              IS CORRECTLY IMPLEMENTED.  DOCUMENTATION SHALL DESCRIBE HOW THE
  1357.              TCB IS STRUCTURED TO FACILITATE TESTING AND TO ENFORCE LEAST
  1358.              PRIVILEGE.  THIS DOCUMENTATION SHALL ALSO PRESENT THE RESULTS
  1359.              OF THE COVERT CHANNEL ANALYSIS AND THE TRADEOFFS INVOLVED IN
  1360.              RESTRICTING THE CHANNELS.  ALL AUDITABLE EVENTS THAT MAY BE
  1361.              USED IN THE EXPLOITATION OF KNOWN COVERT STORAGE CHANNELS SHALL
  1362.              BE IDENTIFIED.  THE BANDWIDTHS OF KNOWN COVERT STORAGE CHANNELS,
  1363.              THE USE OF WHICH IS NOT DETECTABLE BY THE AUDITING MECHANISMS,
  1364.              SHALL BE PROVIDED.  (SEE THE COVERT CHANNEL GUIDELINE SECTION.)
  1365.  
  1366.  
  1367. 3.3  CLASS (B3):    SECURITY DOMAINS
  1368.  
  1369. The class (B3) TCB must satisfy the reference monitor requirements that it
  1370. mediate all accesses of subjects to objects, be tamperproof, and be small
  1371. enough to be subjected to analysis and tests.  To this end, the TCB is
  1372. structured to exclude code not essential to security policy enforcement, with
  1373. significant system engineering during TCB design and implementation directed
  1374. toward minimizing its complexity.  A security administrator is supported,
  1375. audit mechanisms are expanded to signal security- relevant events, and system
  1376. recovery procedures are required.  The system is highly resistant to
  1377. penetration.  The following are minimal requirements for systems assigned a
  1378. class (B3) rating:
  1379.  
  1380. 3.3.1  SECURITY POLICY
  1381.  
  1382.      3.3.1.1   Discretionary Access Control
  1383.  
  1384.                The TCB shall define and control access between named users and
  1385.              named objects (e.g., files and programs) in the ADP system.
  1386.              The enforcement mechanism (E.G., ACCESS CONTROL LISTS) shall
  1387.              allow users to specify and control sharing of those OBJECTS.
  1388.              The discretionary access control mechanism shall, either by
  1389.              explicit user action or by default, provide that objects are
  1390.              protected from unauthorized access.  These access controls shall
  1391.              be capable of SPECIFYING, FOR EACH NAMED OBJECT, A LIST OF NAMED
  1392.              INDIVIDUALS AND A LIST OF GROUPS OF NAMED INDIVIDUALS WITH THEIR
  1393.              RESPECTIVE MODES OF ACCESS TO THAT OBJECT.  FURTHERMORE, FOR
  1394.              EACH SUCH NAMED OBJECT, IT SHALL BE POSSIBLE TO SPECIFY A LIST
  1395.              OF NAMED INDIVIDUALS AND A LIST OF GROUPS OF NAMED INDIVIDUALS
  1396.              FOR WHICH NO ACCESS TO THE OBJECT IS TO BE GIVEN.  Access
  1397.              permission to an object by users not already possessing access
  1398.              permission shall only be assigned by authorized users.
  1399.  
  1400.      3.3.1.2   Object Reuse
  1401.  
  1402.                When a storage object is initially assigned, allocated, or
  1403.              reallocated to a subject from the TCB's pool of unused storage
  1404.              objects, the TCB shall assure that the object contains no data
  1405.              for which the subject is not authorized.
  1406.  
  1407.      3.3.1.3   Labels
  1408.  
  1409.                Sensitivity labels associated with each ADP system resource
  1410.              (e.g., subject, storage object) that is directly or indirectly
  1411.              accessible by subjects external to the TCB shall be maintained
  1412.              by the TCB.  These labels shall be used as the basis for
  1413.              mandatory access control decisions.  In order to import non-
  1414.              labeled data, the TCB shall request and receive from an
  1415.              authorized user the security level of the data, and all such
  1416.              actions shall be auditable by the TCB.
  1417.  
  1418.         3.3.1.3.1  Label Integrity
  1419.  
  1420.                  Sensitivity labels shall accurately represent security
  1421.                  levels of the specific subjects or objects with which
  1422.                  they are associated.  When exported by the TCB,
  1423.                  sensitivity labels shall accurately and unambiguously
  1424.                  represent the internal labels and shall be associated
  1425.                  with the information being exported.
  1426.  
  1427.         3.3.1.3.2  Exportation of Labeled Information
  1428.  
  1429.                  The TCB shall designate each communication channel and
  1430.                  I/O device as either single-level or multilevel.  Any
  1431.                  change in this designation shall be done manually and
  1432.                  shall be auditable by the TCB.  The TCB shall maintain
  1433.                  and be able to audit any change in the current security
  1434.                  level associated with a single-level communication
  1435.                  channel or I/O device.
  1436.  
  1437.              3.3.1.3.2.1  Exportation to Multilevel Devices
  1438.  
  1439.                         When the TCB exports an object to a multilevel I/O
  1440.                         device, the sensitivity label associated with that
  1441.                         object shall also be exported and shall reside on
  1442.                         the same physical medium as the exported 
  1443.                         information and shall be in the same form (i.e., 
  1444.                         machine-readable or human-readable form).  When
  1445.                         the TCB exports or imports an object over a
  1446.                         multilevel communication channel, the protocol 
  1447.                         used on that channel shall provide for the
  1448.                         unambiguous pairing between the sensitivity labels
  1449.                         and the associated information that is sent or
  1450.                         received.
  1451.  
  1452.              3.3.1.3.2.2  Exportation to Single-Level Devices
  1453.  
  1454.                         Single-level I/O devices and single-level
  1455.                         communication channels are not required to 
  1456.                         maintain the sensitivity labels of the information
  1457.                         they process.  However, the TCB shall include a 
  1458.                         mechanism by which the TCB and an authorized user
  1459.                         reliably communicate to designate the single
  1460.                         security level of information imported or exported
  1461.                         via single-level communication channels or I/O
  1462.                         devices.
  1463.  
  1464.              3.3.1.3.2.3  Labeling Human-Readable Output
  1465.  
  1466.                         The ADP system administrator shall be able to
  1467.                         specify the printable label names associated with
  1468.                         exported sensitivity labels.  The TCB shall mark
  1469.                         the beginning and end of all human-readable, paged,
  1470.                         hardcopy output (e.g., line printer output) with
  1471.                         human-readable sensitivity labels that properly*
  1472.                         represent the sensitivity of the output.  The TCB
  1473.                         shall, by default, mark the top and bottom of each
  1474.                         page of human-readable, paged, hardcopy output
  1475.                         (e.g., line printer output) with human-readable
  1476.                         sensitivity labels that properly* represent the
  1477.                         overall sensitivity of the output or that
  1478.                         properly* represent the sensitivity of the 
  1479.                         information on the page.  The TCB shall, by
  1480.                         default and in an appropriate manner, mark other
  1481.                         forms of human-readable output (e.g., maps,
  1482.                         graphics) with human-readable sensitivity labels
  1483.                         that properly* represent the sensitivity of the 
  1484.                         output.  Any override of these marking defaults
  1485.                         shall be auditable by the TCB.
  1486.  
  1487.            _____________________________________________________________
  1488.            * The hierarchical classification component in human-readable
  1489.            sensitivity labels shall be equal to the greatest
  1490.            hierarchical classification of any of the information in the
  1491.            output that the labels refer to;  the non-hierarchical
  1492.            category component shall include all of the non-hierarchical
  1493.            categories of the information in the output the labels refer
  1494.            to, but no other non-hierarchical categories.
  1495.          _____________________________________________________________
  1496.  
  1497.  
  1498.         3.3.1.3.3  Subject Sensitivity Labels
  1499.  
  1500.                  The TCB shall immediately notify a terminal user of each
  1501.                  change in the security level associated with that user
  1502.                  during an interactive session.  A terminal user shall be
  1503.                  able to query the TCB as desired for a display of the
  1504.                  subject's complete sensitivity label.
  1505.  
  1506.         3.3.1.3.4  Device Labels
  1507.  
  1508.                  The TCB shall support the assignment of minimum and
  1509.                  maximum security levels to all attached physical devices.
  1510.                  These security levels shall be used by the TCB to enforce
  1511.                  constraints imposed by the physical environments in which
  1512.                  the devices are located.
  1513.  
  1514.      3.3.1.4   Mandatory Access Control
  1515.  
  1516.                The TCB shall enforce a mandatory access control policy over
  1517.              all resources (i.e., subjects, storage objects, and I/O 
  1518.              devices) that are directly or indirectly accessible by subjects
  1519.              external to the TCB.  These subjects and objects shall be
  1520.              assigned sensitivity labels that are a combination of
  1521.              hierarchical classification levels and non-hierarchical
  1522.              categories, and the labels shall be used as the basis for 
  1523.              mandatory access control decisions.  The TCB shall be able to
  1524.              support two or more such security levels.  (See the Mandatory
  1525.              Access Control guidelines.) The following requirements shall
  1526.              hold for all accesses between all subjects external to the TCB
  1527.              and all objects directly or indirectly accessible by these 
  1528.              subjects: A subject can read an object only if the hierarchical
  1529.              classification in the subject's security level is greater than
  1530.              or equal to the hierarchical classification in the object's
  1531.              security level and the non-hierarchical categories in the
  1532.              subject's security level include all the non-hierarchical
  1533.              categories in the object's security level.  A subject can write
  1534.              an object only if the hierarchical classification in the 
  1535.              subject's security level is less than or equal to the
  1536.              hierarchical classification in the object's security level and
  1537.              all the non-hierarchical categories in the subject's security 
  1538.              level are included in the non- hierarchical categories in the 
  1539.              object's security level.
  1540.  
  1541. 3.3.2  ACCOUNTABILITY
  1542.  
  1543.      3.3.2.1   Identification and Authentication
  1544.  
  1545.                The TCB shall require users to identify themselves to it before
  1546.              beginning to perform any other actions that the TCB is expected
  1547.              to mediate.  Furthermore, the TCB shall maintain authentication
  1548.              data that includes information for verifying the identity of
  1549.              individual users (e.g., passwords) as well as information for
  1550.              determining the clearance and authorizations of individual
  1551.              users.  This data shall be used by the TCB to authenticate the
  1552.              user's identity and to determine the security level and 
  1553.              authorizations of subjects that may be created to act on behalf
  1554.              of the individual user.  The TCB shall protect authentication
  1555.              data so that it cannot be accessed by any unauthorized user.
  1556.              The TCB shall be able to enforce individual accountability by
  1557.              providing the capability to uniquely identify each individual 
  1558.              ADP system user.  The TCB shall also provide the capability of
  1559.              associating this identity with all auditable actions taken by
  1560.              that individual.
  1561.  
  1562.         3.3.2.1.1  Trusted Path
  1563.  
  1564.                  The TCB shall support a trusted communication path
  1565.                  between itself and USERS for USE WHEN A POSITIVE TCB-TO-
  1566.                  USER CONNECTION IS REQUIRED (E.G., LOGIN, CHANGE SUBJECT
  1567.                  SECURITY LEVEL).  Communications via this TRUSTED path
  1568.                  shall be ACTIVATED exclusively by a user OR THE TCB AND
  1569.                  SHALL BE LOGICALLY ISOLATED AND UNMISTAKABLY 
  1570.                  DISTINGUISHABLE FROM OTHER PATHS.
  1571.  
  1572.      3.3.2.2   Audit
  1573.  
  1574.                The TCB shall be able to create, maintain, and protect from
  1575.              modification or unauthorized access or destruction an audit 
  1576.              trail of accesses to the objects it protects.  The audit data
  1577.              shall be protected by the TCB so that read access to it is
  1578.              limited to those who are authorized for audit data.  The TCB
  1579.              shall be able to record the following types of events: use of
  1580.              identification and authentication mechanisms, introduction of
  1581.              objects into a user's address space (e.g., file open, program
  1582.              initiation), deletion of objects, and actions taken by computer
  1583.              operators and system administrators and/or system security
  1584.              officers.  The TCB shall also be able to audit any override of
  1585.              human-readable output markings.  For each recorded event, the
  1586.              audit record shall identify: date and time of the event, user,
  1587.              type of event, and success or failure of the event.  For 
  1588.              identification/authentication events the origin of request
  1589.              (e.g., terminal ID) shall be included in the audit record.
  1590.              For events that introduce an object into a user's address 
  1591.              space and for object deletion events the audit record shall 
  1592.              include the name of the object and the object's security level.
  1593.              The ADP system administrator shall be able to selectively audit
  1594.              the actions of any one or more users based on individual
  1595.              identity and/or object security level.  The TCB shall be able to
  1596.              audit the identified events that may be used in the exploitation
  1597.              of covert storage channels.  THE TCB SHALL CONTAIN A MECHANISM
  1598.              THAT IS ABLE TO MONITOR THE OCCURRENCE OR ACCUMULATION OF
  1599.              SECURITY AUDITABLE EVENTS THAT MAY INDICATE AN IMMINENT
  1600.              VIOLATION OF SECURITY POLICY.  THIS MECHANISM SHALL BE ABLE TO
  1601.              IMMEDIATELY NOTIFY THE SECURITY ADMINISTRATOR WHEN THRESHOLDS
  1602.              ARE EXCEEDED.
  1603.  
  1604. 3.3.3  ASSURANCE
  1605.  
  1606.      3.3.3.1   Operational Assurance
  1607.  
  1608.         3.3.3.1.1  System Architecture
  1609.  
  1610.                  The TCB shall maintain a domain for its own execution
  1611.                  that protects it from external interference or tampering
  1612.                  (e.g., by modification of its code or data structures).
  1613.                  The TCB shall maintain process isolation through the
  1614.                  provision of distinct address spaces under its control.
  1615.                  The TCB shall be internally structured into well-defined
  1616.                  largely independent modules.  It shall make effective use
  1617.                  of available hardware to separate those elements that are
  1618.                  protection-critical from those that are not.  The TCB
  1619.                  modules shall be designed such that the principle of 
  1620.                  least privilege is enforced.  Features in hardware, such
  1621.                  as segmentation, shall be used to support logically
  1622.                  distinct storage objects with separate attributes (namely:
  1623.                  readable, writeable).  The user interface to the TCB shall
  1624.                  be completely defined and all elements of the TCB
  1625.                  identified.  THE TCB SHALL BE DESIGNED AND STRUCTURED TO
  1626.                  USE A COMPLETE, CONCEPTUALLY SIMPLE PROTECTION MECHANISM
  1627.                  WITH PRECISELY DEFINED SEMANTICS.  THIS MECHANISM SHALL
  1628.                  PLAY A CENTRAL ROLE IN ENFORCING THE INTERNAL STRUCTURING
  1629.                  OF THE TCB AND THE SYSTEM.  THE TCB SHALL INCORPORATE
  1630.                  SIGNIFICANT USE OF LAYERING, ABSTRACTION AND DATA HIDING.
  1631.                  SIGNIFICANT SYSTEM ENGINEERING SHALL BE DIRECTED TOWARD
  1632.                  MINIMIZING THE COMPLEXITY OF THE TCB AND EXCLUDING FROM
  1633.                  THE TCB MODULES THAT ARE NOT PROTECTION-CRITICAL.
  1634.  
  1635.         3.3.3.1.2  System Integrity
  1636.  
  1637.                  Hardware and/or software features shall be provided that
  1638.                  can be used to periodically validate the correct 
  1639.                  operation of the on-site hardware and firmware elements 
  1640.                  of the TCB.
  1641.  
  1642.         3.3.3.1.3  Covert Channel Analysis
  1643.  
  1644.                  The system developer shall conduct a thorough search for
  1645.                  COVERT CHANNELS and make a determination (either by 
  1646.                  actual measurement or by engineering estimation) of the
  1647.                  maximum bandwidth of each identified channel.  (See the
  1648.                  Covert Channels Guideline section.)
  1649.  
  1650.         3.3.3.1.4  Trusted Facility Management
  1651.  
  1652.                  The TCB shall support separate operator and administrator
  1653.                  functions.  THE FUNCTIONS PERFORMED IN THE ROLE OF A 
  1654.                  SECURITY ADMINISTRATOR SHALL BE IDENTIFIED.  THE ADP
  1655.                  SYSTEM ADMINISTRATIVE PERSONNEL SHALL ONLY BE ABLE TO
  1656.                  PERFORM SECURITY ADMINISTRATOR FUNCTIONS AFTER TAKING A 
  1657.                  DISTINCT AUDITABLE ACTION TO ASSUME THE SECURITY
  1658.                  ADMINISTRATOR ROLE ON THE ADP SYSTEM.  NON-SECURITY
  1659.                  FUNCTIONS THAT CAN BE PERFORMED IN THE SECURITY 
  1660.                  ADMINISTRATION ROLE SHALL BE LIMITED STRICTLY TO THOSE
  1661.                  ESSENTIAL TO PERFORMING THE SECURITY ROLE EFFECTIVELY.
  1662.  
  1663.         3.3.3.1.5  Trusted Recovery
  1664.  
  1665.                  PROCEDURES AND/OR MECHANISMS SHALL BE PROVIDED TO ASSURE
  1666.                  THAT, AFTER AN ADP SYSTEM FAILURE OR OTHER DISCONTINUITY,
  1667.                  RECOVERY WITHOUT A PROTECTION COMPROMISE IS OBTAINED.
  1668.  
  1669.      3.3.3.2   Life-Cycle Assurance
  1670.  
  1671.         3.3.3.2.1  Security Testing
  1672.  
  1673.                  The security mechanisms of the ADP system shall be tested
  1674.                  and found to work as claimed in the system documentation.
  1675.                  A team of individuals who thoroughly understand the
  1676.                  specific implementation of the TCB shall subject its
  1677.                  design documentation, source code, and object code to
  1678.                  thorough analysis and testing.  Their objectives shall 
  1679.                  be: to uncover all design and implementation flaws that
  1680.                  would permit a subject external to the TCB to read,
  1681.                  change, or delete data normally denied under the 
  1682.                  mandatory or discretionary security policy enforced by
  1683.                  the TCB; as well as to assure that no subject (without
  1684.                  authorization to do so) is able to cause the TCB to enter
  1685.                  a state such that it is unable to respond to 
  1686.                  communications initiated by other users.  The TCB shall
  1687.                  be FOUND RESISTANT TO penetration.  All discovered flaws
  1688.                  shall be corrected and the TCB retested to demonstrate 
  1689.                  that they have been eliminated and that new flaws have
  1690.                  not been introduced.  Testing shall demonstrate that the
  1691.                  TCB implementation is consistent with the descriptive
  1692.                  top-level specification.  (See the Security Testing 
  1693.                  Guidelines.)  NO DESIGN FLAWS AND NO MORE THAN A FEW
  1694.                  CORRECTABLE IMPLEMENTATION FLAWS MAY BE FOUND DURING
  1695.                  TESTING AND THERE SHALL BE REASONABLE CONFIDENCE THAT 
  1696.                  FEW REMAIN.
  1697.  
  1698.         3.3.3.2.2  Design Specification and Verification
  1699.  
  1700.                  A formal model of the security policy supported by the
  1701.                  TCB shall be maintained that is proven consistent with 
  1702.                  its axioms.  A descriptive top-level specification (DTLS)
  1703.                  of the TCB shall be maintained that completely and
  1704.                  accurately describes the TCB in terms of exceptions, error
  1705.                  messages, and effects.  It shall be shown to be an 
  1706.                  accurate description of the TCB interface.  A CONVINCING
  1707.                  ARGUMENT SHALL BE GIVEN THAT THE DTLS IS CONSISTENT WITH
  1708.                  THE MODEL.
  1709.  
  1710.         3.3.3.2.3  Configuration Management
  1711.  
  1712.                  During development and maintenance of the TCB, a
  1713.                  configuration management system shall be in place that 
  1714.                  maintains control of changes to the descriptive top-level
  1715.                  specification, other design data, implementation
  1716.                  documentation, source code, the running version of the
  1717.                  object code, and test fixtures and documentation.  The
  1718.                  configuration management system shall assure a consistent
  1719.                  mapping among all documentation and code associated with
  1720.                  the current version of the TCB.  Tools shall be provided
  1721.                  for generation of a new version of the TCB from source 
  1722.                  code.  Also available shall be tools for comparing a
  1723.                  newly generated version with the previous TCB version in
  1724.                  order to ascertain that only the intended changes have 
  1725.                  been made in the code that will actually be used as the
  1726.                  new version of the TCB.
  1727.  
  1728. 3.3.4  DOCUMENTATION
  1729.  
  1730.      3.3.4.1   Security Features User's Guide
  1731.  
  1732.              A single summary, chapter, or manual in user documentation
  1733.              shall describe the protection mechanisms provided by the TCB,
  1734.              guidelines on their use, and how they interact with one another.
  1735.  
  1736.      3.3.4.2   Trusted Facility Manual
  1737.  
  1738.                A manual addressed to the ADP system administrator shall
  1739.              present cautions about functions and privileges that should be
  1740.              controlled when running a secure facility.  The procedures for
  1741.              examining and maintaining the audit files as well as the
  1742.              detailed audit record structure for each type of audit event
  1743.              shall be given.  The manual shall describe the operator and
  1744.              administrator functions related to security, to include 
  1745.              changing the security characteristics of a user.  It shall
  1746.              provide guidelines on the consistent and effective use of the
  1747.              protection features of the system, how they interact, how to
  1748.              securely generate a new TCB, and facility procedures, warnings,
  1749.              and privileges that need to be controlled in order to operate
  1750.              the facility in a secure manner.  The TCB modules that contain
  1751.              the reference validation mechanism shall be identified.  The
  1752.              procedures for secure generation of a new TCB from source after
  1753.              modification of any modules in the TCB shall be described.  IT
  1754.              SHALL INCLUDE THE PROCEDURES TO ENSURE THAT THE SYSTEM IS
  1755.              INITIALLY STARTED IN A SECURE MANNER.  PROCEDURES SHALL ALSO BE
  1756.              INCLUDED TO RESUME SECURE SYSTEM OPERATION AFTER ANY LAPSE IN 
  1757.              SYSTEM OPERATION.
  1758.  
  1759.      3.3.4.3   Test Documentation
  1760.  
  1761.                The system developer shall provide to the evaluators a document
  1762.              that describes the test plan and results of the security 
  1763.              mechanisms' functional testing.  It shall include results of
  1764.              testing the effectiveness of the methods used to reduce covert
  1765.              channel bandwidths.
  1766.  
  1767.      3.3.4.4   Design Documentation
  1768.  
  1769.                Documentation shall be available that provides a description of
  1770.              the manufacturer's philosophy of protection and an explanation
  1771.              of how this philosophy is translated into the TCB.  The
  1772.              interfaces between the TCB modules shall be described.  A
  1773.              formal description of the security policy model enforced by the
  1774.              TCB shall be available and proven that it is sufficient to
  1775.              enforce the security policy.  The specific TCB protection 
  1776.              mechanisms shall be identified and an explanation given to show
  1777.              that they satisfy the model.  The descriptive top-level
  1778.              specification (DTLS) shall be shown to be an accurate 
  1779.              description of the TCB interface.  Documentation shall describe
  1780.              how the TCB implements the reference monitor concept and give 
  1781.              an explanation why it is tamperproof, cannot be bypassed, and
  1782.              is correctly implemented.  THE TCB IMPLEMENTATION (I.E., IN
  1783.              HARDWARE, FIRMWARE, AND SOFTWARE) SHALL BE INFORMALLY SHOWN TO
  1784.              BE CONSISTENT WITH THE DTLS.  THE ELEMENTS OF THE DTLS SHALL BE
  1785.              SHOWN, USING INFORMAL TECHNIQUES, TO CORRESPOND TO THE ELEMENTS
  1786.              OF THE TCB.  Documentation shall describe how the TCB is
  1787.              structured to facilitate testing and to enforce least privilege.
  1788.              This documentation shall also present the results of the covert
  1789.              channel analysis and the tradeoffs involved in restricting the
  1790.              channels.  All auditable events that may be used in the 
  1791.              exploitation of known covert storage channels shall be 
  1792.              identified.  The bandwidths of known covert storage channels,
  1793.              the use of which is not detectable by the auditing mechanisms,
  1794.              shall be provided.  (See the Covert Channel Guideline section.)
  1795.  
  1796.  
  1797. 4.0  DIVISION A:    VERIFIED PROTECTION
  1798.  
  1799. This division is characterized by the use of formal security verification
  1800. methods to assure that the mandatory and discretionary security controls
  1801. employed in the system can effectively protect classified or other sensitive
  1802. information stored or processed by the system.  Extensive documentation is
  1803. required to demonstrate that the TCB meets the security requirements in all
  1804. aspects of design, development and implementation.
  1805.  
  1806.  
  1807. 4.1  CLASS (A1):    VERIFIED DESIGN
  1808.  
  1809. Systems in class (A1) are functionally equivalent to those in class (B3) in
  1810. that no additional architectural features or policy requirements are added.
  1811. The distinguishing feature of systems in this class is the analysis derived
  1812. from formal design specification and verification techniques and the resulting
  1813. high degree of assurance that the TCB is correctly implemented.  This
  1814. assurance is developmental in nature, starting with a formal model of the
  1815. security policy and a formal top-level specification (FTLS) of the design.
  1816. Independent of the particular specification language or verification system
  1817. used, there are five important criteria for class (A1) design verification:
  1818.  
  1819.         * A formal model of the security policy must be clearly
  1820.         identified and documented, including a mathematical proof
  1821.         that the model is consistent with its axioms and is
  1822.         sufficient to support the security policy.
  1823.  
  1824.         * An FTLS must be produced that includes abstract definitions
  1825.         of the functions the TCB performs and of the hardware and/or
  1826.         firmware mechanisms that are used to support separate
  1827.         execution domains.
  1828.  
  1829.         * The FTLS of the TCB must be shown to be consistent with the
  1830.         model by formal techniques where possible (i.e., where
  1831.         verification tools exist) and informal ones otherwise.
  1832.  
  1833.         * The TCB implementation (i.e., in hardware, firmware, and
  1834.         software) must be informally shown to be consistent with the
  1835.         FTLS.  The elements of the FTLS must be shown, using
  1836.         informal techniques, to correspond to the elements of the
  1837.         TCB.  The FTLS must express the unified protection mechanism
  1838.         required to satisfy the security policy, and it is the
  1839.         elements of this protection mechanism that are mapped to the
  1840.         elements of the TCB.
  1841.  
  1842.         * Formal analysis techniques must be used to identify and
  1843.         analyze covert channels.  Informal techniques may be used to
  1844.         identify covert timing channels.  The continued existence of
  1845.         identified covert channels in the system must be justified.
  1846.  
  1847. In keeping with the extensive design and development analysis of the TCB
  1848. required of systems in class (A1), more stringent configuration management is
  1849. required and procedures are established for securely distributing the system
  1850. to sites.  A system security administrator is supported.
  1851.  
  1852. The following are minimal requirements for systems assigned a class (A1)
  1853. rating:
  1854.  
  1855. 4.1.1  SECURITY POLICY
  1856.  
  1857.      4.1.1.1   Discretionary Access Control
  1858.  
  1859.              The TCB shall define and control access between named users and
  1860.              named objects (e.g., files and programs) in the ADP system.  
  1861.              The enforcement mechanism (e.g., access control lists) shall 
  1862.              allow users to specify and control sharing of those objects.
  1863.              The discretionary access control mechanism shall, either by
  1864.              explicit user action or by default, provide that objects are
  1865.              protected from unauthorized access.  These access controls 
  1866.              shall be capable of specifying, for each named object, a list 
  1867.              of named individuals and a list of groups of named individuals
  1868.              with their respective modes of access to that object.
  1869.              Furthermore, for each such named object, it shall be possible to
  1870.              specify a list of named individuals and a list of groups of 
  1871.              named individuals for which no access to the object is to be 
  1872.              given.  Access permission to an object by users not already
  1873.              possessing access permission shall only be assigned by
  1874.              authorized users.
  1875.  
  1876.      4.1.1.2   Object Reuse
  1877.  
  1878.              When a storage object is initially assigned, allocated, or
  1879.              reallocated to a subject from the TCB's pool of unused storage
  1880.              objects, the TCB shall assure that the object contains no data
  1881.              for which the subject is not authorized.
  1882.  
  1883.      4.1.1.3   Labels
  1884.  
  1885.              Sensitivity labels associated with each ADP system resource
  1886.              (e.g., subject, storage object) that is directly or indirectly
  1887.              accessible by subjects external to the TCB shall be maintained
  1888.              by the TCB.  These labels shall be used as the basis for
  1889.              mandatory access control decisions.  In order to import non-
  1890.              labeled data, the TCB shall request and receive from an 
  1891.              authorized user the security level of the data, and all such
  1892.              actions shall be auditable by the TCB.
  1893.  
  1894.         4.1.1.3.1  Label Integrity
  1895.  
  1896.                  Sensitivity labels shall accurately represent security
  1897.                  levels of the specific subjects or objects with which 
  1898.                  they are associated.  When exported by the TCB,
  1899.                  sensitivity labels shall accurately and unambiguously
  1900.                  represent the internal labels and shall be associated 
  1901.                  with the information being exported.
  1902.  
  1903.         4.1.1.3.2  Exportation of Labeled Information
  1904.  
  1905.                  The TCB shall designate each communication channel and
  1906.                  I/O device as either single-level or multilevel.  Any 
  1907.                  change in this designation shall be done manually and
  1908.                  shall be auditable by the TCB.  The TCB shall maintain
  1909.                  and be able to audit any change in the current security
  1910.                  level associated with a single-level communication
  1911.                  channel or I/O device.
  1912.  
  1913.              4.1.1.3.2.1  Exportation to Multilevel Devices
  1914.  
  1915.                         When the TCB exports an object to a multilevel I/O
  1916.                         device, the sensitivity label associated with that
  1917.                         object shall also be exported and shall reside on
  1918.                         the same physical medium as the exported 
  1919.                         information and shall be in the same form (i.e., 
  1920.                         machine-readable or human-readable form).  When
  1921.                         the TCB exports or imports an object over a
  1922.                         multilevel communication channel, the protocol 
  1923.                         used on that channel shall provide for the
  1924.                         unambiguous pairing between the sensitivity labels
  1925.                         and the associated information that is sent or 
  1926.                         received.
  1927.  
  1928.              4.1.1.3.2.2  Exportation to Single-Level Devices
  1929.  
  1930.                         Single-level I/O devices and single-level
  1931.                         communication channels are not required to 
  1932.                         maintain the sensitivity labels of the information
  1933.                         they process.  However, the TCB shall include a 
  1934.                         mechanism by which the TCB and an authorized user
  1935.                         reliably communicate to designate the single
  1936.                         security level of information imported or exported
  1937.                         via single-level communication channels or I/O 
  1938.                         devices.
  1939.  
  1940.              4.1.1.3.2.3  Labeling Human-Readable Output
  1941.  
  1942.                         The ADP system administrator shall be able to
  1943.                         specify the printable label names associated with
  1944.                         exported sensitivity labels.  The TCB shall mark
  1945.                         the beginning and end of all human-readable, paged,
  1946.                         hardcopy output (e.g., line printer output) with 
  1947.                         human-readable sensitivity labels that properly*
  1948.                         represent the sensitivity of the output.  The TCB
  1949.                         shall, by default, mark the top and bottom of each
  1950.                         page of human-readable, paged, hardcopy output
  1951.                         (e.g., line printer output) with human-readable 
  1952.                         sensitivity labels that properly* represent the
  1953.                         overall sensitivity of the output or that 
  1954.                         properly* represent the sensitivity of the 
  1955.                         information on the page.  The TCB shall, by
  1956.                         default and in an appropriate manner, mark other
  1957.                         forms of human-readable output (e.g., maps,
  1958.                         graphics) with human-readable sensitivity labels
  1959.                         that properly* represent the sensitivity of the 
  1960.                         output.  Any override of these marking defaults
  1961.                         shall be auditable by the TCB.
  1962.  
  1963.            ____________________________________________________________________
  1964.            * The hierarchical classification component in human-readable
  1965.            sensitivity labels shall be equal to the greatest
  1966.            hierarchical classification of any of the information in the
  1967.            output that the labels refer to;  the non-hierarchical
  1968.            category component shall include all of the non-hierarchical
  1969.            categories of the information in the output the labels refer
  1970.            to, but no other non-hierarchical categories.
  1971.            ____________________________________________________________________
  1972.  
  1973.  
  1974.         4.1.1.3.3  Subject Sensitivity Labels
  1975.  
  1976.                  The TCB shall immediately notify a terminal user of each
  1977.                  change in the security level associated with that user 
  1978.                  during an interactive session.  A terminal user shall be
  1979.                  able to query the TCB as desired for a display of the
  1980.                  subject's complete sensitivity label.
  1981.  
  1982.         4.1.1.3.4  Device Labels
  1983.  
  1984.                  The TCB shall support the assignment of minimum and
  1985.                  maximum security levels to all attached physical devices.
  1986.                  These security levels shall be used by the TCB to enforce
  1987.                  constraints imposed by the physical environments in which
  1988.                  the devices are located.
  1989.  
  1990.      4.1.1.4   Mandatory Access Control
  1991.  
  1992.              The TCB shall enforce a mandatory access control policy over
  1993.              all resources (i.e., subjects, storage objects, and I/O 
  1994.              devices) that are directly or indirectly accessible by subjects
  1995.              external to the TCB.  These subjects and objects shall be
  1996.              assigned sensitivity labels that are a combination of
  1997.              hierarchical classification levels and non-hierarchical
  1998.              categories, and the labels shall be used as the basis for 
  1999.              mandatory access control decisions.  The TCB shall be able to
  2000.              support two or more such security levels.  (See the Mandatory
  2001.              Access Control guidelines.) The following requirements shall
  2002.              hold for all accesses between all subjects external to the TCB
  2003.              and all objects directly or indirectly accessible by these 
  2004.              subjects: A subject can read an object only if the hierarchical
  2005.              classification in the subject's security level is greater than
  2006.              or equal to the hierarchical classification in the object's
  2007.              security level and the non-hierarchical categories in the
  2008.              subject's security level include all the non-hierarchical
  2009.              categories in the object's security level.  A subject can write
  2010.              an object only if the hierarchical classification in the 
  2011.              subject's security level is less than or equal to the
  2012.              hierarchical classification in the object's security level and
  2013.              all the non-hierarchical categories in the subject's security 
  2014.              level are included in the non- hierarchical categories in the 
  2015.              object's security level.
  2016.  
  2017. 4.1.2  ACCOUNTABILITY
  2018.  
  2019.      4.1.2.1   Identification and Authentication
  2020.  
  2021.              The TCB shall require users to identify themselves to it before
  2022.              beginning to perform any other actions that the TCB is expected
  2023.              to mediate.  Furthermore, the TCB shall maintain authentication
  2024.              data that includes information for verifying the identity of
  2025.              individual users (e.g., passwords) as well as information for
  2026.              determining the clearance and authorizations of individual
  2027.              users.  This data shall be used by the TCB to authenticate the
  2028.              user's identity and to determine the security level and 
  2029.              authorizations of subjects that may be created to act on behalf
  2030.              of the individual user.  The TCB shall protect authentication
  2031.              data so that it cannot be accessed by any unauthorized user.
  2032.              The TCB shall be able to enforce individual accountability by
  2033.              providing the capability to uniquely identify each individual 
  2034.              ADP system user.  The TCB shall also provide the capability of
  2035.              associating this identity with all auditable actions taken by
  2036.              that individual.
  2037.  
  2038.         4.1.2.1.1  Trusted Path
  2039.  
  2040.                  The TCB shall support a trusted communication path
  2041.                  between itself and users for use when a positive TCB-to-
  2042.                  user connection is required (e.g., login, change subject
  2043.                  security level).  Communications via this trusted path
  2044.                  shall be activated exclusively by a user or the TCB and
  2045.                  shall be logically isolated and unmistakably 
  2046.                  distinguishable from other paths.
  2047.  
  2048.      4.1.2.2   Audit
  2049.  
  2050.              The TCB shall be able to create, maintain, and protect from
  2051.              modification or unauthorized access or destruction an audit 
  2052.              trail of accesses to the objects it protects.  The audit data
  2053.              shall be protected by the TCB so that read access to it is
  2054.              limited to those who are authorized for audit data.  The TCB
  2055.              shall be able to record the following types of events: use of
  2056.              identification and authentication mechanisms, introduction of
  2057.              objects into a user's address space (e.g., file open, program
  2058.              initiation), deletion of objects, and actions taken by computer
  2059.              operators and system administrators and/or system security
  2060.              officers.  The TCB shall also be able to audit any override of
  2061.              human-readable output markings.  For each recorded event, the
  2062.              audit record shall identify: date and time of the event, user,
  2063.              type of event, and success or failure of the event.  For
  2064.              identification/authentication events the origin of request
  2065.              (e.g., terminal ID) shall be included in the audit record.  For
  2066.              events that introduce an object into a user's address space and
  2067.              for object deletion events the audit record shall include the 
  2068.              name of the object and the object's security level.  The ADP
  2069.              system administrator shall be able to selectively audit the
  2070.              actions of any one or more users based on individual identity
  2071.              and/or object security level.  The TCB shall be able to audit
  2072.              the identified events that may be used in the exploitation of
  2073.              covert storage channels.  The TCB shall contain a mechanism 
  2074.              that is able to monitor the occurrence or accumulation of 
  2075.              security auditable events that may indicate an imminent
  2076.              violation of security policy.  This mechanism shall be able to
  2077.              immediately notify the security administrator when thresholds 
  2078.              are exceeded.
  2079.  
  2080. 4.1.3  ASSURANCE
  2081.  
  2082.      4.1.3.1   Operational Assurance
  2083.  
  2084.         4.1.3.1.1  System Architecture
  2085.  
  2086.                  The TCB shall maintain a domain for its own execution
  2087.                  that protects it from external interference or tampering
  2088.                  (e.g., by modification of its code or data structures).
  2089.                  The TCB shall maintain process isolation through the
  2090.                  provision of distinct address spaces under its control.
  2091.                  The TCB shall be internally structured into well-defined
  2092.                  largely independent modules.  It shall make effective use
  2093.                  of available hardware to separate those elements that are
  2094.                  protection-critical from those that are not.  The TCB
  2095.                  modules shall be designed such that the principle of 
  2096.                  least privilege is enforced.  Features in hardware, such
  2097.                  as segmentation, shall be used to support logically 
  2098.                  distinct storage objects with separate attributes (namely:
  2099.                  readable, writeable).  The user interface to the TCB 
  2100.                  shall be completely defined and all elements of the TCB 
  2101.                  identified.  The TCB shall be designed and structured to
  2102.                  use a complete, conceptually simple protection mechanism
  2103.                  with precisely defined semantics.  This mechanism shall 
  2104.                  play a central role in enforcing the internal structuring
  2105.                  of the TCB and the system.  The TCB shall incorporate
  2106.                  significant use of layering, abstraction and data hiding.
  2107.                  Significant system engineering shall be directed toward 
  2108.                  minimizing the complexity of the TCB and excluding from
  2109.                  the TCB modules that are not protection-critical.
  2110.  
  2111.         4.1.3.1.2  System Integrity
  2112.  
  2113.                  Hardware and/or software features shall be provided that
  2114.                  can be used to periodically validate the correct 
  2115.                  operation of the on-site hardware and firmware elements
  2116.                  of the TCB.
  2117.  
  2118.         4.1.3.1.3  Covert Channel Analysis
  2119.  
  2120.                  The system developer shall conduct a thorough search for
  2121.                  COVERT CHANNELS and make a determination (either by 
  2122.                  actual measurement or by engineering estimation) of the
  2123.                  maximum bandwidth of each identified channel.  (See the
  2124.                  Covert Channels Guideline section.)  FORMAL METHODS SHALL
  2125.                  BE USED IN THE ANALYSIS.
  2126.  
  2127.         4.1.3.1.4  Trusted Facility Management
  2128.  
  2129.                  The TCB shall support separate operator and administrator
  2130.                  functions.  The functions performed in the role of a 
  2131.                  security administrator shall be identified.  The ADP
  2132.                  system administrative personnel shall only be able to
  2133.                  perform security administrator functions after taking a 
  2134.                  distinct auditable action to assume the security
  2135.                  administrator role on the ADP system.  Non-security
  2136.                  functions that can be performed in the security 
  2137.                  administration role shall be limited strictly to those
  2138.                  essential to performing the security role effectively.
  2139.  
  2140.         4.1.3.1.5  Trusted Recovery
  2141.  
  2142.                  Procedures and/or mechanisms shall be provided to assure
  2143.                  that, after an ADP system failure or other discontinuity,
  2144.                  recovery without a protection compromise is obtained.
  2145.  
  2146.      4.1.3.2   Life-Cycle Assurance
  2147.  
  2148.         4.1.3.2.1  Security Testing
  2149.  
  2150.                  The security mechanisms of the ADP system shall be tested
  2151.                  and found to work as claimed in the system documentation.
  2152.                  A team of individuals who thoroughly understand the
  2153.                  specific implementation of the TCB shall subject its
  2154.                  design documentation, source code, and object code to
  2155.                  thorough analysis and testing.  Their objectives shall 
  2156.                  be: to uncover all design and implementation flaws that
  2157.                  would permit a subject external to the TCB to read,
  2158.                  change, or delete data normally denied under the 
  2159.                  mandatory or discretionary security policy enforced by 
  2160.                  the TCB; as well as to assure that no subject (without
  2161.                  authorization to do so) is able to cause the TCB to enter
  2162.                  a state such that it is unable to respond to 
  2163.                  communications initiated by other users.  The TCB shall 
  2164.                  be found resistant to penetration.  All discovered flaws
  2165.                  shall be corrected and the TCB retested to demonstrate 
  2166.                  that they have been eliminated and that new flaws have
  2167.                  not been introduced.  Testing shall demonstrate that the
  2168.                  TCB implementation is consistent with the FORMAL top-
  2169.                  level specification.  (See the Security Testing 
  2170.                  Guidelines.)  No design flaws and no more than a few
  2171.                  correctable implementation flaws may be found during
  2172.                  testing and there shall be reasonable confidence that few
  2173.                  remain.  MANUAL OR OTHER MAPPING OF THE FTLS TO THE 
  2174.                  SOURCE CODE MAY FORM A BASIS FOR PENETRATION TESTING.
  2175.  
  2176.         4.1.3.2.2  Design Specification and Verification
  2177.  
  2178.                  A formal model of the security policy supported by the
  2179.                  TCB shall be maintained that is proven consistent with 
  2180.                  its axioms.  A descriptive top-level specification (DTLS)
  2181.                  of the TCB shall be maintained that completely and
  2182.                  accurately describes the TCB in terms of exceptions, error
  2183.                  messages, and effects.  A FORMAL TOP-LEVEL SPECIFICATION
  2184.                  (FTLS) OF THE TCB SHALL BE MAINTAINED THAT ACCURATELY
  2185.                  DESCRIBES THE TCB IN TERMS OF EXCEPTIONS, ERROR MESSAGES,
  2186.                  AND EFFECTS.  THE DTLS AND FTLS SHALL INCLUDE THOSE 
  2187.                  COMPONENTS OF THE TCB THAT ARE IMPLEMENTED AS HARDWARE
  2188.                  AND/OR FIRMWARE IF THEIR PROPERTIES ARE VISIBLE AT THE
  2189.                  TCB INTERFACE.  THE FTLS shall be shown to be an accurate
  2190.                  description of the TCB interface.  A convincing argument
  2191.                  shall be given that the DTLS is consistent with the model
  2192.                  AND A COMBINATION OF FORMAL AND INFORMAL TECHNIQUES SHALL
  2193.                  BE USED TO SHOW THAT THE FTLS IS CONSISTENT WITH THE
  2194.                  MODEL.  THIS VERIFICATION EVIDENCE SHALL BE CONSISTENT 
  2195.                  WITH THAT PROVIDED WITHIN THE STATE-OF-THE-ART OF THE 
  2196.                  PARTICULAR COMPUTER SECURITY CENTER-ENDORSED FORMAL
  2197.                  SPECIFICATION AND VERIFICATION SYSTEM USED.  MANUAL OR
  2198.                  OTHER MAPPING OF THE FTLS TO THE TCB SOURCE CODE SHALL BE
  2199.                  PERFORMED TO PROVIDE EVIDENCE OF CORRECT IMPLEMENTATION.
  2200.  
  2201.         4.1.3.2.3  Configuration Management
  2202.  
  2203.                  During THE ENTIRE LIFE-CYCLE, I.E., DURING THE DESIGN,
  2204.                  DEVELOPMENT, and maintenance of the TCB, a configuration
  2205.                  management system shall be in place FOR ALL SECURITY-
  2206.                  RELEVANT HARDWARE, FIRMWARE, AND SOFTWARE that maintains
  2207.                  control of changes to THE FORMAL MODEL, the descriptive 
  2208.                  AND FORMAL top-level SPECIFICATIONS, other design data, 
  2209.                  implementation documentation, source code, the running
  2210.                  version of the object code, and test fixtures and
  2211.                  documentation.  The configuration management system shall
  2212.                  assure a consistent mapping among all documentation and 
  2213.                  code associated with the current version of the TCB.
  2214.                  Tools shall be provided for generation of a new version
  2215.                  of the TCB from source code.  Also available shall be 
  2216.                  tools, MAINTAINED UNDER STRICT CONFIGURATION CONTROL, for
  2217.                  comparing a newly generated version with the previous TCB
  2218.                  version in order to ascertain that only the intended
  2219.                  changes have been made in the code that will actually be
  2220.                  used as the new version of the TCB.  A COMBINATION OF
  2221.                  TECHNICAL, PHYSICAL, AND PROCEDURAL SAFEGUARDS SHALL BE
  2222.                  USED TO PROTECT FROM UNAUTHORIZED MODIFICATION OR
  2223.                  DESTRUCTION THE MASTER COPY OR COPIES OF ALL MATERIAL 
  2224.                  USED TO GENERATE THE TCB.
  2225.  
  2226.         4.1.3.2.4  Trusted Distribution
  2227.  
  2228.                  A TRUSTED ADP SYSTEM CONTROL AND DISTRIBUTION FACILITY
  2229.                  SHALL BE PROVIDED FOR MAINTAINING THE INTEGRITY OF THE 
  2230.                  MAPPING BETWEEN THE MASTER DATA DESCRIBING THE CURRENT
  2231.                  VERSION OF THE TCB AND THE ON-SITE MASTER COPY OF THE
  2232.                  CODE FOR THE CURRENT VERSION.  PROCEDURES (E.G., SITE 
  2233.                  SECURITY ACCEPTANCE TESTING) SHALL EXIST FOR ASSURING
  2234.                  THAT THE TCB SOFTWARE, FIRMWARE, AND HARDWARE UPDATES
  2235.                  DISTRIBUTED TO A CUSTOMER ARE EXACTLY AS SPECIFIED BY 
  2236.                  THE MASTER COPIES.
  2237.  
  2238. 4.1.4  DOCUMENTATION
  2239.  
  2240.      4.1.4.1   Security Features User's Guide
  2241.  
  2242.              A single summary, chapter, or manual in user documentation
  2243.              shall describe the protection mechanisms provided by the TCB,
  2244.              guidelines on their use, and how they interact with one another.
  2245.  
  2246.      4.1.4.2   Trusted Facility Manual
  2247.  
  2248.                A manual addressed to the ADP system administrator shall
  2249.              present cautions about functions and privileges that should be
  2250.              controlled when running a secure facility.  The procedures for
  2251.              examining and maintaining the audit files as well as the
  2252.              detailed audit record structure for each type of audit event
  2253.              shall be given.  The manual shall describe the operator and
  2254.              administrator functions related to security, to include 
  2255.              changing the security characteristics of a user.  It shall
  2256.              provide guidelines on the consistent and effective use of the
  2257.              protection features of the system, how they interact, how to
  2258.              securely generate a new TCB, and facility procedures, warnings,
  2259.              and privileges that need to be controlled in order to operate
  2260.              the facility in a secure manner.  The TCB modules that contain
  2261.              the reference validation mechanism shall be identified.  The 
  2262.              procedures for secure generation of a new TCB from source after
  2263.              modification of any modules in the TCB shall be described.  It
  2264.              shall include the procedures to ensure that the system is 
  2265.              initially started in a secure manner.  Procedures shall also be
  2266.              included to resume secure system operation after any lapse in 
  2267.              system operation.  
  2268.  
  2269.      4.1.4.3   Test Documentation
  2270.  
  2271.              The system developer shall provide to the evaluators a document
  2272.              that describes the test plan and results of the security
  2273.              mechanisms' functional testing.  It shall include results of 
  2274.              testing the effectiveness of the methods used to reduce covert
  2275.              channel bandwidths.  THE RESULTS OF THE MAPPING BETWEEN THE
  2276.              FORMAL TOP-LEVEL SPECIFICATION AND THE TCB SOURCE CODE SHALL BE
  2277.              GIVEN.
  2278.  
  2279.      4.1.4.4   Design Documentation
  2280.  
  2281.              Documentation shall be available that provides a description of
  2282.              the manufacturer's philosophy of protection and an explanation
  2283.              of how this philosophy is translated into the TCB.  The 
  2284.              interfaces between the TCB modules shall be described.  A
  2285.              formal description of the security policy model enforced by the
  2286.              TCB shall be available and proven that it is sufficient to 
  2287.              enforce the security policy.  The specific TCB protection 
  2288.              mechanisms shall be identified and an explanation given to show
  2289.              that they satisfy the model.  The descriptive top-level
  2290.              specification (DTLS) shall be shown to be an accurate 
  2291.              description of the TCB interface.  Documentation shall describe
  2292.              how the TCB implements the reference monitor concept and give 
  2293.              an explanation why it is tamperproof, cannot be bypassed, and
  2294.              is correctly implemented.  The TCB implementation (i.e., in
  2295.              hardware, firmware, and software) shall be informally shown to
  2296.              be consistent with the FORMAL TOP- LEVEL SPECIFICATION (FTLS).
  2297.              The elements of the FTLS shall be shown, using informal 
  2298.              techniques, to correspond to the elements of the TCB.  
  2299.              Documentation shall describe how the TCB is structured to
  2300.              facilitate testing and to enforce least privilege.  This
  2301.              documentation shall also present the results of the covert 
  2302.              channel analysis and the tradeoffs involved in restricting the
  2303.              channels.  All auditable events that may be used in the
  2304.              exploitation of known covert storage channels shall be 
  2305.              identified.  The bandwidths of known covert storage channels,
  2306.              the use of which is not detectable by the auditing mechanisms,
  2307.              shall be provided.  (See the Covert Channel Guideline section.)
  2308.              HARDWARE, FIRMWARE, AND SOFTWARE MECHANISMS NOT DEALT WITH IN
  2309.              THE FTLS BUT STRICTLY INTERNAL TO THE TCB (E.G., MAPPING
  2310.              REGISTERS, DIRECT MEMORY ACCESS I/O) SHALL BE CLEARLY DESCRIBED.
  2311.  
  2312. 4.2  BEYOND CLASS (A1)
  2313.  
  2314. Most of the security enhancements envisioned for systems that will provide
  2315. features and assurance in addition to that already provided by class (Al)
  2316. systems are beyond current technology.  The discussion below is intended to
  2317. guide future work and is derived from research and development activities
  2318. already underway in both the public and private sectors.  As more and better
  2319. analysis techniques are developed, the requirements for these systems will
  2320. become more explicit.  In the future, use of formal verification will be
  2321. extended to the source level and covert timing channels will be more fully
  2322. addressed.  At this level the design environment will become important and
  2323. testing will be aided by analysis of the formal top-level specification.
  2324. Consideration will be given to the correctness of the tools used in TCB
  2325. development (e.g., compilers, assemblers, loaders) and to the correct
  2326. functioning of the hardware/firmware on which the TCB will run.  Areas to be
  2327. addressed by systems beyond class (A1) include:
  2328.  
  2329.            * System Architecture
  2330.  
  2331.            A demonstration (formal or otherwise) must be given showing
  2332.            that requirements of self-protection and completeness for
  2333.            reference monitors have been implemented in the TCB.
  2334.  
  2335.            * Security Testing
  2336.  
  2337.            Although beyond the current state-of-the-art, it is
  2338.            envisioned that some test-case generation will be done
  2339.            automatically from the formal top-level specification or
  2340.            formal lower-level specifications.
  2341.  
  2342.            * Formal Specification and Verification
  2343.  
  2344.            The TCB must be verified down to the source code level,
  2345.            using formal verification methods where feasible.  Formal
  2346.            verification of the source code of the security-relevant
  2347.            portions of an operating system has proven to be a difficult
  2348.            task.  Two important considerations are the choice of a
  2349.            high-level language whose semantics can be fully and
  2350.            formally expressed, and a careful mapping, through
  2351.            successive stages, of the abstract formal design to a
  2352.            formalization of the implementation in low-level
  2353.            specifications.    Experience has shown that only when the
  2354.            lowest level specifications closely correspond to the actual
  2355.            code can code proofs be successfully accomplished.
  2356.  
  2357.            * Trusted Design Environment
  2358.  
  2359.            The TCB must be designed in a trusted facility with only
  2360.          trusted (cleared) personnel.
  2361.  
  2362.  
  2363.  
  2364.  
  2365.                                PART II:
  2366.  
  2367.  
  2368. 5.0  CONTROL OBJECTIVES FOR TRUSTED COMPUTER SYSTEMS
  2369.  
  2370. The criteria are divided within each class into groups of requirements.  These
  2371. groupings were developed to assure that three basic control objectives for
  2372. computer security are satisfied and not overlooked.  These control objectives
  2373. deal with:
  2374.  
  2375.                       * Security Policy
  2376.                       * Accountability
  2377.                       * Assurance
  2378.  
  2379. This section provides a discussion of these general control objectives and
  2380. their implication in terms of designing trusted systems.
  2381.  
  2382. 5.1  A Need for Consensus
  2383.  
  2384. A major goal of the DoD Computer Security Center is to encourage the Computer
  2385. Industry to develop trusted computer systems and products, making them widely
  2386. available in the commercial market place.  Achievement of this goal will
  2387. require recognition and articulation by both the public and private sectors of
  2388. a need and demand for such products.
  2389.  
  2390. As described in the introduction to this document, efforts to define the
  2391. problems and develop solutions associated with processing nationally sensitive
  2392. information, as well as other sensitive data such as financial, medical, and
  2393. personnel information used by the National Security Establishment, have been
  2394. underway for a number of years.  The criteria, as described in Part I,
  2395. represent the culmination of these efforts and describe basic requirements for
  2396. building trusted computer systems.  To date, however, these systems have been
  2397. viewed by many as only satisfying National Security needs.  As long as this
  2398. perception continues the consensus needed to motivate manufacture of trusted
  2399. systems will be lacking.
  2400.  
  2401. The purpose of this section is to describe, in some detail, the fundamental
  2402. control objectives that lay the foundations for requirements delineated in the
  2403. criteria.  The goal is to explain the foundations so that those outside the
  2404. National Security Establishment can assess their universality and, by
  2405. extension, the universal applicability of the criteria requirements to
  2406. processing all types of sensitive applications whether they be for National
  2407. Security or the private sector.
  2408.  
  2409. 5.2  Definition and Usefulness
  2410.  
  2411. The term "control objective" refers to a statement of intent with respect to
  2412. control over some aspect of an organization's resources, or processes, or
  2413. both.  In terms of a computer system, control objectives provide a framework
  2414. for developing a strategy for fulfilling a set of security requirements for
  2415. any given system.  Developed in response to generic vulnerabilities, such as
  2416. the need to manage and handle sensitive data in order to prevent compromise,
  2417. or the need to provide accountability in order to detect fraud, control
  2418. objectives have been identified as a useful method of expressing security
  2419. goals.[3]
  2420.  
  2421. Examples of control objectives include the three basic design requirements for
  2422. implementing the reference monitor concept discussed in Section 6.  They are:
  2423.  
  2424.         * The reference validation mechanism must be tamperproof.
  2425.  
  2426.         * The reference validation mechanism must always be invoked.
  2427.  
  2428.         * The reference validation mechanism must be small enough to be
  2429.           subjected to analysis and tests, the completeness of which can 
  2430.           be assured.[1]
  2431.  
  2432. 5.3  Criteria Control Objectives
  2433.  
  2434. The three basic control objectives of the criteria are concerned with security
  2435. policy, accountability, and assurance.  The remainder of this section provides
  2436. a discussion of these basic requirements.
  2437.  
  2438.      5.3.1  Security Policy
  2439.  
  2440.           In the most general sense, computer security is concerned with
  2441.           controlling the way in which a computer can be used, i.e., 
  2442.           controlling how information processed by it can be accessed and 
  2443.           manipulated.  However, at closer examination, computer security 
  2444.           can refer to a number of areas.  Symptomatic of this, FIPS PUB 39,
  2445.           Glossary For Computer Systems Security, does not have a unique
  2446.           definition for computer security.[16]  Instead there are eleven
  2447.           separate definitions for security which include: ADP systems 
  2448.           security, administrative security, data security, etc.  A common 
  2449.           thread running through these definitions is the word "protection."
  2450.           Further declarations of protection requirements can be found in
  2451.           DoD Directive 5200.28 which describes an acceptable level of
  2452.           protection for classified data to be one that will "assure that
  2453.           systems which process, store, or use classified data and produce
  2454.           classified information will, with reasonable dependability, 
  2455.           prevent: a. Deliberate or inadvertent access to classified 
  2456.           material by unauthorized persons, and b.  Unauthorized 
  2457.           manipulation of the computer and its associated peripheral 
  2458.           devices."[8]
  2459.  
  2460.           In summary, protection requirements must be defined in terms of
  2461.           the perceived threats, risks, and goals of an organization.  This
  2462.           is often stated in terms of a security policy.  It has been 
  2463.           pointed out in the literature that it is external laws, rules, 
  2464.           regulations, etc.  that establish what access to information is to
  2465.           be permitted, independent of the use of a computer.  In particular,
  2466.           a given system can only be said to be secure with respect to its
  2467.           enforcement of some specific policy.[30]  Thus, the control 
  2468.           objective for security policy is:
  2469.  
  2470.           SECURITY POLICY CONTROL OBJECTIVE
  2471.  
  2472.           A STATEMENT OF INTENT WITH REGARD TO CONTROL OVER ACCESS TO AND
  2473.           DISSEMINATION OF INFORMATION, TO BE KNOWN AS THE SECURITY POLICY,
  2474.           MUST BE PRECISELY DEFINED AND IMPLEMENTED FOR EACH SYSTEM THAT IS
  2475.           USED TO PROCESS SENSITIVE INFORMATION.  THE SECURITY POLICY MUST 
  2476.           ACCURATELY REFLECT THE LAWS, REGULATIONS, AND GENERAL POLICIES
  2477.           FROM WHICH IT IS DERIVED.
  2478.  
  2479.         5.3.1.1  Mandatory Security Policy
  2480.  
  2481.                  Where a security policy is developed that is to be applied
  2482.                  to control of classified or other specifically designated 
  2483.                  sensitive information, the policy must include detailed 
  2484.                  rules on how to handle that information throughout its
  2485.                  life-cycle.  These rules are a function of the various
  2486.                  sensitivity designations that the information can assume 
  2487.                  and the various forms of access supported by the system.
  2488.                  Mandatory security refers to the enforcement of a set of
  2489.                  access control rules that constrains a subject's access to
  2490.                  information on the basis of a comparison of that 
  2491.                  individual's clearance/authorization to the information,
  2492.                  the classification/sensitivity designation of the
  2493.                  information, and the form of access being mediated.
  2494.                  Mandatory policies either require or can be satisfied by 
  2495.                  systems that can enforce a partial ordering of 
  2496.                  designations, namely, the designations must form what is
  2497.                  mathematically known as a "lattice."[5]
  2498.  
  2499.                  A clear implication of the above is that the system must
  2500.                  assure that the designations associated with sensitive data
  2501.                  cannot be arbitrarily changed, since this could permit 
  2502.                  individuals who lack the appropriate authorization to 
  2503.                  access sensitive information.  Also implied is the
  2504.                  requirement that the system control the flow of information
  2505.                  so that data cannot be stored with lower sensitivity 
  2506.                  designations unless its "downgrading" has been authorized.
  2507.                  The control objective is:
  2508.  
  2509.                  MANDATORY SECURITY CONTROL OBJECTIVE
  2510.  
  2511.                  SECURITY POLICIES DEFINED FOR SYSTEMS THAT ARE USED TO
  2512.                  PROCESS CLASSIFIED OR OTHER SPECIFICALLY CATEGORIZED 
  2513.                  SENSITIVE INFORMATION MUST INCLUDE PROVISIONS FOR THE 
  2514.                  ENFORCEMENT OF MANDATORY ACCESS CONTROL RULES.  THAT IS,
  2515.                  THEY MUST INCLUDE A SET OF RULES FOR CONTROLLING ACCESS 
  2516.                  BASED DIRECTLY ON A COMPARISON OF THE INDIVIDUAL'S 
  2517.                  CLEARANCE OR AUTHORIZATION FOR THE INFORMATION AND THE 
  2518.                  CLASSIFICATION OR SENSITIVITY DESIGNATION OF THE
  2519.                  INFORMATION BEING SOUGHT, AND INDIRECTLY ON CONSIDERATIONS
  2520.                  OF PHYSICAL AND OTHER ENVIRONMENTAL FACTORS OF CONTROL.  
  2521.                  THE MANDATORY ACCESS CONTROL RULES MUST ACCURATELY REFLECT
  2522.                  THE LAWS, REGULATIONS, AND GENERAL POLICIES FROM WHICH
  2523.                  THEY ARE DERIVED.
  2524.  
  2525.         5.3.1.2  Discretionary Security Policy
  2526.  
  2527.                  Discretionary security is the principal type of access
  2528.                  control available in computer systems today.  The basis of
  2529.                  this kind of security is that an individual user, or
  2530.                  program operating on his behalf, is allowed to specify
  2531.                  explicitly the types of access other users may have to
  2532.                  information under his control.  Discretionary security
  2533.                  differs from mandatory security in that it implements an
  2534.                  access control policy on the basis of an individual's
  2535.                  need-to-know as opposed to mandatory controls which are
  2536.                  driven by the classification or sensitivity designation of
  2537.                  the information.
  2538.  
  2539.                  Discretionary controls are not a replacement for mandatory
  2540.                  controls.  In an environment in which information is 
  2541.                  classified (as in the DoD) discretionary security provides
  2542.                  for a finer granularity of control within the overall
  2543.                  constraints of the mandatory policy.  Access to classified
  2544.                  information requires effective implementation of both types
  2545.                  of controls as precondition to granting that access.  In 
  2546.                  general, no person may have access to classified
  2547.                  information unless: (a) that person has been determined to
  2548.                  be trustworthy, i.e., granted a personnel security 
  2549.                  clearance -- MANDATORY, and (b) access is necessary for the
  2550.                  performance of official duties, i.e., determined to have a
  2551.                  need-to-know -- DISCRETIONARY.  In other words, 
  2552.                  discretionary controls give individuals discretion to 
  2553.                  decide on which of the permissible accesses will actually
  2554.                  be allowed to which users, consistent with overriding
  2555.                  mandatory policy restrictions.  The control objective is:
  2556.  
  2557.                  DISCRETIONARY SECURITY CONTROL OBJECTIVE
  2558.  
  2559.                  SECURITY POLICIES DEFINED FOR SYSTEMS THAT ARE USED TO
  2560.                  PROCESS CLASSIFIED OR OTHER SENSITIVE INFORMATION MUST 
  2561.                  INCLUDE PROVISIONS FOR THE ENFORCEMENT OF DISCRETIONARY
  2562.                  ACCESS CONTROL RULES.  THAT IS, THEY MUST INCLUDE A
  2563.                  CONSISTENT SET OF RULES FOR CONTROLLING AND LIMITING ACCESS
  2564.                  BASED ON IDENTIFIED INDIVIDUALS WHO HAVE BEEN DETERMINED TO
  2565.                  HAVE A NEED-TO-KNOW FOR THE INFORMATION.
  2566.  
  2567.         5.3.1.3  Marking
  2568.  
  2569.                  To implement a set of mechanisms that will put into effect
  2570.                  a mandatory security policy, it is necessary that the 
  2571.                  system mark information with appropriate classification or
  2572.                  sensitivity labels and maintain these markings as the
  2573.                  information moves through the system.  Once information is
  2574.                  unalterably and accurately marked, comparisons required by
  2575.                  the mandatory access control rules can be accurately and
  2576.                  consistently made.  An additional benefit of having the
  2577.                  system maintain the classification or sensitivity label
  2578.                  internally is the ability to automatically generate 
  2579.                  properly "labeled" output.  The labels, if accurately and
  2580.                  integrally maintained by the system, remain accurate when
  2581.                  output from the system.  The control objective is:
  2582.  
  2583.                  MARKING CONTROL OBJECTIVE
  2584.  
  2585.                  SYSTEMS THAT ARE DESIGNED TO ENFORCE A MANDATORY SECURITY
  2586.                  POLICY MUST STORE AND PRESERVE THE INTEGRITY OF 
  2587.                  CLASSIFICATION OR OTHER SENSITIVITY LABELS FOR ALL 
  2588.                  INFORMATION.  LABELS EXPORTED FROM THE SYSTEM MUST BE
  2589.                  ACCURATE REPRESENTATIONS OF THE CORRESPONDING INTERNAL 
  2590.                  SENSITIVITY LABELS BEING EXPORTED.
  2591.  
  2592.      5.3.2  Accountability
  2593.  
  2594.           The second basic control objective addresses one of the
  2595.           fundamental principles of security, i.e., individual 
  2596.           accountability.  Individual accountability is the key to securing
  2597.           and controlling any system that processes information on behalf
  2598.           of individuals or groups of individuals.  A number of requirements
  2599.           must be met in order to satisfy this objective.
  2600.  
  2601.           The first requirement is for individual user identification.
  2602.           Second, there is a need for authentication of the identification.
  2603.           Identification is functionally dependent on authentication.  
  2604.           Without authentication, user identification has no credibility.  
  2605.           Without a credible identity, neither mandatory nor discretionary
  2606.           security policies can be properly invoked because there is no
  2607.           assurance that proper authorizations can be made.
  2608.  
  2609.           The third requirement is for dependable audit capabilities.  That
  2610.           is, a trusted computer system must provide authorized personnel 
  2611.           with the ability to audit any action that can potentially cause
  2612.           access to, generation of, or effect the release of classified or
  2613.           sensitive information.  The audit data will be selectively 
  2614.           acquired based on the auditing needs of a particular installation
  2615.           and/or application.  However, there must be sufficient granularity
  2616.           in the audit data to support tracing the auditable events to a
  2617.           specific individual who has taken the actions or on whose behalf
  2618.           the actions were taken.  The control objective is:
  2619.  
  2620.           ACCOUNTABILITY CONTROL OBJECTIVE
  2621.  
  2622.           SYSTEMS THAT ARE USED TO PROCESS OR HANDLE CLASSIFIED OR OTHER
  2623.           SENSITIVE INFORMATION MUST ASSURE INDIVIDUAL ACCOUNTABILITY 
  2624.           WHENEVER EITHER A MANDATORY OR DISCRETIONARY SECURITY POLICY IS
  2625.           INVOKED.  FURTHERMORE, TO ASSURE ACCOUNTABILITY THE CAPABILITY 
  2626.           MUST EXIST FOR AN AUTHORIZED AND COMPETENT AGENT TO ACCESS AND
  2627.           EVALUATE ACCOUNTABILITY INFORMATION BY A SECURE MEANS, WITHIN A
  2628.           REASONABLE AMOUNT OF TIME, AND WITHOUT UNDUE DIFFICULTY.
  2629.  
  2630.      5.3.3  Assurance
  2631.  
  2632.           The third basic control objective is concerned with guaranteeing
  2633.           or providing confidence that the security policy has been 
  2634.           implemented correctly and that the protection-relevant elements of
  2635.           the system do, indeed, accurately mediate and enforce the intent
  2636.           of that policy.  By extension, assurance must include a guarantee
  2637.           that the trusted portion of the system works only as intended.  To
  2638.           accomplish these objectives, two types of assurance are needed.
  2639.           They are life-cycle assurance and operational assurance.
  2640.  
  2641.           Life-cycle assurance refers to steps taken by an organization to
  2642.           ensure that the system is designed, developed, and maintained 
  2643.           using formalized and rigorous controls and standards.[17]  
  2644.           Computer systems that process and store sensitive or classified
  2645.           information depend on the hardware and software to protect that
  2646.           information.  It follows that the hardware and software themselves
  2647.           must be protected against unauthorized changes that could cause
  2648.           protection mechanisms to malfunction or be bypassed completely.  
  2649.           For this reason trusted computer systems must be carefully 
  2650.           evaluated and tested during the design and development phases and
  2651.           reevaluated whenever changes are made that could affect the
  2652.           integrity of the protection mechanisms.  Only in this way can
  2653.           confidence be provided that the hardware and software 
  2654.           interpretation of the security policy is maintained accurately 
  2655.           and without distortion.
  2656.  
  2657.           While life-cycle assurance is concerned with procedures for
  2658.           managing system design, development, and maintenance; operational
  2659.           assurance focuses on features and system architecture used to
  2660.           ensure that the security policy is uncircumventably enforced
  2661.           during system operation.  That is, the security policy must be
  2662.           integrated into the hardware and software protection features of
  2663.           the system.  Examples of steps taken to provide this kind of
  2664.           confidence include: methods for testing the operational hardware 
  2665.           and software for correct operation, isolation of protection-
  2666.           critical code, and the use of hardware and software to provide
  2667.           distinct domains.  The control objective is:
  2668.  
  2669.           ASSURANCE CONTROL OBJECTIVE
  2670.  
  2671.           SYSTEMS THAT ARE USED TO PROCESS OR HANDLE CLASSIFIED OR OTHER
  2672.           SENSITIVE INFORMATION MUST BE DESIGNED TO GUARANTEE CORRECT AND
  2673.           ACCURATE INTERPRETATION OF THE SECURITY POLICY AND MUST NOT 
  2674.           DISTORT THE INTENT OF THAT POLICY.  ASSURANCE MUST BE PROVIDED
  2675.           THAT CORRECT IMPLEMENTATION AND OPERATION OF THE POLICY EXISTS
  2676.           THROUGHOUT THE SYSTEM'S LIFE-CYCLE.  
  2677.  
  2678.  
  2679. 6.0 RATIONALE BEHIND THE EVALUATION CLASSES
  2680.  
  2681. 6.1  The Reference Monitor Concept
  2682.  
  2683. In October of 1972, the Computer Security Technology Planning Study, conducted
  2684. by James P.  Anderson & Co., produced a report for the Electronic Systems
  2685. Division (ESD) of the United States Air Force.[1]  In that report, the concept
  2686. of "a reference monitor which enforces the authorized access relationships
  2687. between subjects and objects of a system" was introduced.  The reference
  2688. monitor concept was found to be an essential element of any system that would
  2689. provide multilevel secure computing facilities and controls.
  2690.  
  2691. The Anderson report went on to define the reference validation mechanism as
  2692. "an implementation of the reference monitor concept .  .  .  that validates
  2693. each reference to data or programs by any user (program) against a list of
  2694. authorized types of reference for that user." It then listed the three design
  2695. requirements that must be met by a reference validation mechanism:
  2696.  
  2697.         a. The reference validation mechanism must be tamper proof.
  2698.  
  2699.         b. The reference validation mechanism must always be invoked.
  2700.  
  2701.         c. The reference validation mechanism must be small enough to be
  2702.            subject to analysis and tests, the completeness of which can 
  2703.            be assured."[1]
  2704.  
  2705. Extensive peer review and continuing research and development activities have
  2706. sustained the validity of the Anderson Committee's findings.  Early examples
  2707. of the reference validation mechanism were known as security kernels.  The
  2708. Anderson Report described the security kernel as "that combination of hardware
  2709. and software which implements the reference monitor concept."[1]  In this vein,
  2710. it will be noted that the security kernel must support the three reference
  2711. monitor requirements listed above.
  2712.  
  2713. 6.2  A Formal Security Policy Model
  2714.  
  2715. Following the publication of the Anderson report, considerable research was
  2716. initiated into formal models of security policy requirements and of the
  2717. mechanisms that would implement and enforce those policy models as a security
  2718. kernel.  Prominent among these efforts was the ESD-sponsored development of
  2719. the Bell and LaPadula model, an abstract formal treatment of DoD security
  2720. policy.[2]  Using mathematics and set theory, the model precisely defines the
  2721. notion of secure state, fundamental modes of access, and the rules for
  2722. granting subjects specific modes of access to objects.  Finally, a theorem is
  2723. proven to demonstrate that the rules are security-preserving operations, so
  2724. that the application of any sequence of the rules to a system that is in a
  2725. secure state will result in the system entering a new state that is also
  2726. secure.  This theorem is known as the Basic Security Theorem.
  2727.  
  2728. The Bell and LaPadula model defines a relationship between clearances of
  2729. subjects and classifications of system objects, now referenced as the
  2730. "dominance relation." From this definition, accesses permitted between
  2731. subjects and objects are explicitly defined for the fundamental modes of
  2732. access, including read-only access, read/write access, and write-only access.
  2733. The model defines the Simple Security Condition to control granting a subject
  2734. read access to a specific object, and the *-Property (read "Star Property") to
  2735. control granting a subject write access to a specific object.  Both the Simple
  2736. Security Condition and the *-Property include mandatory security provisions
  2737. based on the dominance relation between the clearance of the subject and the
  2738. classification of the object.  The Discretionary Security Property is also
  2739. defined, and requires that a specific subject be authorized for the particular
  2740. mode of access required for the state transition.  In its treatment of
  2741. subjects (processes acting on behalf of a user), the model distinguishes
  2742. between trusted subjects (i.e., not constrained within the model by the
  2743. *-Property) and untrusted subjects (those that are constrained by the
  2744. *-Property).
  2745.  
  2746. From the Bell and LaPadula model there evolved a model of the method of proof
  2747. required to formally demonstrate that all arbitrary sequences of state
  2748. transitions are security-preserving.  It was also shown that the *- Property
  2749. is sufficient to prevent the compromise of information by Trojan Horse
  2750. attacks.
  2751.  
  2752. 6.3  The Trusted Computing Base
  2753.  
  2754. In order to encourage the widespread commercial availability of trusted
  2755. computer systems, these evaluation criteria have been designed to address
  2756. those systems in which a security kernel is specifically implemented as well
  2757. as those in which a security kernel has not been implemented.  The latter case
  2758. includes those systems in which objective (c) is not fully supported because
  2759. of the size or complexity of the reference validation mechanism.  For
  2760. convenience, these evaluation criteria use the term Trusted Computing Base to
  2761. refer to the reference validation mechanism, be it a security kernel,
  2762. front-end security filter, or the entire trusted computer system.
  2763.  
  2764. The heart of a trusted computer system is the Trusted Computing Base (TCB)
  2765. which contains all of the elements of the system responsible for supporting
  2766. the security policy and supporting the isolation of objects (code and data) on
  2767. which the protection is based.  The bounds of the TCB equate to the "security
  2768. perimeter" referenced in some computer security literature.  In the interest
  2769. of understandable and maintainable protection, a TCB should be as simple as
  2770. possible consistent with the functions it has to perform.  Thus, the TCB
  2771. includes hardware, firmware, and software critical to protection and must be
  2772. designed and implemented such that system elements excluded from it need not
  2773. be trusted to maintain protection.  Identification of the interface and
  2774. elements of the TCB along with their correct functionality therefore forms the
  2775. basis for evaluation.
  2776.  
  2777. For general-purpose systems, the TCB will include key elements of the
  2778. operating system and may include all of the operating system.  For embedded
  2779. systems, the security policy may deal with objects in a way that is meaningful
  2780. at the application level rather than at the operating system level.  Thus, the
  2781. protection policy may be enforced in the application software rather than in
  2782. the underlying operating system.  The TCB will necessarily include all those
  2783. portions of the operating system and application software essential to the
  2784. support of the policy.  Note that, as the amount of code in the TCB increases,
  2785. it becomes harder to be confident that the TCB enforces the reference monitor
  2786. requirements under all circumstances.
  2787.  
  2788. 6.4  Assurance
  2789.  
  2790. The third reference monitor design objective is currently interpreted as
  2791. meaning that the TCB "must be of sufficiently simple organization and
  2792. complexity to be subjected to analysis and tests, the completeness of which
  2793. can be assured."
  2794.  
  2795. Clearly, as the perceived degree of risk increases (e.g., the range of
  2796. sensitivity of the system's protected data, along with the range of clearances
  2797. held by the system's user population) for a particular system's operational
  2798. application and environment, so also must the assurances be increased to
  2799. substantiate the degree of trust that will be placed in the system.  The
  2800. hierarchy of requirements that are presented for the evaluation classes in the
  2801. trusted computer system evaluation criteria reflect the need for these
  2802. assurances.
  2803.  
  2804. As discussed in Section 5.3, the evaluation criteria uniformly require a
  2805. statement of the security policy that is enforced by each trusted computer
  2806. system.  In addition, it is required that a convincing argument be presented
  2807. that explains why the TCB satisfies the first two design requirements for a
  2808. reference monitor.  It is not expected that this argument will be entirely
  2809. formal.  This argument is required for each candidate system in order to
  2810. satisfy the assurance control objective.
  2811.  
  2812. The systems to which security enforcement mechanisms have been added, rather
  2813. than built-in as fundamental design objectives, are not readily amenable to
  2814. extensive analysis since they lack the requisite conceptual simplicity of a
  2815. security kernel.  This is because their TCB extends to cover much of the
  2816. entire system.  Hence, their degree of trustworthiness can best be ascertained
  2817. only by obtaining test results.  Since no test procedure for something as
  2818. complex as a computer system can be truly exhaustive, there is always the
  2819. possibility that a subsequent penetration attempt could succeed.  It is for
  2820. this reason that such systems must fall into the lower evaluation classes.
  2821.  
  2822. On the other hand, those systems that are designed and engineered to support
  2823. the TCB concepts are more amenable to analysis and structured testing.  Formal
  2824. methods can be used to analyze the correctness of their reference validation
  2825. mechanisms in enforcing the system's security policy.  Other methods,
  2826. including less-formal arguments, can be used in order to substantiate claims
  2827. for the completeness of their access mediation and their degree of
  2828. tamper-resistance.  More confidence can be placed in the results of this
  2829. analysis and in the thoroughness of the structured testing than can be placed
  2830. in the results for less methodically structured systems.  For these reasons,
  2831. it appears reasonable to conclude that these systems could be used in
  2832. higher-risk environments.  Successful implementations of such systems would be
  2833. placed in the higher evaluation classes.
  2834.  
  2835. 6.5  The Classes
  2836.  
  2837. It is highly desirable that there be only a small number of overall evaluation
  2838. classes.  Three major divisions have been identified in the evaluation
  2839. criteria with a fourth division reserved for those systems that have been
  2840. evaluated and found to offer unacceptable security protection.  Within each
  2841. major evaluation division, it was found that "intermediate" classes of trusted
  2842. system design and development could meaningfully be defined.  These
  2843. intermediate classes have been designated in the criteria because they
  2844. identify systems that:
  2845.  
  2846.         * are viewed to offer significantly better protection and assurance
  2847.           than would systems that satisfy the basic requirements for their
  2848.           evaluation class; and
  2849.  
  2850.         * there is reason to believe that systems in the intermediate
  2851.           evaluation classes could eventually be evolved such that they 
  2852.           would satisfy the requirements for the next higher evaluation 
  2853.           class.
  2854.  
  2855. Except within division A it is not anticipated that additional "intermediate"
  2856. evaluation classes satisfying the two characteristics described above will be
  2857. identified.
  2858.  
  2859. Distinctions in terms of system architecture, security policy enforcement, and
  2860. evidence of credibility between evaluation classes have been defined such that
  2861. the "jump" between evaluation classes would require a considerable investment
  2862. of effort on the part of implementors.  Correspondingly, there are expected to
  2863. be significant differentials of risk to which systems from the higher
  2864. evaluation classes will be exposed.
  2865.  
  2866.  
  2867. 7.0  THE RELATIONSHIP BETWEEN POLICY AND THE CRITERIA
  2868.  
  2869. Section 1 presents fundamental computer security requirements and Section 5
  2870. presents the control objectives for Trusted Computer Systems.  They are
  2871. general requirements, useful and necessary, for the development of all secure
  2872. systems.  However, when designing systems that will be used to process
  2873. classified or other sensitive information, functional requirements for meeting
  2874. the Control Objectives become more specific.  There is a large body of policy
  2875. laid down in the form of Regulations, Directives, Presidential Executive
  2876. Orders, and OMB Circulars that form the basis of the procedures for the
  2877. handling and processing of Federal information in general and classified
  2878. information specifically.  This section presents pertinent excerpts from these
  2879. policy statements and discusses their relationship to the Control Objectives.
  2880.  
  2881.  
  2882. 7.1  Established Federal Policies
  2883.  
  2884. A significant number of computer security policies and associated requirements
  2885. have been promulgated by Federal government elements.  The interested reader
  2886. is referred to reference [32] which analyzes the need for trusted systems in
  2887. the civilian agencies of the Federal government, as well as in state and local
  2888. governments and in the private sector.  This reference also details a number
  2889. of relevant Federal statutes, policies and requirements not treated further
  2890. below.
  2891.  
  2892. Security guidance for Federal automated information systems is provided by the
  2893. Office of Management and Budget.  Two specifically applicable Circulars have
  2894. been issued.  OMB Circular No.  A-71, Transmittal Memorandum No.  1, "Security
  2895. of Federal Automated Information Systems,"[26] directs each executive agency
  2896. to establish and maintain a computer security program.  It makes the head of
  2897. each executive branch, department and agency responsible "for assuring an
  2898. adequate level of security for all agency data whether processed in-house or
  2899. commercially.  This includes responsibility for the establishment of physical,
  2900. administrative and technical safeguards required to adequately protect
  2901. personal, proprietary or other sensitive data not subject to national security
  2902. regulations, as well as national security data."[26, para. 4 p. 2]
  2903.  
  2904. OMB Circular No.  A-123, "Internal Control Systems,"[27] issued to help
  2905. eliminate fraud, waste, and abuse in government programs requires: (a) agency
  2906. heads to issue internal control directives and assign responsibility, (b)
  2907. managers to review programs for vulnerability, and (c) managers to perform
  2908. periodic reviews to evaluate strengths and update controls.  Soon after
  2909. promulgation of OMB Circular A-123, the relationship of its internal control
  2910. requirements to building secure computer systems was recognized.[4] While not
  2911. stipulating computer controls specifically, the definition of Internal
  2912. Controls in A-123 makes it clear that computer systems are to be included:
  2913.  
  2914.      "Internal Controls - The plan of organization and all of the methods and
  2915.       measures adopted within an agency to safeguard its resources, assure the
  2916.       accuracy and reliability of its information, assure adherence to 
  2917.       applicable laws, regulations and policies, and promote operational 
  2918.       economy and efficiency."[27, sec. 4.C]
  2919.  
  2920. The matter of classified national security information processed by ADP
  2921. systems was one of the first areas given serious and extensive concern in
  2922. computer security.  The computer security policy documents promulgated as a
  2923. result contain generally more specific and structured requirements than most,
  2924. keyed in turn to an authoritative basis that itself provides a rather clearly
  2925. articulated and structured information security policy.  This basis, Executive
  2926. Order 12356, "National Security Information," sets forth requirements for the
  2927. classification, declassification and safeguarding of "national security
  2928. information" per se.[14]
  2929.  
  2930. 7.2  DoD Policies
  2931.  
  2932. Within the Department of Defense, these broad requirements are implemented and
  2933. further specified primarily through two vehicles: 1) DoD Regulation 5200.1-R
  2934. [7], which applies to all components of the DoD as such, and 2) DoD 5220.22-M,
  2935. "Industrial Security Manual for Safeguarding Classified Information" [11],
  2936. which applies to contractors included within the Defense Industrial Security
  2937. Program.  Note that the latter transcends DoD as such, since it applies not
  2938. only to any contractors handling classified information for any DoD component,
  2939. but also to the contractors of eighteen other Federal organizations for whom
  2940. the Secretary of Defense is authorized to act in rendering industrial security
  2941. services.*
  2942.  
  2943.            ____________________________________________________________
  2944.            * i.e., NASA, Commerce Department, GSA, State Department,
  2945.            Small Business Administration, National Science Foundation,
  2946.            Treasury Department, Transportation Department, Interior
  2947.            Department, Agriculture Department, Health and Human
  2948.            Services Department, Labor Department, Environmental
  2949.            Protection Agency, Justice Department, U.S. Arms Control and
  2950.            Disarmament Agency, Federal Emergency Management Agency,
  2951.            Federal Reserve System, and U.S. General Accounting Office.
  2952.            ____________________________________________________________
  2953.  
  2954.  
  2955. For ADP systems, these information security requirements are further amplified
  2956. and specified in: 1) DoD Directive 5200.28 [8] and DoD Manual 5200.28-M [9],
  2957. for DoD components; and 2) Section XIII of DoD 5220.22-M [11] for contractors.
  2958. DoD Directive 5200.28, "Security Requirements for Automatic Data Processing
  2959. (ADP) Systems," stipulates: "Classified material contained in an ADP system
  2960. shall be safeguarded by the continuous employment of protective features in
  2961. the system's hardware and software design and configuration .  .  .  ."[8,
  2962. sec.  IV] Furthermore, it is required that ADP systems that "process, store,
  2963. or use classified data and produce classified information will, with
  2964. reasonable dependability, prevent:
  2965.  
  2966.      a.  Deliberate or inadvertent access to classified material by
  2967.          unauthorized persons, and
  2968.  
  2969.      b.  Unauthorized manipulation of the computer and its associated
  2970.          peripheral devices."[8, sec. I B.3]
  2971.  
  2972. Requirements equivalent to these appear within DoD 5200.28-M [9] and in DoD
  2973. 5220.22-M [11].
  2974.  
  2975. From requirements imposed by these regulations, directives and circulars, the
  2976. three components of the Security Policy Control Objective, i.e., Mandatory and
  2977. Discretionary Security and Marking, as well as the Accountability and
  2978. Assurance Control Objectives, can be functionally defined for DoD
  2979. applications.  The following discussion provides further specificity in Policy
  2980. for these Control Objectives.
  2981.  
  2982. 7.3  Criteria Control Objective for Security Policy
  2983.  
  2984.      7.3.1  Marking
  2985.  
  2986.           The control objective for marking is: "Systems that are designed
  2987.           to enforce a mandatory security policy must store and preserve the
  2988.           integrity of classification or other sensitivity labels for all 
  2989.           information.  Labels exported from the system must be accurate 
  2990.           representations of the corresonding internal sensitivity labels
  2991.           being exported."
  2992.  
  2993.           DoD 5220.22-M, "Industrial Security Manual for Safeguarding
  2994.           Classified Information," explains in paragraph 11 the reasons for 
  2995.           marking information:
  2996.  
  2997.                "Designation by physical marking, notation or other means
  2998.                serves to inform and to warn the holder about the 
  2999.                classification designation of the information which requires
  3000.                protection in the interest of national security.  The degree
  3001.                of protection against unauthorized disclosure which will be
  3002.                required for a particular level of classification is directly
  3003.                commensurate with the marking designation which is assigned 
  3004.                to the material."[11]
  3005.  
  3006.           Marking requirements are given in a number of policy statements.
  3007.  
  3008.           Executive Order 12356 (Sections 1.5.a and 1.5.a.1) requires that
  3009.           classification markings "shall be shown on the face of all 
  3010.           classified documents, or clearly associated with other forms of 
  3011.           classified information in a manner appropriate to the medium 
  3012.           involved."[14]
  3013.  
  3014.           DoD Regulation 5200.1-R (Section 1-500) requires that: ".  .  .
  3015.           information or material that requires protection against 
  3016.           unauthorized disclosure in the interest of national security shall
  3017.           be classified in one of three designations, namely: 'Top Secret,'
  3018.           'Secret' or 'Confidential.'"[7] (By extension, for use in computer
  3019.           processing, the unofficial designation "Unclassified" is used to
  3020.           indicate information that does not fall under one of the other
  3021.           three designations of classified information.)
  3022.  
  3023.           DoD Regulation 5200.1-R (Section 4-304b) requires that: "ADP
  3024.           systems and word processing systems employing such media shall 
  3025.           provide for internal classification marking to assure that 
  3026.           classified information contained therein that is reproduced or 
  3027.           generated, will bear applicable classification and associated
  3028.           markings." (This regulation provides for the exemption of certain
  3029.           existing systems where "internal classification and applicable
  3030.           associated markings cannot be implemented without extensive system
  3031.           modifications."[7]  However, it is clear that future DoD ADP 
  3032.           systems must be able to provide applicable and accurate labels for
  3033.           classified and other sensitive information.)
  3034.  
  3035.           DoD Manual 5200.28-M (Section IV, 4-305d) requires the following:
  3036.           "Security Labels - All classified material accessible by or within
  3037.           the ADP system shall be identified as to its security 
  3038.           classification and access or dissemination limitations, and all
  3039.           output of the ADP system shall be appropriately marked."[9]
  3040.  
  3041.      7.3.2  Mandatory Security
  3042.  
  3043.           The control objective for mandatory security is: "Security
  3044.           policies defined for systems that are used to process classified
  3045.           or other specifically categorized sensitive information must 
  3046.           include provisions for the enforcement of mandatory access control
  3047.           rules.  That is, they must include a set of rules for controlling
  3048.           access based directly on a comparison of the individual's
  3049.           clearance or authorization for the information and the 
  3050.           classification or sensitivity designation of the information being
  3051.           sought, and indirectly on considerations of physical and other 
  3052.           environmental factors of control.  The mandatory access control
  3053.           rules must accurately reflect the laws, regulations, and general
  3054.           policies from which they are derived."
  3055.  
  3056.           There are a number of policy statements that are related to
  3057.           mandatory security.
  3058.  
  3059.           Executive Order 12356 (Section 4.1.a) states that "a person is
  3060.           eligible for access to classified information provided that a 
  3061.           determination of trustworthiness has been made by agency heads or
  3062.           designated officials and provided that such access is essential
  3063.           to the accomplishment of lawful and authorized Government
  3064.           purposes."[14]
  3065.  
  3066.           DoD Regulation 5200.1-R (Chapter I, Section 3) defines a Special
  3067.           Access Program as "any program imposing 'need-to-know' or access
  3068.           controls beyond those normally provided for access to 
  3069.           Confidential, Secret, or Top Secret information.  Such a program
  3070.           includes, but is not limited to, special clearance, adjudication,
  3071.           or investigative requirements, special designation of officials
  3072.           authorized to determine 'need-to-know', or special lists of persons
  3073.           determined to have a 'need-to- know.'"[7, para.  1-328] This
  3074.           passage distinguishes between a 'discretionary' determination of
  3075.           need-to-know and formal need-to-know which is implemented through
  3076.           Special Access Programs.  DoD Regulation 5200.1-R, paragraph 7-100
  3077.           describes general requirements for trustworthiness (clearance) and
  3078.           need-to-know, and states that the individual with possession,
  3079.           knowledge or control of classified information has final
  3080.           responsibility for determining if conditions for access have been
  3081.           met.  This regulation further stipulates that "no one has a right
  3082.           to have access to classified information solely by virtue of rank
  3083.           or position." [7, para. 7-100])
  3084.  
  3085.           DoD Manual 5200.28-M (Section II 2-100) states that, "Personnel
  3086.           who develop, test (debug), maintain, or use programs which are 
  3087.           classified or which will be used to access or develop classified
  3088.           material shall have a personnel security clearance and an access
  3089.           authorization (need-to-know), as appropriate for the highest
  3090.           classified and most restrictive category of classified material
  3091.           which they will access under system constraints."[9]
  3092.  
  3093.           DoD Manual 5220.22-M (Paragraph 3.a) defines access as "the
  3094.           ability and opportunity to obtain knowledge of classified 
  3095.           information.  An individual, in fact, may have access to 
  3096.           classified information by being in a place where such information
  3097.           is kept, if the security measures which are in force do not
  3098.           prevent him from gaining knowledge of the classified 
  3099.           information."[11]
  3100.  
  3101.           The above mentioned Executive Order, Manual, Directives and
  3102.           Regulations clearly imply that a trusted computer system must 
  3103.           assure that the classification labels associated with sensitive
  3104.           data cannot be arbitrarily changed, since this could permit
  3105.           individuals who lack the appropriate clearance to access
  3106.           classified information.  Also implied is the requirement that a
  3107.           trusted computer system must control the flow of information so 
  3108.           that data from a higher classification cannot be placed in a 
  3109.           storage object of lower classification unless its "downgrading" 
  3110.           has been authorized.
  3111.  
  3112.      7.3.3  Discretionary Security
  3113.  
  3114.           The term discretionary security refers to a computer system's
  3115.           ability to control information on an individual basis.  It stems
  3116.           from the fact that even though an individual has all the formal 
  3117.           clearances for access to specific classified information, each
  3118.           individual's access to information must be based on a demonstrated
  3119.           need-to-know.  Because of this, it must be made clear that this
  3120.           requirement is not discretionary in a "take it or leave it" sense.
  3121.           The directives and regulations are explicit in stating that the
  3122.           need-to-know test must be satisfied before access can be granted 
  3123.           to the classified information.  The control objective for 
  3124.           discretionary security is: "Security policies defined for systems
  3125.           that are used to process classified or other sensitive information
  3126.           must include provisions for the enforcement of discretionary
  3127.           access control rules.  That is, they must include a consistent set
  3128.           of rules for controlling and limiting access based on identified
  3129.           individuals who have been determined to have a need-to-know for the
  3130.           information."
  3131.  
  3132.           DoD Regulation 5200.1-R (Paragraph 7-100) In addition to excerpts
  3133.           already provided that touch on need-to- know, this section of the
  3134.           regulation stresses the need- to-know principle when it states "no
  3135.           person may have access to classified information unless .  .  .  
  3136.           access is necessary for the performance of official duties."[7]
  3137.  
  3138.           Also, DoD Manual 5220.22-M (Section III 20.a) states that "an
  3139.           individual shall be permitted to have access to classified
  3140.           information only . . . when the contractor determines that access
  3141.           is necessary in the performance of tasks or services essential to
  3142.           the fulfillment of a contract or program, i.e., the individual has
  3143.           a need-to-know."[11]
  3144.  
  3145. 7.4  Criteria Control Objective for Accountability
  3146.  
  3147.      The control objective for accountability is: "Systems that are used to
  3148.      process or handle classified or other sensitive information must assure
  3149.      individual accountability whenever either a mandatory or discretionary
  3150.      security policy is invoked.  Furthermore, to assure accountability the
  3151.      capability must exist for an authorized and competent agent to access and
  3152.      evaluate accountability information by a secure means, within a reasonable
  3153.      amount of time, and without undue difficulty."
  3154.  
  3155.      This control objective is supported by the following citations:
  3156.  
  3157.      DoD Directive 5200.28 (VI.A.1) states: "Each user's identity shall be
  3158.      positively established, and his access to the system, and his activity in
  3159.      the system (including material accessed and actions taken) controlled and
  3160.      open to scrutiny."[8]
  3161.  
  3162.      DoD Manual 5200.28-M (Section V 5-100) states: "An audit log or file
  3163.      (manual, machine, or a combination of both) shall be maintained as a 
  3164.      history of the use of the ADP System to permit a regular security review
  3165.      of system activity.  (e.g., The log should record security related 
  3166.      transactions, including each access to a classified file and the nature 
  3167.      of the access, e.g., logins, production of accountable classified 
  3168.      outputs, and creation of new classified files.  Each classified file
  3169.      successfully accessed [regardless of the number of individual references]
  3170.      during each 'job' or 'interactive session' should also be recorded in the
  3171.      audit log.  Much of the material in this log may also be required to 
  3172.      assure that the system preserves information entrusted to it.)"[9]
  3173.  
  3174.      DoD Manual 5200.28-M (Section IV 4-305f) states: "Where needed to assure
  3175.      control of access and individual accountability, each user or specific 
  3176.      group of users shall be identified to the ADP System by appropriate 
  3177.      administrative or hardware/software measures.  Such identification 
  3178.      measures must be in sufficient detail to enable the ADP System to provide
  3179.      the user only that material which he is authorized."[9]
  3180.  
  3181.      DoD Manual 5200.28-M (Section I 1-102b) states: 
  3182.  
  3183.         "Component's Designated Approving Authorities, or their designees
  3184.          for this purpose .  .  .  will assure:
  3185.  
  3186.                  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .
  3187.  
  3188.            (4) Maintenance of documentation on operating systems (O/S)
  3189.            and all modifications thereto, and its retention for a
  3190.            sufficient period of time to enable tracing of security-
  3191.            related defects to their point of origin or inclusion in the
  3192.            system.
  3193.  
  3194.                  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .
  3195.  
  3196.            (6) Establishment of procedures to discover, recover,
  3197.            handle, and dispose of classified material improperly
  3198.            disclosed through system malfunction or personnel action.
  3199.  
  3200.            (7) Proper disposition and correction of security
  3201.            deficiencies in all approved ADP Systems, and the effective
  3202.            use and disposition of system housekeeping or audit records,
  3203.            records of security violations or security-related system
  3204.            malfunctions, and records of tests of the security features
  3205.            of an ADP System."[9]
  3206.  
  3207.      DoD Manual 5220.22-M (Section XIII 111) states: "Audit Trails
  3208.  
  3209.            a. The general security requirement for any ADP system audit
  3210.            trail is that it provide a documented history of the use of
  3211.            the system.  An approved audit trail will permit review of
  3212.            classified system activity and will provide a detailed
  3213.            activity record to facilitate reconstruction of events to
  3214.            determine the magnitude of compromise (if any) should a
  3215.            security malfunction occur.  To fulfill this basic
  3216.            requirement, audit trail systems, manual, automated or a
  3217.            combination of both must document significant events
  3218.            occurring in the following areas of concern: (i) preparation
  3219.            of input data and dissemination of output data (i.e.,
  3220.            reportable interactivity between users and system support
  3221.            personnel), (ii) activity involved within an ADP environment
  3222.            (e.g., ADP support personnel modification of security and
  3223.            related controls), and (iii) internal machine activity.
  3224.  
  3225.            b. The audit trail for an ADP system approved to process
  3226.            classified information must be based on the above three
  3227.            areas and may be stylized to the particular system.  All
  3228.            systems approved for classified processing should contain
  3229.            most if not all of the audit trail records listed below. The
  3230.            contractor's SPP documentation must identify and describe
  3231.            those applicable:
  3232.  
  3233.                       1. Personnel access;
  3234.  
  3235.                       2. Unauthorized and surreptitious entry into the
  3236.            central computer facility or remote terminal areas;
  3237.  
  3238.                       3. Start/stop time of classified processing indicating
  3239.            pertinent systems security initiation and termination events
  3240.            (e.g., upgrading/downgrading actions pursuant to paragraph
  3241.            107);
  3242.  
  3243.                       4. All functions initiated by ADP system console
  3244.            operators;
  3245.  
  3246.                       5. Disconnects of remote terminals and peripheral
  3247.            devices (paragraph 107c);
  3248.  
  3249.                       6. Log-on and log-off user activity;
  3250.  
  3251.                       7. Unauthorized attempts to access files or programs,
  3252.            as well as all open, close, create, and file destroy
  3253.            actions;
  3254.  
  3255.                       8. Program aborts and anomalies including
  3256.            identification information (i.e., user/program name, time
  3257.            and location of incident, etc.);
  3258.  
  3259.                       9. System hardware additions, deletions and maintenance
  3260.            actions;
  3261.  
  3262.                       10. Generations and modifications affecting the
  3263.            security features of the system software.
  3264.  
  3265.            c. The ADP system security supervisor or designee shall
  3266.            review the audit trail logs at least weekly to assure that
  3267.            all pertinent activity is properly recorded and that
  3268.            appropriate action has been taken to correct any anomaly.
  3269.            The majority of ADP systems in use today can develop audit
  3270.            trail systems in accord with the above; however, special
  3271.            systems such as weapons, communications, communications
  3272.            security, and tactical data exchange and display systems,
  3273.            may not be able to comply with all aspects of the above and
  3274.            may require individualized consideration by the cognizant
  3275.            security office.
  3276.  
  3277.            d. Audit trail records shall be retained for a period of one
  3278.            inspection cycle."[11]
  3279.  
  3280. 7.5  Criteria Control Objective for Assurance
  3281.  
  3282.      The control objective for assurance is: "Systems that are used to process
  3283.      or handle classified or other sensitive information must be designed to
  3284.      guarantee correct and accurate interpretation of the security policy and
  3285.      must not distort the intent of that policy.  Assurance must be provided
  3286.      that correct implementation and operation of the policy exists throughout
  3287.      the system's life-cycle."
  3288.  
  3289.      A basis for this objective can be found in the following sections of DoD
  3290.      Directive 5200.28:
  3291.  
  3292.      DoD Directive 5200.28 (IV.B.1) stipulates: "Generally, security of an ADP
  3293.      system is most effective and economical if the system is designed 
  3294.      originally to provide it.  Each Department of Defense Component 
  3295.      undertaking design of an ADP system which is expected to process, store,
  3296.      use, or produce classified material shall:  From the beginning of the 
  3297.      design process, consider the security policies, concepts, and measures
  3298.      prescribed in this Directive."[8]
  3299.  
  3300.      DoD Directive 5200.28 (IV.C.5.a) states: "Provision may be made to permit
  3301.      adjustment of ADP system area controls to the level of protection 
  3302.      required for the classification category and type(s) of material actually
  3303.      being handled by the system, provided change procedures are developed and
  3304.      implemented which will prevent both the unauthorized access to classified
  3305.      material handled by the system and the unauthorized manipulation of the
  3306.      system and its components.  Particular attention shall be given to the
  3307.      continuous protection of automated system security measures, techniques
  3308.      and procedures when the personnel security clearance level of users
  3309.      having access to the system changes."[8]
  3310.  
  3311.      DoD Directive 5200.28 (VI.A.2) states: "Environmental Control.  The ADP
  3312.      System shall be externally protected to minimize the likelihood of
  3313.      unauthorized access to system entry points, access to classified 
  3314.      information in the system, or damage to the system."[8]
  3315.  
  3316.      DoD Manual 5200.28-M (Section I 1-102b) states: 
  3317.  
  3318.         "Component's Designated Approving Authorities, or their designees
  3319.         for this purpose .  .  .  will assure:
  3320.  
  3321.                   .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .
  3322.  
  3323.               (5) Supervision, monitoring, and testing, as appropriate, of
  3324.           changes in an approved ADP System which could affect the
  3325.           security features of the system, so that a secure system is
  3326.           maintained.
  3327.  
  3328.                   .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .
  3329.  
  3330.               (7) Proper disposition and correction of security
  3331.           deficiencies in all approved ADP Systems, and the effective
  3332.           use and disposition of system housekeeping or audit records,
  3333.           records of security violations or security-related system
  3334.           malfunctions, and records of tests of the security features
  3335.           of an ADP System.
  3336.  
  3337.               (8) Conduct of competent system ST&E, timely review of
  3338.           system ST&E reports, and correction of deficiencies needed
  3339.           to support conditional or final approval or disapproval of
  3340.           an ADP System for the processing of classified information.
  3341.  
  3342.               (9) Establishment, where appropriate, of a central ST&E
  3343.           coordination point for the maintenance of records of
  3344.           selected techniques, procedures, standards, and tests used
  3345.           in the testing and evaluation of security features of ADP
  3346.           Systems which may be suitable for validation and use by
  3347.           other Department of Defense Components."[9]
  3348.  
  3349.      DoD Manual 5220.22-M (Section XIII 103a) requires: "the initial approval,
  3350.      in writing, of the cognizant security office prior to processing any
  3351.      classified information in an ADP system.  This section requires 
  3352.      reapproval by the cognizant security office for major system 
  3353.      modifications made subsequent to initial approval.  Reapprovals will be 
  3354.      required because of (i) major changes in personnel access requirements,
  3355.      (ii) relocation or structural modification of the central computer
  3356.      facility, (iii) additions, deletions or changes to main frame, storage or
  3357.      input/output devices, (iv) system software changes impacting security
  3358.      protection features, (v) any change in clearance, declassification, audit
  3359.      trail or hardware/software maintenance procedures, and (vi) other system
  3360.      changes as determined by the cognizant security office."[11]
  3361.  
  3362.      A major component of assurance, life-cycle assurance, is concerned with
  3363.      testing ADP systems both in the development phase as well as during 
  3364.      operation.  DoD Directive 5215.1 (Section F.2.C.(2)) requires 
  3365.      "evaluations of selected industry and government-developed trusted 
  3366.      computer systems against these criteria."[10]
  3367.  
  3368.  
  3369.  
  3370. 8.0  A GUIDELINE ON COVERT CHANNELS
  3371.  
  3372. A covert channel is any communication channel that can be exploited by a
  3373. process to transfer information in a manner that violates the system's
  3374. security policy.  There are two types of covert channels: storage channels and
  3375. timing channels.  Covert storage channels include all vehicles that would
  3376. allow the direct or indirect writing of a storage location by one process and
  3377. the direct or indirect reading of it by another.  Covert timing channels
  3378. include all vehicles that would allow one process to signal information to
  3379. another process by modulating its own use of system resources in such a way
  3380. that the change in response time observed by the second process would provide
  3381. information.
  3382.  
  3383. From a security perspective, covert channels with low bandwidths represent a
  3384. lower threat than those with high bandwidths.  However, for many types of
  3385. covert channels, techniques used to reduce the bandwidth below a certain rate
  3386. (which depends on the specific channel mechanism and the system architecture)
  3387. also have the effect of degrading the performance provided to legitimate
  3388. system users.  Hence, a trade-off between system performance and covert
  3389. channel bandwidth must be made.  Because of the threat of compromise that
  3390. would be present in any multilevel computer system containing classified or
  3391. sensitive information, such systems should not contain covert channels with
  3392. high bandwidths.  This guideline is intended to provide system developers with
  3393. an idea of just how high a "high" covert channel bandwidth is.
  3394.  
  3395. A covert channel bandwidth that exceeds a rate of one hundred (100) bits per
  3396. second is considered "high" because 100 bits per second is the approximate
  3397. rate at which many computer terminals are run.  It does not seem appropriate
  3398. to call a computer system "secure" if information can be compromised at a rate
  3399. equal to the normal output rate of some commonly used device.
  3400.  
  3401. In any multilevel computer system there are a number of relatively
  3402. low-bandwidth covert channels whose existence is deeply ingrained in the
  3403. system design.  Faced with the large potential cost of reducing the bandwidths
  3404. of such covert channels, it is felt that those with maximum bandwidths of less
  3405. than one (1) bit per second are acceptable in most application environments.
  3406. Though maintaining acceptable performance in some systems may make it
  3407. impractical to eliminate all covert channels with bandwidths of 1 or more bits
  3408. per second, it is possible to audit their use without adversely affecting
  3409. system performance.  This audit capability provides the system administration
  3410. with a means of detecting -- and procedurally correcting -- significant
  3411. compromise.  Therefore, a Trusted Computing Base should provide, wherever
  3412. possible, the capability to audit the use of covert channel mechanisms with
  3413. bandwidths that may exceed a rate of one (1) bit in ten (10) seconds.
  3414.  
  3415. The covert channel problem has been addressed by a number of authors.  The
  3416. interested reader is referred to references [5], [6], [19], [21], [22], [23],
  3417. and [29].
  3418.  
  3419.  
  3420.  
  3421. 9.0  A GUIDELINE ON CONFIGURING MANDATORY ACCESS CONTROL FEATURES
  3422.  
  3423. The Mandatory Access Control requirement includes a capability to support an
  3424. unspecified number of hierarchical classifications and an unspecified number
  3425. of non-hierarchical categories at each hierarchical level.  To encourage
  3426. consistency and portability in the design and development of the National
  3427. Security Establishment trusted computer systems, it is desirable for all such
  3428. systems to be able to support a minimum number of levels and categories.  The
  3429. following suggestions are provided for this purpose:
  3430.  
  3431.      * The number of hierarchical classifications should be greater than or
  3432.        equal to eight (8).
  3433.  
  3434.      * The number of non-hierarchical categories should be greater than or
  3435.        equal to twenty-nine (29).
  3436.  
  3437.  
  3438.  
  3439. 10.0  A GUIDELINE ON SECURITY TESTING
  3440.  
  3441. These guidelines are provided to give an indication of the extent and
  3442. sophistication of testing undertaken by the DoD Computer Security Center
  3443. during the Formal Product Evaluation process.  Organizations wishing to use
  3444. "Department of Defense Trusted Computer System Evaluation Criteria" for
  3445. performing their own evaluations may find this section useful for planning
  3446. purposes.
  3447.  
  3448. As in Part I, highlighting is used to indicate changes in the guidelines from
  3449. the next lower division.
  3450.  
  3451. 10.1  Testing for Division C
  3452.  
  3453.      10.1.1   Personnel
  3454.  
  3455.             The security testing team shall consist of at least two
  3456.             individuals with bachelor degrees in Computer Science or the
  3457.             equivalent.  Team members shall be able to follow test plans
  3458.             prepared by the system developer and suggest additions, shall
  3459.             be familiar with the "flaw hypothesis" or equivalent security
  3460.             testing methodology, and shall have assembly level programming
  3461.             experience.  Before testing begins, the team members shall have
  3462.             functional knowledge of, and shall have completed the system 
  3463.             developer's internals course for, the system being evaluated.
  3464.  
  3465.      10.1.2   Testing
  3466.  
  3467.             The team shall have "hands-on" involvement in an independent run
  3468.             of the tests used by the system developer.  The team shall 
  3469.             independently design and implement at least five system-specific
  3470.             tests in an attempt to circumvent the security mechanisms of the
  3471.             system.  The elapsed time devoted to testing shall be at least
  3472.             one month and need not exceed three months.  There shall be no
  3473.             fewer than twenty hands-on hours spent carrying out system
  3474.             developer-defined tests and test team-defined tests.
  3475.  
  3476. 10.2  Testing for Division B
  3477.  
  3478.      10.2.1   Personnel
  3479.  
  3480.             The security testing team shall consist of at least two
  3481.             individuals with bachelor degrees in Computer Science or the 
  3482.             equivalent and at least one individual with a master's degree in
  3483.             Computer Science or equivalent.  Team members shall be able to
  3484.             follow test plans prepared by the system developer and suggest
  3485.             additions, shall be conversant with the "flaw hypothesis" or
  3486.             equivalent security testing methodology, shall be fluent in the
  3487.             TCB implementation language(s), and shall have assembly level 
  3488.             programming experience.  Before testing begins, the team members
  3489.             shall have functional knowledge of, and shall have completed the
  3490.             system developer's internals course for, the system being
  3491.             evaluated.  At least one team member shall have previously
  3492.             completed a security test on another system.
  3493.  
  3494.      10.2.2   Testing
  3495.  
  3496.             The team shall have "hands-on" involvement in an independent run
  3497.             of the test package used by the system developer to test 
  3498.             security-relevant hardware and software.  The team shall
  3499.             independently design and implement at least fifteen system-
  3500.             specific tests in an attempt to circumvent the security
  3501.             mechanisms of the system.  The elapsed time devoted to testing 
  3502.             shall be at least two months and need not exceed four months.  
  3503.             There shall be no fewer than thirty hands-on hours per team
  3504.             member spent carrying out system developer-defined tests and
  3505.             test team-defined tests.
  3506.  
  3507. 10.3  Testing for Division A
  3508.  
  3509.      10.3.1   Personnel
  3510.  
  3511.             The security testing team shall consist of at least one
  3512.             individual with a bachelor's degree in Computer Science or the 
  3513.             equivalent and at least two individuals with masters' degrees in
  3514.             Computer Science or equivalent.  Team members shall be able to 
  3515.             follow test plans prepared by the system developer and suggest
  3516.             additions, shall be conversant with the "flaw hypothesis" or
  3517.             equivalent security testing methodology, shall be fluent in the
  3518.             TCB implementation language(s), and shall have assembly level 
  3519.             programming experience.  Before testing begins, the team members
  3520.             shall have functional knowledge of, and shall have completed the
  3521.             system developer's internals course for, the system being
  3522.             evaluated.  At least one team member shall be familiar enough
  3523.             with the system hardware to understand the maintenance diagnostic
  3524.             programs and supporting hardware documentation.  At least two 
  3525.             team members shall have previously completed a security test on
  3526.             another system.  At least one team member shall have 
  3527.             demonstrated system level programming competence on the system
  3528.             under test to a level of complexity equivalent to adding a device
  3529.             driver to the system.
  3530.  
  3531.      10.3.2   Testing
  3532.  
  3533.             The team shall have "hands-on" involvement in an independent run
  3534.             of the test package used by the system developer to test 
  3535.             security-relevant hardware and software.  The team shall 
  3536.             independently design and implement at least twenty-five system-
  3537.             specific tests in an attempt to circumvent the security
  3538.             mechanisms of the system.  The elapsed time devoted to testing 
  3539.             shall be at least three months and need not exceed six months.  
  3540.             There shall be no fewer than fifty hands-on hours per team 
  3541.             member spent carrying out system developer-defined tests and
  3542.             test team-defined tests.
  3543.  
  3544.  
  3545.  
  3546.  
  3547.                                     APPENDIX A
  3548.  
  3549.                      Commercial Product Evaluation Process
  3550.  
  3551.  
  3552. "Department of Defense Trusted Computer System Evaluation Criteria" forms the
  3553. basis upon which the Computer Security Center will carry out the commercial
  3554. computer security evaluation process.  This process is focused on commercially
  3555. produced and supported general-purpose operating system products that meet the
  3556. needs of government departments and agencies.  The formal evaluation is aimed
  3557. at "off-the-shelf" commercially supported products and is completely divorced
  3558. from any consideration of overall system performance, potential applications,
  3559. or particular processing environments.  The evaluation provides a key input to
  3560. a computer system security approval/accreditation.  However, it does not
  3561. constitute a complete computer system security evaluation.  A complete study
  3562. (e.g., as in reference [18]) must consider additional factors dealing with the
  3563. system in its unique environment, such as it's proposed security mode of
  3564. operation, specific users, applications, data sensitivity, physical and
  3565. personnel security, administrative and procedural security, TEMPEST, and
  3566. communications security.
  3567.  
  3568. The product evaluation process carried out by the Computer Security Center has
  3569. three distinct elements:
  3570.  
  3571.      * Preliminary Product Evaluation - An informal dialogue between a vendor
  3572.        and the Center in which technical information is exchanged to create a
  3573.        common understanding of the vendor's product, the criteria, and the 
  3574.        rating that may be expected to result from a formal product evaluation.
  3575.  
  3576.      * Formal Product Evaluation - A formal evaluation, by the Center, of a
  3577.        product that is available to the DoD, and that results in that product
  3578.        and its assigned rating being placed on the Evaluated Products List.
  3579.  
  3580.      * Evaluated Products List - A list of products that have been subjected
  3581.        to formal product evaluation and their assigned ratings.
  3582.  
  3583.  
  3584. PRELIMINARY PRODUCT EVALUATION
  3585.  
  3586. Since it is generally very difficult to add effective security measures late
  3587. in a product's life cycle, the Center is interested in working with system
  3588. vendors in the early stages of product design.  A preliminary product
  3589. evaluation allows the Center to consult with computer vendors on computer
  3590. security issues found in products that have not yet been formally announced.
  3591.  
  3592. A preliminary evaluation is typically initiated by computer system vendors who
  3593. are planning new computer products that feature security or major
  3594. security-related upgrades to existing products.  After an initial meeting
  3595. between the vendor and the Center, appropriate non-disclosure agreements are
  3596. executed that require the Center to maintain the confidentiality of any
  3597. proprietary information disclosed to it.  Technical exchange meetings follow
  3598. in which the vendor provides details about the proposed product (particularly
  3599. its internal designs and goals) and the Center provides expert feedback to the
  3600. vendor on potential computer security strengths and weaknesses of the vendor's
  3601. design choices, as well as relevant interpretation of the criteria.  The
  3602. preliminary evaluation is typically terminated when the product is completed
  3603. and ready for field release by the vendor.  Upon termination, the Center
  3604. prepares a wrap-up report for the vendor and for internal distribution within
  3605. the Center.  Those reports containing proprietary information are not
  3606. available to the public.
  3607.  
  3608. During preliminary evaluation, the vendor is under no obligation to actually
  3609. complete or market the potential product.  The Center is, likewise, not
  3610. committed to conduct a formal product evaluation.  A preliminary evaluation
  3611. may be terminated by either the Center or the vendor when one notifies the
  3612. other, in writing, that it is no longer advantageous to continue the
  3613. evaluation.
  3614.  
  3615.  
  3616. FORMAL PRODUCT EVALUATION
  3617.  
  3618. The formal product evaluation provides a key input to certification of a
  3619. computer system for use in National Security Establishment applications and is
  3620. the sole basis for a product being placed on the Evaluated Products List.
  3621.  
  3622. A formal product evaluation begins with a request by a vendor for the Center
  3623. to evaluate a product for which the product itself and accompanying
  3624. documentation needed to meet the requirements defined by this publication are
  3625. complete.  Non-disclosure agreements are executed and a formal product
  3626. evaluation team is formed by the Center.  An initial meeting is then held with
  3627. the vendor to work out the schedule for the formal evaluation.  Since testing
  3628. of the implemented product forms an important part of the evaluation process,
  3629. access by the evaluation team to a working version of the system is negotiated
  3630. with the vendor.  Additional support required from the vendor includes
  3631. complete design documentation, source code, and access to vendor personnel who
  3632. can answer detailed questions about specific portions of the product.  The
  3633. evaluation team tests the product against each requirement, making any
  3634. necessary interpretations of the criteria with respect to the product being
  3635. evaluated.
  3636.  
  3637. The evaluation team writes a two-part final report on their findings about the
  3638. system.  The first part is publicly available (containing no proprietary
  3639. information) and contains the overall class rating assigned to the system and
  3640. the details of the evaluation team's findings when comparing the product
  3641. against the evaluation criteria.  The second part of the evaluation report
  3642. contains vulnerability analyses and other detailed information supporting the
  3643. rating decision.  Since this part may contain proprietary or other sensitive
  3644. information it will be distributed only within the U.S.  Government on a
  3645. strict need-to-know and non- disclosure basis, and to the vendor.  No portion
  3646. of the evaluation results will be withheld from the vendor.
  3647.  
  3648.  
  3649.  
  3650.  
  3651.  
  3652.  
  3653.  
  3654.                                    APPENDIX B
  3655.  
  3656.                    Summary of Evaluation Criteria Divisions
  3657.  
  3658. The divisions of systems recognized under the trusted computer system
  3659. evaluation criteria are as follows.  Each division represents a major
  3660. improvement in the overall confidence one can place in the system to protect
  3661. classified and other sensitive information.
  3662.  
  3663. Division (D):  Minimal Protection
  3664.  
  3665. This division contains only one class.  It is reserved for those systems that
  3666. have been evaluated but that fail to meet the requirements for a higher
  3667. evaluation class.
  3668.  
  3669. Division (C):  Discretionary Protection
  3670.  
  3671. Classes in this division provide for discretionary (need-to-know) protection
  3672. and, through the inclusion of audit capabilities, for accountability of
  3673. subjects and the actions they initiate.
  3674.  
  3675. Division (B):  Mandatory Protection
  3676.  
  3677. The notion of a TCB that preserves the integrity of sensitivity labels and
  3678. uses them to enforce a set of mandatory access control rules is a major
  3679. requirement in this division.  Systems in this division must carry the
  3680. sensitivity labels with major data structures in the system.  The system
  3681. developer also provides the security policy model on which the TCB is based
  3682. and furnishes a specification of the TCB.  Evidence must be provided to
  3683. demonstrate that the reference monitor concept has been implemented.
  3684.  
  3685. Division (A):  Verified Protection
  3686.  
  3687. This division is characterized by the use of formal security verification
  3688. methods to assure that the mandatory and discretionary security controls
  3689. employed in the system can effectively protect classified or other sensitive
  3690. information stored or processed by the system.  Extensive documentation is
  3691. required to demonstrate that the TCB meets the security requirements in all
  3692. aspects of design, development and implementation.
  3693.  
  3694.  
  3695.  
  3696.  
  3697.  
  3698.                                    APPENDIX C
  3699.  
  3700.                     Summary of Evaluation Criteria Classes
  3701.  
  3702. The classes of systems recognized under the trusted computer system evaluation
  3703. criteria are as follows.  They are presented in the order of increasing
  3704. desirablity from a computer security point of view.
  3705.  
  3706. Class (D):  Minimal Protection
  3707.  
  3708. This class is reserved for those systems that have been evaluated but that
  3709. fail to meet the requirements for a higher evaluation class.
  3710.  
  3711. Class (C1):  Discretionary Security Protection
  3712.  
  3713. The Trusted Computing Base (TCB) of a class (C1) system nominally satisfies
  3714. the discretionary security requirements by providing separation of users and
  3715. data.  It incorporates some form of credible controls capable of enforcing
  3716. access limitations on an individual basis, i.e., ostensibly suitable for
  3717. allowing users to be able to protect project or private information and to
  3718. keep other users from accidentally reading or destroying their data.  The
  3719. class (C1) environment is expected to be one of cooperating users processing
  3720. data at the same level(s) of sensitivity.
  3721.  
  3722. Class (C2):  Controlled Access Protection
  3723.  
  3724. Systems in this class enforce a more finely grained discretionary access
  3725. control than (C1) systems, making users individually accountable for their
  3726. actions through login procedures, auditing of security-relevant events, and
  3727. resource isolation.
  3728.  
  3729. Class (B1):  Labeled Security Protection
  3730.  
  3731. Class (B1) systems require all the features required for class (C2).  In
  3732. addition, an informal statement of the security policy model, data labeling,
  3733. and mandatory access control over named subjects and objects must be present.
  3734. The capability must exist for accurately labeling exported information.  Any
  3735. flaws identified by testing must be removed.
  3736.  
  3737. Class (B2):  Structured Protection
  3738.  
  3739. In class (B2) systems, the TCB is based on a clearly defined and documented
  3740. formal security policy model that requires the discretionary and mandatory
  3741. access control enforcement found in class (B1) systems be extended to all
  3742. subjects and objects in the ADP system.  In addition, covert channels are
  3743. addressed.  The TCB must be carefully structured into protection-critical and
  3744. non- protection-critical elements.  The TCB interface is well-defined and the
  3745. TCB design and implementation enable it to be subjected to more thorough
  3746. testing and more complete review.  Authentication mechanisms are strengthened,
  3747. trusted facility management is provided in the form of support for system
  3748. administrator and operator functions, and stringent configuration management
  3749. controls are imposed.  The system is relatively resistant to penetration.
  3750.  
  3751. Class (B3):  Security Domains
  3752.  
  3753. The class (B3) TCB must satisfy the reference monitor requirements that it
  3754. mediate all accesses of subjects to objects, be tamperproof, and be small
  3755. enough to be subjected to analysis and tests.  To this end, the TCB is
  3756. structured to exclude code not essential to security policy enforcement, with
  3757. significant system engineering during TCB design and implementation directed
  3758. toward minimizing its complexity.  A security administrator is supported,
  3759. audit mechanisms are expanded to signal security- relevant events, and system
  3760. recovery procedures are required.  The system is highly resistant to
  3761. penetration.
  3762.  
  3763. Class (A1):  Verified Design
  3764.  
  3765. Systems in class (A1) are functionally equivalent to those in class (B3) in
  3766. that no additional architectural features or policy requirements are added.
  3767. The distinguishing feature of systems in this class is the analysis derived
  3768. from formal design specification and verification techniques and the resulting
  3769. high degree of assurance that the TCB is correctly implemented.  This
  3770. assurance is developmental in nature, starting with a formal model of the
  3771. security policy and a formal top-level specification (FTLS) of the design.  In
  3772. keeping with the extensive design and development analysis of the TCB required
  3773. of systems in class (A1), more stringent configuration management is required
  3774. and procedures are established for securely distributing the system to sites.
  3775. A system security administrator is supported.
  3776.  
  3777.  
  3778.  
  3779.  
  3780.  
  3781.                                    APPENDIX D
  3782.  
  3783.                               Requirement Directory
  3784.  
  3785. This appendix lists requirements defined in "Department of Defense Trusted
  3786. Computer System Evaluation Criteria" alphabetically rather than by class.  It
  3787. is provided to assist in following the evolution of a requirement through the
  3788. classes.  For each requirement, three types of criteria may be present.  Each
  3789. will be preceded by the word: NEW, CHANGE, or ADD to indicate the following:
  3790.  
  3791.               NEW: Any criteria appearing in a lower class are superseded
  3792.                    by the criteria that follow.
  3793.  
  3794.            CHANGE: The criteria that follow have appeared in a lower class
  3795.                    but are changed for this class.  Highlighting is used
  3796.                    to indicate the specific changes to previously stated
  3797.                    criteria.
  3798.  
  3799.               ADD: The criteria that follow have not been required for any
  3800.                    lower class, and are added in this class to the
  3801.                    previously stated criteria for this requirement.
  3802.  
  3803. Abbreviations are used as follows:
  3804.  
  3805.                NR: (No Requirement) This requirement is not included in
  3806.                    this class.
  3807.  
  3808.               NAR: (No Additional Requirements) This requirement does not
  3809.                    change from the previous class.
  3810.  
  3811. The reader is referred to Part I of this document when placing new criteria
  3812. for a requirement into the complete context for that class.
  3813.  
  3814. Figure 1 provides a pictorial summary of the evolution of requirements through
  3815. the classes.
  3816.  
  3817.  
  3818. Audit
  3819.  
  3820.      C1: NR.
  3821.  
  3822.      C2: NEW: The TCB shall be able to create, maintain, and protect from
  3823.          modification or unauthorized access or destruction an audit trail of
  3824.          accesses to the objects it protects.  The audit data shall be 
  3825.          protected by the TCB so that read access to it is limited to those 
  3826.          who are authorized for audit data.  The TCB shall be able to record
  3827.          the following types of events:  use of identification and
  3828.          authentication mechanisms, introduction of objects into a user's
  3829.          address space (e.g., file open, program initiation), deletion of
  3830.          objects, and actions taken by computer operators and system 
  3831.          administrators and/or system security officers.  For each recorded 
  3832.          event, the audit record shall identify: date and time of the event,
  3833.          user, type of event, and success or failure of the event.  For
  3834.          identification/authentication events the origin of request (e.g.,
  3835.          terminal ID) shall be included in the audit record.  For events that
  3836.          introduce an object into a user's address space and for object
  3837.          deletion events the audit record shall include the name of the object.
  3838.          The ADP system administrator shall be able to selectively audit the 
  3839.          actions of any one or more users based on individual identity.
  3840.  
  3841.      B1: CHANGE: For events that introduce an object into a user's address
  3842.          space and for object deletion events the audit record shall include
  3843.          the name of the object and the object's security level.  The ADP 
  3844.          system administrator shall be able to selectively audit the actions 
  3845.          of any one or more users based on individual identity and/or object
  3846.          security level.
  3847.  
  3848.          ADD: The TCB shall also be able to audit any override of
  3849.          human-readable output markings.
  3850.  
  3851.      B2: ADD: The TCB shall be able to audit the identified events that may be
  3852.          used in the exploitation of covert storage channels.
  3853.  
  3854.      B3: ADD: The TCB shall contain a mechanism that is able to monitor the
  3855.          occurrence or accumulation of security auditable events that may 
  3856.          indicate an imminent violation of security policy.  This mechanism 
  3857.          shall be able to immediately notify the security administrator when
  3858.          thresholds are exceeded.
  3859.  
  3860.      A1: NAR.
  3861.  
  3862. Configuration Management
  3863.  
  3864.      C1: NR.
  3865.  
  3866.      C2: NR.
  3867.  
  3868.      B1: NR.
  3869.  
  3870.      B2: NEW: During development and maintenance of the TCB, a configuration
  3871.          management system shall be in place that maintains control of changes
  3872.          to the descriptive top-level specification, other design data, 
  3873.          implementation documentation, source code, the running version of the
  3874.          object code, and test fixtures and documentation.  The configuration
  3875.          management system shall assure a consistent mapping among all
  3876.          documentation and code associated with the current version of the TCB.
  3877.          Tools shall be provided for generation of a new version of the TCB
  3878.          from source code.  Also available shall be tools for comparing a 
  3879.          newly generated version with the previous TCB version in order to
  3880.          ascertain that only the intended changes have been made in the code 
  3881.          that will actually be used as the new version of the TCB.
  3882.  
  3883.      B3: NAR.
  3884.  
  3885.      A1: CHANGE: During the entire life-cycle, i.e., during the design,
  3886.          development, and maintenance of the TCB, a configuration management
  3887.          system shall be in place for all security-relevant hardware, firmware,
  3888.          and software that maintains control of changes to the formal model, 
  3889.          the descriptive and formal top-level specifications, other design
  3890.          data, implementation documentation, source code, the running version
  3891.          of the object code, and test fixtures and documentation.  Also
  3892.          available shall be tools, maintained under strict configuration
  3893.          control, for comparing a newly generated version with the previous
  3894.          TCB version in order to ascertain that only the intended changes have
  3895.          been made in the code that will actually be used as the new version 
  3896.          of the TCB.
  3897.  
  3898.     ADD: A combination of technical, physical, and procedural safeguards
  3899.          shall be used to protect from unauthorized modification or 
  3900.          destruction the master copy or copies of all material used to 
  3901.          generate the TCB.
  3902.  
  3903. Covert Channel Analysis
  3904.  
  3905.      C1: NR.
  3906.  
  3907.      C2: NR.
  3908.  
  3909.      B1: NR.
  3910.  
  3911.      B2: NEW: The system developer shall conduct a thorough search for covert
  3912.          storage channels and make a determination (either by actual 
  3913.          measurement or by engineering estimation) of the maximum bandwidth of
  3914.          each identified channel.  (See the Covert Channels Guideline section.)
  3915.  
  3916.      B3: CHANGE: The system developer shall conduct a thorough search for
  3917.          covert channels and make a determination (either by actual 
  3918.          measurement or by engineering estimation) of the maximum bandwidth 
  3919.          of each identified channel.
  3920.  
  3921.      A1: ADD: Formal methods shall be used in the analysis.
  3922.  
  3923. Design Documentation
  3924.  
  3925.      C1: NEW: Documentation shall be available that provides a description of
  3926.          the manufacturer's philosophy of protection and an explanation of how
  3927.          this philosophy is translated into the TCB.  If the TCB is composed 
  3928.          of distinct modules, the interfaces between these modules shall be 
  3929.          described.
  3930.  
  3931.      C2: NAR.
  3932.  
  3933.      B1: ADD: An informal or formal description of the security policy model
  3934.          enforced by the TCB shall be available and an explanation provided to
  3935.          show that it is sufficient to enforce the security policy.  The 
  3936.          specific TCB protection mechanisms shall be identified and an 
  3937.          explanation given to show that they satisfy the model.
  3938.  
  3939.      B2: CHANGE: The interfaces between the TCB modules shall be described.  A
  3940.          formal description of the security policy model enforced by the TCB 
  3941.          shall be available and proven that it is sufficient to enforce the 
  3942.          security policy.
  3943.  
  3944.          ADD: The descriptive top-level specification (DTLS) shall be shown to
  3945.          be an accurate description of the TCB interface.  Documentation shall
  3946.          describe how the TCB implements the reference monitor concept and 
  3947.          give an explanation why it is tamperproof, cannot be bypassed, and is
  3948.          correctly implemented.  Documentation shall describe how the TCB is 
  3949.          structured to facilitate testing and to enforce least privilege.
  3950.          This documentation shall also present the results of the covert
  3951.          channel analysis and the tradeoffs involved in restricting the
  3952.          channels.  All auditable events that may be used in the exploitation
  3953.          of known covert storage channels shall be identified.  The bandwidths
  3954.          of known covert storage channels, the use of which is not detectable
  3955.          by the auditing mechanisms, shall be provided.  (See the Covert 
  3956.          Channel Guideline section.)
  3957.  
  3958.      B3: ADD: The TCB implementation (i.e., in hardware, firmware, and
  3959.          software) shall be informally shown to be consistent with the DTLS.
  3960.          The elements of the DTLS shall be shown, using informal techniques, 
  3961.          to correspond to the elements of the TCB.
  3962.  
  3963.      A1: CHANGE: The TCB implementation (i.e., in hardware, firmware, and
  3964.          software) shall be informally shown to be consistent with the formal
  3965.          top-level specification (FTLS).  The elements of the FTLS shall be 
  3966.          shown, using informal techniques, to correspond to the elements of 
  3967.          the TCB.
  3968.  
  3969.          ADD: Hardware, firmware, and software mechanisms not dealt with in
  3970.          the FTLS but strictly internal to the TCB (e.g., mapping registers,
  3971.          direct memory access I/O) shall be clearly described.
  3972.  
  3973. Design Specification and Verification
  3974.  
  3975.      C1: NR.
  3976.  
  3977.      C2: NR.
  3978.  
  3979.      B1: NEW: An informal or formal model of the security policy supported by
  3980.          the TCB shall be maintained that is shown to be consistent with its 
  3981.          axioms.
  3982.  
  3983.      B2: CHANGE: A formal model of the security policy supported by the TCB
  3984.          shall be maintained that is proven consistent with its axioms.
  3985.  
  3986.          ADD: A descriptive top-level specification (DTLS) of the TCB shall be
  3987.          maintained that completely and accurately describes the TCB in terms
  3988.          of exceptions, error messages, and effects.  It shall be shown to be
  3989.          an accurate description of the TCB interface.
  3990.  
  3991.      B3: ADD: A convincing argument shall be given that the DTLS is consistent
  3992.          with the model.
  3993.  
  3994.      A1: CHANGE: The FTLS shall be shown to be an accurate description of the
  3995.          TCB interface.  A convincing argument shall be given that the DTLS is
  3996.          consistent with the model and a combination of formal and informal 
  3997.          techniques shall be used to show that the FTLS is consistent with the
  3998.          model.
  3999.  
  4000.          ADD: A formal top-level specification (FTLS) of the TCB shall be
  4001.          maintained that accurately describes the TCB in terms of exceptions,
  4002.          error messages, and effects.  The DTLS and FTLS shall include those
  4003.          components of the TCB that are implemented as hardware and/or 
  4004.          firmware if their properties are visible at the TCB interface.  This
  4005.          verification evidence shall be consistent with that provided within
  4006.          the state-of-the-art of the particular Computer Security Center-
  4007.          endorsed formal specification and verification system used.  Manual
  4008.          or other mapping of the FTLS to the TCB source code shall be
  4009.          performed to provide evidence of correct implementation.
  4010.  
  4011. Device Labels
  4012.  
  4013.      C1: NR.
  4014.  
  4015.      C2: NR.
  4016.  
  4017.      B1: NR.
  4018.  
  4019.      B2: NEW: The TCB shall support the assignment of minimum and maximum
  4020.          security levels to all attached physical devices.  These security
  4021.          levels shall be used by the TCB to enforce constraints imposed by 
  4022.          the physical environments in which the devices are located.
  4023.  
  4024.      B3: NAR.
  4025.  
  4026.      A1: NAR.
  4027.  
  4028. Discretionary Access Control
  4029.  
  4030.      C1: NEW: The TCB shall define and control access between named users and
  4031.          named objects (e.g., files and programs) in the ADP system.  The 
  4032.          enforcement mechanism (e.g., self/group/public controls, access 
  4033.          control lists) shall allow users to specify and control sharing of
  4034.          those objects by named individuals or defined groups or both.
  4035.  
  4036.      C2: CHANGE: The enforcement mechanism (e.g., self/group/public controls,
  4037.          access control lists) shall allow users to specify and control 
  4038.          sharing of those objects by named individuals, or defined groups of
  4039.          individuals, or by both.
  4040.  
  4041.     ADD: The discretionary access control mechanism shall, either by explicit
  4042.          user action or by default, provide that objects are protected from
  4043.          unauthorized access.  These access controls shall be capable of 
  4044.          including or excluding access to the granularity of a single user.  
  4045.          Access permission to an object by users not already possessing access
  4046.          permission shall only be assigned by authorized users.
  4047.  
  4048.      B1: NAR.
  4049.  
  4050.      B2: NAR.
  4051.  
  4052.      B3: CHANGE: The enforcement mechanism (e.g., access control lists) shall
  4053.          allow users to specify and control sharing of those objects.  These 
  4054.          access controls shall be capable of specifying, for each named 
  4055.          object, a list of named individuals and a list of groups of named 
  4056.          individuals with their respective modes of access to that object.
  4057.  
  4058.     ADD: Furthermore, for each such named object, it shall be possible to
  4059.          specify a list of named individuals and a list of groups of named 
  4060.          individuals for which no access to the object is to be given.
  4061.  
  4062.      A1: NAR.
  4063.  
  4064. Exportation of Labeled Information
  4065.  
  4066.      C1: NR.
  4067.  
  4068.      C2: NR.
  4069.  
  4070.      B1: NEW: The TCB shall designate each communication channel and I/O
  4071.          device as either single-level or multilevel.  Any change in this 
  4072.          designation shall be done manually and shall be auditable by the 
  4073.          TCB.  The TCB shall maintain and be able to audit any change in the
  4074.          current security level associated with a single-level communication
  4075.          channel or I/O device.
  4076.  
  4077.      B2: NAR.
  4078.  
  4079.      B3: NAR.
  4080.  
  4081.      A1: NAR.
  4082.  
  4083. Exportation to Multilevel Devices
  4084.  
  4085.      C1: NR.
  4086.  
  4087.      C2: NR.
  4088.  
  4089.      B1: NEW: When the TCB exports an object to a multilevel I/O device, the
  4090.          sensitivity label associated with that object shall also be exported
  4091.          and shall reside on the same physical medium as the exported 
  4092.          information and shall be in the same form (i.e., machine-readable or
  4093.          human-readable form).  When the TCB exports or imports an object over
  4094.          a multilevel communication channel, the protocol used on that channel
  4095.          shall provide for the unambiguous pairing between the sensitivity
  4096.          labels and the associated information that is sent or received.
  4097.  
  4098.      B2: NAR.
  4099.  
  4100.      B3: NAR.
  4101.  
  4102.      A1: NAR.
  4103.  
  4104. Exportation to Single-Level Devices
  4105.  
  4106.      C1: NR.
  4107.  
  4108.      C2: NR.
  4109.  
  4110.      B1: NEW: Single-level I/O devices and single-level communication channels
  4111.          are not required to maintain the sensitivity labels of the 
  4112.          information they process.  However, the TCB shall include a mechanism
  4113.          by which the TCB and an authorized user reliably communicate to
  4114.          designate the single security level of information imported or 
  4115.          exported via single-level communication channels or I/O devices.
  4116.  
  4117.      B2: NAR.
  4118.  
  4119.      B3: NAR.
  4120.  
  4121.      A1: NAR.
  4122.  
  4123. Identification and Authentication
  4124.  
  4125.      C1: NEW: The TCB shall require users to identify themselves to it before
  4126.          beginning to perform any other actions that the TCB is expected to 
  4127.          mediate.  Furthermore, the TCB shall use a protected mechanism (e.g.,
  4128.          passwords) to authenticate the user's identity.  The TCB shall 
  4129.          protect authentication data so that it cannot be accessed by any 
  4130.          unauthorized user.
  4131.  
  4132.      C2: ADD: The TCB shall be able to enforce individual accountability by
  4133.          providing the capability to uniquely identify each individual ADP 
  4134.          system user.  The TCB shall also provide the capability of 
  4135.          associating this identity with all auditable actions taken by that 
  4136.          individual.
  4137.  
  4138.      B1: CHANGE: Furthermore, the TCB shall maintain authentication data that
  4139.          includes information for verifying the identity of individual users
  4140.          (e.g., passwords) as well as information for determining the 
  4141.          clearance and authorizations of individual users.  This data shall be
  4142.          used by the TCB to authenticate the user's identity and to determine 
  4143.          the security level and authorizations of subjects that may be created
  4144.          to act on behalf of the individual user.
  4145.  
  4146.      B2: NAR.
  4147.  
  4148.      B3: NAR.
  4149.  
  4150.      A1: NAR.
  4151.  
  4152. Label Integrity
  4153.  
  4154.      C1: NR.
  4155.  
  4156.      C2: NR.
  4157.  
  4158.      B1: NEW: Sensitivity labels shall accurately represent security levels of
  4159.          the specific subjects or objects with which they are associated.  When
  4160.          exported by the TCB, sensitivity labels shall accurately and 
  4161.          unambiguously represent the internal labels and shall be associated 
  4162.          with the information being exported.
  4163.  
  4164.      B2: NAR.
  4165.  
  4166.      B3: NAR.
  4167.  
  4168.      A1: NAR.
  4169.  
  4170. Labeling Human-Readable Output
  4171.  
  4172.      C1: NR.
  4173.  
  4174.      C2: NR.
  4175.  
  4176.      B1: NEW: The ADP system administrator shall be able to specify the
  4177.          printable label names associated with exported sensitivity labels.
  4178.          The TCB shall mark the beginning and end of all human-readable, 
  4179.          paged, hardcopy output (e.g., line printer output) with human-
  4180.          readable sensitivity labels that properly* represent the sensitivity
  4181.          of the output.  The TCB shall, by default, mark the top and bottom of
  4182.          each page of human-readable, paged, hardcopy output (e.g., line
  4183.          printer output) with human-readable sensitivity labels that
  4184.          properly* represent the overall sensitivity of the output or that 
  4185.          properly* represent the sensitivity of the information on the page.
  4186.          The TCB shall, by default and in an appropriate manner, mark other 
  4187.          forms of human-readable output (e.g., maps, graphics) with human-
  4188.          readable sensitivity labels that properly* represent the sensitivity
  4189.          of the output.  Any override of these marking defaults shall be
  4190.          auditable by the TCB.
  4191.  
  4192.      B2: NAR.
  4193.  
  4194.      B3: NAR.
  4195.  
  4196.      A1: NAR.
  4197.  
  4198.            ____________________________________________________________
  4199.            * The hierarchical classification component in human-readable
  4200.            sensitivity labels shall be equal to the greatest
  4201.            hierarchical classification of any of the information in the
  4202.            output that the labels refer to;  the non-hierarchical
  4203.            category component shall include all of the non-hierarchical
  4204.            categories of the information in the output the labels refer
  4205.            to, but no other non-hierarchical categories.
  4206.            ____________________________________________________________
  4207.  
  4208.  
  4209. Labels
  4210.  
  4211.      C1: NR.
  4212.  
  4213.      C2: NR.
  4214.  
  4215.      B1: NEW: Sensitivity labels associated with each subject and storage
  4216.          object under its control (e.g., process, file, segment, device) shall
  4217.          be maintained by the TCB.  These labels shall be used as the basis 
  4218.          for mandatory access control decisions.  In order to import non-
  4219.          labeled data, the TCB shall request and receive from an authorized 
  4220.          user the security level of the data, and all such actions shall be
  4221.          auditable by the TCB.
  4222.  
  4223.      B2: CHANGE: Sensitivity labels associated with each ADP system resource
  4224.          (e.g., subject, storage object) that is directly or indirectly 
  4225.          accessible by subjects external to the TCB shall be maintained by 
  4226.          the TCB.
  4227.  
  4228.      B3: NAR.
  4229.  
  4230.      A1: NAR.
  4231.  
  4232. Mandatory Access Control
  4233.  
  4234.      C1: NR.
  4235.  
  4236.      C2: NR.
  4237.  
  4238.      B1: NEW: The TCB shall enforce a mandatory access control policy over all
  4239.          subjects and storage objects under its control (e.g., processes, 
  4240.          files, segments, devices).  These subjects and objects shall be 
  4241.          assigned sensitivity labels that are a combination of hierarchical 
  4242.          classification levels and non-hierarchical categories, and the labels
  4243.          shall be used as the basis for mandatory access control decisions.
  4244.          The TCB shall be able to support two or more such security levels.
  4245.          (See the Mandatory Access Control guidelines.)  The following
  4246.          requirements shall hold for all accesses between subjects and objects
  4247.          controlled by the TCB: A subject can read an object only if the
  4248.          hierarchical classification in the subject's security level is 
  4249.          greater than or equal to the hierarchical classification in the 
  4250.          object's security level and the non-hierarchical categories in the
  4251.          subject's security level include all the non-hierarchical categories
  4252.          in the object's security level.  A subject can write an object only
  4253.          if the hierarchical classification in the subject's security level is
  4254.          less than or equal to the hierarchical classification in the object's
  4255.          security level and all the non-hierarchical categories in the 
  4256.          subject's security level are included in the non-hierarchical 
  4257.          categories in the object's security level.
  4258.  
  4259.      B2: CHANGE: The TCB shall enforce a mandatory access control policy over
  4260.          all resources (i.e., subjects, storage objects, and I/O devices) that
  4261.          are directly or indirectly accessible by subjects external to the TCB.
  4262.          The following requirements shall hold for all accesses between all
  4263.          subjects external to the TCB and all objects directly or indirectly 
  4264.          accessible by these subjects:
  4265.  
  4266.      B3: NAR.
  4267.  
  4268.      A1: NAR.
  4269.  
  4270. Object Reuse
  4271.  
  4272.      C1: NR.
  4273.  
  4274.      C2: NEW: When a storage object is initially assigned, allocated, or
  4275.          reallocated to a subject from the TCB's pool of unused storage 
  4276.          objects, the TCB shall assure that the object contains no data for 
  4277.          which the subject is not authorized.
  4278.  
  4279.      B1: NAR.
  4280.  
  4281.      B2: NAR.
  4282.  
  4283.      B3: NAR.
  4284.  
  4285.      A1: NAR.
  4286.  
  4287. Security Features User's Guide
  4288.  
  4289.      C1: NEW: A single summary, chapter, or manual in user documentation shall
  4290.          describe the protection mechanisms provided by the TCB, guidelines on
  4291.          their use, and how they interact with one another.
  4292.  
  4293.      C2: NAR.
  4294.  
  4295.      B1: NAR.
  4296.  
  4297.      B2: NAR.
  4298.  
  4299.      B3: NAR.
  4300.  
  4301.      A1: NAR.
  4302.  
  4303. Security Testing
  4304.  
  4305.      C1: NEW: The security mechanisms of the ADP system shall be tested and
  4306.          found to work as claimed in the system documentation.  Testing shall 
  4307.          be done to assure that there are no obvious ways for an unauthorized
  4308.          user to bypass or otherwise defeat the security protection mechanisms
  4309.          of the TCB.  (See the Security Testing guidelines.)
  4310.  
  4311.      C2: ADD: Testing shall also include a search for obvious flaws that would
  4312.          allow violation of resource isolation, or that would permit 
  4313.          unauthorized access to the audit or authentication data.
  4314.  
  4315.      B1: NEW: The security mechanisms of the ADP system shall be tested and
  4316.          found to work as claimed in the system documentation.  A team of 
  4317.          individuals who thoroughly understand the specific implementation of
  4318.          the TCB shall subject its design documentation, source code, and 
  4319.          object code to thorough analysis and testing.  Their objectives shall
  4320.          be: to uncover all design and implementation flaws that would permit
  4321.          a subject external to the TCB to read, change, or delete data
  4322.          normally denied under the mandatory or discretionary security policy 
  4323.          enforced by the TCB; as well as to assure that no subject (without
  4324.          authorization to do so) is able to cause the TCB to enter a state
  4325.          such that it is unable to respond to communications initiated by 
  4326.          other users.  All discovered flaws shall be removed or neutralized 
  4327.          and the TCB retested to demonstrate that they have been eliminated 
  4328.          and that new flaws have not been introduced.  (See the Security 
  4329.          Testing Guidelines.)
  4330.  
  4331.      B2: CHANGE: All discovered flaws shall be corrected and the TCB retested
  4332.          to demonstrate that they have been eliminated and that new flaws have
  4333.          not been introduced.
  4334.  
  4335.          ADD: The TCB shall be found relatively resistant to penetration.
  4336.          Testing shall demonstrate that the TCB implementation is consistent 
  4337.          with the descriptive top-level specification.
  4338.  
  4339.      B3: CHANGE: The TCB shall be found resistant to penetration.
  4340.  
  4341.          ADD: No design flaws and no more than a few correctable
  4342.          implementation flaws may be found during testing and there shall be 
  4343.          reasonable confidence that few remain.
  4344.  
  4345.      A1: CHANGE: Testing shall demonstrate that the TCB implementation is
  4346.          consistent with the formal top-level specification.
  4347.  
  4348.          ADD: Manual or other mapping of the FTLS to the source code may form
  4349.          a basis for penetration testing.
  4350.  
  4351. Subject Sensitivity Labels
  4352.  
  4353.      C1: NR.
  4354.  
  4355.      C2: NR.
  4356.  
  4357.      B1: NR.
  4358.  
  4359.      B2: NEW: The TCB shall immediately notify a terminal user of each change
  4360.          in the security level associated with that user during an interactive
  4361.          session.  A terminal user shall be able to query the TCB as desired 
  4362.          for a display of the subject's complete sensitivity label.
  4363.  
  4364.      B3: NAR.
  4365.  
  4366.      A1: NAR.
  4367.  
  4368. System Architecture
  4369.  
  4370.      C1: NEW: The TCB shall maintain a domain for its own execution that
  4371.          protects it from external interference or tampering (e.g., by 
  4372.          modification of its code or data structures).  Resources controlled 
  4373.          by the TCB may be a defined subset of the subjects and objects in 
  4374.          the ADP system.
  4375.  
  4376.      C2: ADD: The TCB shall isolate the resources to be protected so that they
  4377.          are subject to the access control and auditing requirements.
  4378.  
  4379.      B1: ADD: The TCB shall maintain process isolation through the provision
  4380.          of distinct address spaces under its control.
  4381.  
  4382.      B2: NEW: The TCB shall maintain a domain for its own execution that
  4383.          protects it from external interference or tampering (e.g., by 
  4384.          modification of its code or data structures).  The TCB shall maintain
  4385.          process isolation through the provision of distinct address spaces 
  4386.          under its control.  The TCB shall be internally structured into well-
  4387.          defined largely independent modules.  It shall make effective use of
  4388.          available hardware to separate those elements that are protection-
  4389.          critical from those that are not.  The TCB modules shall be designed
  4390.          such that the principle of least privilege is enforced.  Features in
  4391.          hardware, such as segmentation, shall be used to support logically 
  4392.          distinct storage objects with separate attributes (namely: readable, 
  4393.          writeable).  The user interface to the TCB shall be completely 
  4394.          defined and all elements of the TCB identified.
  4395.  
  4396.      B3: ADD: The TCB shall be designed and structured to use a complete,
  4397.          conceptually simple protection mechanism with precisely defined 
  4398.          semantics.  This mechanism shall play a central role in enforcing the
  4399.          internal structuring of the TCB and the system.  The TCB shall
  4400.          incorporate significant use of layering, abstraction and data hiding.
  4401.          Significant system engineering shall be directed toward minimizing
  4402.          the complexity of the TCB and excluding from the TCB modules that are
  4403.          not protection-critical.
  4404.  
  4405.      A1: NAR.
  4406.  
  4407. System Integrity
  4408.  
  4409.      C1: NEW: Hardware and/or software features shall be provided that can be
  4410.          used to periodically validate the correct operation of the on-site 
  4411.          hardware and firmware elements of the TCB.
  4412.  
  4413.      C2: NAR.
  4414.  
  4415.      B1: NAR.
  4416.  
  4417.      B2: NAR.
  4418.  
  4419.      B3: NAR.
  4420.  
  4421.      A1: NAR.
  4422.  
  4423. Test Documentation
  4424.  
  4425.      C1: NEW: The system developer shall provide to the evaluators a document
  4426.          that describes the test plan and results of the security mechanisms'
  4427.          functional testing.
  4428.  
  4429.      C2: NAR.
  4430.  
  4431.      B1: NAR.
  4432.  
  4433.      B2: ADD: It shall include results of testing the effectiveness of the
  4434.          methods used to reduce covert channel bandwidths.
  4435.  
  4436.      B3: NAR.
  4437.  
  4438.      A1: ADD: The results of the mapping between the formal top-level
  4439.          specification and the TCB source code shall be given.
  4440.  
  4441. Trusted Distribution
  4442.  
  4443.      C1: NR.
  4444.  
  4445.      C2: NR.
  4446.  
  4447.      B1: NR.
  4448.  
  4449.      B2: NR.
  4450.  
  4451.      B3: NR.
  4452.  
  4453.      A1: NEW: A trusted ADP system control and distribution facility shall be
  4454.          provided for maintaining the integrity of the mapping between the 
  4455.          master data describing the current version of the TCB and the on-site
  4456.          master copy of the code for the current version.  Procedures (e.g.,
  4457.          site security acceptance testing) shall exist for assuring that the
  4458.          TCB software, firmware, and hardware updates distributed to a
  4459.          customer are exactly as specified by the master copies.
  4460.  
  4461. Trusted Facility Management
  4462.  
  4463.      C1: NR.
  4464.  
  4465.      C2: NR.
  4466.  
  4467.      B1: NR.
  4468.  
  4469.      B2: NEW: The TCB shall support separate operator and administrator
  4470.          functions.
  4471.  
  4472.      B3: ADD: The functions performed in the role of a security administrator
  4473.          shall be identified.  The ADP system administrative personnel shall 
  4474.          only be able to perform security administrator functions after taking
  4475.          a distinct auditable action to assume the security administrator role
  4476.          on the ADP system.  Non-security functions that can be performed in
  4477.          the security administration role shall be limited strictly to those
  4478.          essential to performing the security role effectively.
  4479.  
  4480.      A1: NAR.
  4481.  
  4482. Trusted Facility Manual
  4483.  
  4484.      C1: NEW: A manual addressed to the ADP system administrator shall present
  4485.          cautions about functions and privileges that should be controlled 
  4486.          when running a secure facility.
  4487.  
  4488.      C2: ADD: The procedures for examining and maintaining the audit files as
  4489.          well as the detailed audit record structure for each type of audit 
  4490.          event shall be given.
  4491.  
  4492.      B1: ADD: The manual shall describe the operator and administrator
  4493.          functions related to security, to include changing the 
  4494.          characteristics of a user.  It shall provide guidelines on the 
  4495.          consistent and effective use of the protection features of the
  4496.          system, how they interact, how to securely generate a new TCB, and
  4497.          facility procedures, warnings, and privileges that need to be
  4498.          controlled in order to operate the facility in a secure manner.
  4499.  
  4500.      B2: ADD: The TCB modules that contain the reference validation mechanism
  4501.          shall be identified.  The procedures for secure generation of a new 
  4502.          TCB from source after modification of any modules in the TCB shall 
  4503.          be described.
  4504.  
  4505.      B3: ADD: It shall include the procedures to ensure that the system is
  4506.          initially started in a secure manner.  Procedures shall also be 
  4507.          included to resume secure system operation after any lapse in system
  4508.          operation.
  4509.  
  4510.      A1: NAR.
  4511.  
  4512. Trusted Path
  4513.  
  4514.      C1: NR.
  4515.  
  4516.      C2: NR.
  4517.  
  4518.      B1: NR.
  4519.  
  4520.      B2: NEW: The TCB shall support a trusted communication path between
  4521.          itself and user for initial login and authentication.  Communications
  4522.          via this path shall be initiated exclusively by a user.
  4523.  
  4524.      B3: CHANGE: The TCB shall support a trusted communication path between
  4525.          itself and users for use when a positive TCB-to-user connection is 
  4526.          required (e.g., login, change subject security level).  
  4527.          Communications via this trusted path shall be activated exclusively
  4528.          by a user or the TCB and shall be logically isolated and unmistakably
  4529.          distinguishable from other paths.
  4530.  
  4531.      A1: NAR.
  4532.  
  4533. Trusted Recovery
  4534.  
  4535.      C1: NR.
  4536.  
  4537.      C2: NR.
  4538.  
  4539.      B1: NR.
  4540.  
  4541.      B2: NR.
  4542.  
  4543.      B3: NEW: Procedures and/or mechanisms shall be provided to assure that,
  4544.          after an ADP system failure or other discontinuity, recovery without a
  4545.          protection compromise is obtained.
  4546.  
  4547.      A1: NAR.
  4548.  
  4549.  
  4550.  
  4551.  
  4552.  
  4553.     (this page is reserved for Figure 1)
  4554.  
  4555.  
  4556.  
  4557.  
  4558.                                  GLOSSARY
  4559.  
  4560.  
  4561. Access - A specific type of interaction between a subject and an object 
  4562.      that results in the flow of information from one to the other.
  4563.  
  4564. Approval/Accreditation - The official authorization that is
  4565.      granted to an ADP system to process sensitive information in
  4566.      its operational environment, based upon comprehensive
  4567.      security evaluation of the system's hardware, firmware, and
  4568.      software security design, configuration, and implementation
  4569.      and of the other system procedural, administrative,
  4570.      physical, TEMPEST, personnel, and communications security
  4571.      controls.
  4572.  
  4573. Audit Trail - A set of records that collectively provide
  4574.      documentary evidence of processing used to aid in tracing
  4575.      from original transactions forward to related records and
  4576.      reports, and/or backwards from records and reports to their
  4577.      component source transactions.
  4578.  
  4579. Authenticate - To establish the validity of a claimed identity.
  4580.  
  4581. Automatic Data Processing (ADP) System - An assembly of computer
  4582.      hardware, firmware, and software configured for the purpose
  4583.      of classifying, sorting, calculating, computing,
  4584.      summarizing, transmitting and receiving, storing, and
  4585.      retrieving data with a minimum of human intervention.
  4586.  
  4587. Bandwidth - A characteristic of a communication channel that is
  4588.      the amount of information that can be passed through it in a
  4589.      given amount of time, usually expressed in bits per second.
  4590.  
  4591. Bell-LaPadula Model - A formal state transition model of computer
  4592.      security policy that describes a set of access control
  4593.      rules.  In this formal model, the entities in a computer
  4594.      system are divided into abstract sets of subjects and
  4595.      objects.  The notion of a secure state is defined and it is
  4596.      proven that each state transition preserves security by
  4597.      moving from secure state to secure state; thus, inductively
  4598.      proving that the system is secure.  A system state is
  4599.      defined to be "secure" if the only permitted access modes of
  4600.      subjects to objects are in accordance with a specific
  4601.      security policy.  In order to determine whether or not a
  4602.      specific access mode is allowed, the clearance of a subject
  4603.      is compared to the classification of the object and a
  4604.      determination is made as to whether the subject is
  4605.      authorized for the specific access mode.  The
  4606.      clearance/classification scheme is expressed in terms of a
  4607.      lattice.  See also: Lattice, Simple Security Property, *-
  4608.      Property.
  4609.  
  4610. Certification - The technical evaluation of a system's security
  4611.      features, made as part of and in support of the
  4612.      approval/accreditation process, that establishes the extent
  4613.      to which a particular computer system's design and
  4614.      implementation meet a set of specified security
  4615.      requirements.
  4616.  
  4617. Channel - An information transfer path within a system.  May also
  4618.      refer to the mechanism by which the path is effected.
  4619.  
  4620. Covert Channel - A communication channel that allows a process to
  4621.      transfer information in a manner that violates the system's
  4622.      security policy.  See also:  Covert Storage Channel, Covert
  4623.      Timing Channel.
  4624.  
  4625. Covert Storage Channel - A covert channel that involves the
  4626.      direct or indirect writing of a storage location by one
  4627.      process and the direct or indirect reading of the storage
  4628.      location by another process.  Covert storage channels
  4629.      typically involve a finite resource (e.g., sectors on a
  4630.      disk) that is shared by two subjects at different security
  4631.      levels.
  4632.  
  4633. Covert Timing Channel - A covert channel in which one process
  4634.      signals information to another by modulating its own use of
  4635.      system resources (e.g., CPU time) in such a way that this
  4636.      manipulation affects the real response time observed by the
  4637.      second process.
  4638.  
  4639. Data - Information with a specific physical representation.
  4640.  
  4641. Data Integrity - The state that exists when computerized data is
  4642.      the same as that in the source documents and has not been
  4643.      exposed to accidental or malicious alteration or
  4644.      destruction.
  4645.  
  4646. Descriptive Top-Level Specification (DTLS) - A top-level
  4647.      specification that is written in a natural language (e.g.,
  4648.      English), an informal program design notation, or a
  4649.      combination of the two.
  4650.  
  4651. Discretionary Access Control - A means of restricting access to
  4652.      objects based on the identity of subjects and/or groups to
  4653.      which they belong.  The controls are discretionary in the
  4654.      sense that a subject with a certain access permission is
  4655.      capable of passing that permission (perhaps indirectly) on
  4656.      to any other subject.
  4657.  
  4658. Domain - The set of objects that a subject has the ability to
  4659.      access.
  4660.  
  4661. Dominate - Security level S1 is said to dominate security level
  4662.      S2 if the hierarchical classification of S1 is greater than
  4663.      or equal to that of S2 and the non-hierarchical categories
  4664.      of S1 include all those of S2 as a subset.
  4665.  
  4666. Exploitable Channel - Any channel that is useable or detectable
  4667.      by subjects external to the Trusted Computing Base.
  4668.  
  4669. Flaw Hypothesis Methodology - A system analysis and penetration
  4670.      technique where specifications and documentation for the
  4671.      system are analyzed and then flaws in the system are
  4672.      hypothesized.  The list of hypothesized flaws is then
  4673.      prioritized on the basis of the estimated probability that a
  4674.      flaw actually exists and, assuming a flaw does exist, on the
  4675.      ease of exploiting it and on the extent of control or
  4676.      compromise it would provide.  The prioritized list is used
  4677.      to direct the actual testing of the system.
  4678.  
  4679. Flaw - An error of commission, omission, or oversight in a system
  4680.      that allows protection mechanisms to be bypassed.
  4681.  
  4682. Formal Proof - A complete and convincing mathematical argument,
  4683.      presenting the full logical justification for each proof
  4684.      step, for the truth of a theorem or set of theorems.  The
  4685.      formal verification process uses formal proofs to show the
  4686.      truth of certain properties of formal specification and for
  4687.      showing that computer programs satisfy their specifications.
  4688.  
  4689. Formal Security Policy Model - A mathematically precise statement
  4690.      of a security policy.  To be adequately precise, such a
  4691.      model must represent the initial state of a system, the way
  4692.      in which the system progresses from one state to another,
  4693.      and a definition of a "secure" state of the system.  To be
  4694.      acceptable as a basis for a TCB, the model must be supported
  4695.      by a formal proof that if the initial state of the system
  4696.      satisfies the definition of a "secure" state and if all
  4697.      assumptions required by the model hold, then all future
  4698.      states of the system will be secure.  Some formal modeling
  4699.      techniques include:  state transition models, temporal logic
  4700.      models, denotational semantics models, algebraic
  4701.      specification models.  An example is the model described by
  4702.      Bell and LaPadula in reference [2].  See also:  Bell-
  4703.      LaPadula Model, Security Policy Model.
  4704.  
  4705. Formal Top-Level Specification (FTLS) - A Top-Level Specification
  4706.      that is written in a formal mathematical language to allow
  4707.      theorems showing the correspondence of the system
  4708.      specification to its formal requirements to be hypothesized
  4709.      and formally proven.
  4710.  
  4711. Formal Verification - The process of using formal proofs to
  4712.      demonstrate the consistency (design verification) between a
  4713.      formal specification of a system and a formal security
  4714.      policy model or (implementation verification) between the
  4715.      formal specification and its program implementation.
  4716.  
  4717. Functional Testing - The portion of security testing in which the
  4718.      advertised features of a system are tested for correct
  4719.      operation.
  4720.  
  4721. General-Purpose System - A computer system that is designed to
  4722.      aid in solving a wide variety of problems.
  4723.  
  4724. Lattice - A partially ordered set for which every pair of
  4725.      elements has a greatest lower bound and a least upper bound.
  4726.  
  4727. Least Privilege - This principle requires that each subject in a
  4728.      system be granted the most restrictive set of privileges (or
  4729.      lowest clearance) needed for the performance of authorized
  4730.      tasks.  The application of this principle limits the damage
  4731.      that can result from accident, error, or unauthorized use.
  4732.  
  4733. Mandatory Access Control - A means of restricting access to
  4734.      objects based on the sensitivity (as represented by a label)
  4735.      of the information contained in the objects and the formal
  4736.      authorization (i.e., clearance) of subjects to access
  4737.      information of such sensitivity.
  4738.  
  4739. Multilevel Device - A device that is used in a manner that
  4740.      permits it to simultaneously process data of two or more
  4741.      security levels without risk of compromise.  To accomplish
  4742.      this, sensitivity labels are normally stored on the same
  4743.      physical medium and in the same form (i.e., machine-readable
  4744.      or human-readable) as the data being processed.
  4745.  
  4746. Multilevel Secure - A class of system containing information with
  4747.      different sensitivities that simultaneously permits access
  4748.      by users with different security clearances and needs-to-
  4749.      know, but prevents users from obtaining access to
  4750.      information for which they lack authorization.
  4751.  
  4752. Object - A passive entity that contains or receives information.
  4753.      Access to an object potentially implies access to the
  4754.      information it contains.  Examples of objects are:  records,
  4755.      blocks, pages, segments, files, directories, directory
  4756.      trees, and programs, as well as bits, bytes, words, fields,
  4757.      processors, video displays, keyboards, clocks, printers,
  4758.      network nodes, etc.
  4759.  
  4760. Object Reuse - The reassignment to some subject of a medium
  4761.      (e.g., page frame, disk sector, magnetic tape) that
  4762.      contained one or more objects.  To be securely reassigned,
  4763.      such media must contain no residual data from the previously
  4764.      contained object(s).
  4765.  
  4766. Output - Information that has been exported by a TCB.
  4767.  
  4768. Password - A private character string that is used to
  4769.      authenticate an identity.
  4770.  
  4771. Penetration Testing - The portion of security testing in which
  4772.      the penetrators attempt to circumvent the security features
  4773.      of a system.  The penetrators may be assumed to use all
  4774.      system design and implementation documentation, which may
  4775.      include listings of system source code, manuals, and circuit
  4776.      diagrams.  The penetrators work under no constraints other
  4777.      than those that would be applied to ordinary users.
  4778.  
  4779. Process - A program in execution.  It is completely characterized
  4780.      by a single current execution point (represented by the
  4781.      machine state) and address space.
  4782.  
  4783. Protection-Critical Portions of the TCB - Those portions of the
  4784.      TCB whose normal function is to deal with the control of
  4785.      access between subjects and objects.
  4786.  
  4787. Protection Philosophy - An informal description of the overall
  4788.      design of a system that delineates each of the protection
  4789.      mechanisms employed.  A combination (appropriate to the
  4790.      evaluation class) of formal and informal techniques is used
  4791.      to show that the mechanisms are adequate to enforce the
  4792.      security policy.
  4793.  
  4794. Read - A fundamental operation that results only in the flow of
  4795.      information from an object to a subject.
  4796.  
  4797. Read Access - Permission to read information.
  4798.  
  4799. Reference Monitor Concept - An access control concept that refers
  4800.      to an abstract machine that mediates all accesses to objects
  4801.      by subjects.
  4802.  
  4803. Resource - Anything used or consumed while performing a function.
  4804.      The categories of resources are: time, information, objects
  4805.      (information containers), or processors (the ability to use
  4806.      information).  Specific examples are: CPU time; terminal
  4807.      connect time; amount of directly-addressable memory; disk
  4808.      space; number of I/O requests per minute, etc.
  4809.  
  4810. Security Kernel - The hardware, firmware, and software elements
  4811.      of a Trusted Computing Base that implement the reference
  4812.      monitor concept.  It must mediate all accesses, be protected
  4813.      from modification, and be verifiable as correct.
  4814.  
  4815. Security Level - The combination of a hierarchical classification
  4816.      and a set of non-hierarchical categories that represents the
  4817.      sensitivity of information.
  4818.  
  4819. Security Policy - The set of laws, rules, and practices that
  4820.      regulate how an organization manages, protects, and
  4821.      distributes sensitive information.
  4822.  
  4823. Security Policy Model - An informal presentation of a formal
  4824.      security policy model.
  4825.  
  4826. Security Testing - A process used to determine that the security
  4827.      features of a system are implemented as designed and that
  4828.      they are adequate for a proposed application environment.
  4829.      This process includes hands-on functional testing,
  4830.      penetration testing, and verification.  See also: Functional
  4831.      Testing, Penetration Testing, Verification.
  4832.  
  4833. Sensitive Information - Information that, as determined by a
  4834.      competent authority, must be protected because its
  4835.      unauthorized disclosure, alteration, loss, or destruction
  4836.      will at least cause perceivable damage to someone or
  4837.      something.
  4838.  
  4839. Sensitivity Label - A piece of information that represents the
  4840.      security level of an object and that describes the
  4841.      sensitivity (e.g., classification) of the data in the
  4842.      object.   Sensitivity labels are used by the TCB as the basis
  4843.      for mandatory access control decisions.
  4844.  
  4845. Simple Security Property - A Bell-LaPadula security model rule
  4846.      allowing a subject read access to an object only if the
  4847.      security level of the subject dominates the security level
  4848.      of the object.
  4849.  
  4850. Single-Level Device - A device that is used to process data of a
  4851.      single security level at any one time.  Since the device
  4852.      need not be trusted to separate data of different security
  4853.      levels, sensitivity labels do not have to be stored with the
  4854.      data being processed.
  4855.  
  4856. *-Property (Star Property) - A Bell-LaPadula security model rule
  4857.      allowing a subject write access to an object only if the
  4858.      security level of the subject is dominated by the security
  4859.      level of the object.  Also known as the Confinement
  4860.      Property.
  4861.  
  4862. Storage Object - An object that supports both read and write
  4863.      accesses.
  4864.  
  4865. Subject - An active entity, generally in the form of a person,
  4866.      process, or device that causes information to flow among
  4867.      objects or changes the system state.  Technically, a
  4868.      process/domain pair.
  4869.  
  4870. Subject Security Level - A subject's security level is equal to
  4871.      the security level of the objects to which it has both read
  4872.      and write access.  A subject's security level must always be
  4873.      dominated by the clearance of the user the subject is
  4874.      associated with.
  4875.  
  4876. TEMPEST - The study and control of spurious electronic signals
  4877.      emitted from ADP equipment.
  4878.  
  4879. Top-Level Specification (TLS) - A non-procedural description of
  4880.      system behavior at the most abstract level.  Typically a
  4881.      functional specification that omits all implementation
  4882.      details.
  4883.  
  4884. Trap Door - A hidden software or hardware mechanism that permits
  4885.      system protection mechanisms to be circumvented.  It is
  4886.      activated in some non-apparent manner (e.g., special
  4887.      "random" key sequence at a terminal).
  4888.  
  4889. Trojan Horse - A computer program with an apparently or actually
  4890.      useful function that contains additional (hidden) functions
  4891.      that surreptitiously exploit the legitimate authorizations
  4892.      of the invoking process to the detriment of security.  For
  4893.      example, making a "blind copy" of a sensitive file for the
  4894.      creator of the Trojan Horse.
  4895.  
  4896. Trusted Computer System - A system that employs sufficient
  4897.      hardware and software integrity measures to allow its use
  4898.      for processing simultaneously a range of sensitive or
  4899.      classified information.
  4900.  
  4901. Trusted Computing Base (TCB) - The totality of protection
  4902.      mechanisms within a computer system -- including hardware,
  4903.      firmware, and software -- the combination of which is
  4904.      responsible for enforcing a security policy.  It creates a
  4905.      basic protection environment and provides additional user
  4906.      services required for a trusted computer system.  The
  4907.      ability of a trusted computing base to correctly enforce a
  4908.      security policy depends solely on the mechanisms within the
  4909.      TCB and on the correct input by system administrative
  4910.      personnel of parameters (e.g., a user's clearance) related
  4911.      to the security policy.
  4912.  
  4913. Trusted Path - A mechanism by which a person at a terminal can
  4914.      communicate directly with the Trusted Computing Base.  This
  4915.      mechanism can only be activated by the person or the Trusted
  4916.      Computing Base and cannot be imitated by untrusted software.
  4917.  
  4918. Trusted Software - The software portion of a Trusted Computing
  4919.      Base.
  4920.  
  4921. User - Any person who interacts directly with a computer system.
  4922.  
  4923. Verification - The process of comparing two levels of system
  4924.      specification for proper correspondence (e.g., security
  4925.      policy model with top-level specification, TLS with source
  4926.      code, or source code with object code).  This process may or
  4927.      may not be automated.
  4928.  
  4929. Write - A fundamental operation that results only in the flow of
  4930.      information from a subject to an object.
  4931.  
  4932. Write Access - Permission to write an object.
  4933.  
  4934.  
  4935.  
  4936.  
  4937.  
  4938.                               REFERENCES
  4939.  
  4940.  
  4941. 1.  Anderson, J. P.  Computer Security Technology Planning
  4942.          Study, ESD-TR-73-51, vol. I, ESD/AFSC, Hanscom AFB,
  4943.          Bedford, Mass., October 1972 (NTIS AD-758 206).
  4944.  
  4945. 2.  Bell, D. E. and LaPadula, L. J.  Secure Computer Systems:
  4946.          Unified Exposition and Multics Interpretation, MTR-2997
  4947.          Rev. 1, MITRE Corp., Bedford, Mass., March 1976.
  4948.  
  4949. 3.  Brand, S. L.    "An Approach to Identification and Audit of
  4950.          Vulnerabilities and Control in Application Systems," in
  4951.          Audit and Evaluation of Computer Security II: System
  4952.          Vulnerabilities and Controls, Z. Ruthberg, ed., NBS
  4953.          Special Publication #500-57, MD78733, April 1980.
  4954.  
  4955. 4.  Brand, S. L.    "Data Processing and A-123," in Proceedings of
  4956.          the Computer Performance Evaluation User's Group 18th
  4957.          Meeting, C. B. Wilson, ed., NBS Special Publication
  4958.          #500-95, October 1982.
  4959.  
  4960. 5.  Denning, D. E.  "A Lattice Model of Secure Information
  4961.          Flow," in Communications of the ACM, vol. 19, no. 5
  4962.          (May 1976), pp. 236-243.
  4963.  
  4964. 6.  Denning, D. E.  Secure Information Flow in Computer Systems,
  4965.          Ph.D. dissertation, Purdue Univ., West Lafayette, Ind.,
  4966.          May 1975.
  4967.  
  4968. 7.  DoD 5200.1-R, Information Security Program Regulation,
  4969.          August 1982.
  4970.  
  4971. 8.  DoD Directive 5200.28, Security Requirements for Automatic
  4972.          Data Processing (ADP) Systems, revised April 1978.
  4973.  
  4974. 9.  DoD 5200.28-M, ADP Security Manual -- Techniques and
  4975.          Procedures for Implementing, Deactivating, Testing, and
  4976.          Evaluating Secure Resource-Sharing ADP Systems, revised
  4977.          June 1979.
  4978.  
  4979. 10. DoD Directive 5215.1, Computer Security Evaluation Center,
  4980.          25 October 1982.
  4981.  
  4982. 11. DoD 5220.22-M, Industrial Security Manual for Safeguarding
  4983.          Classified Information, January 1983.
  4984.  
  4985. 12. DoD 5220.22-R, Industrial Security Regulation, January 1983.
  4986.  
  4987. 13. DoD Directive 5400.11, Department of Defense Privacy
  4988.          Program, 9 June 1982.
  4989.  
  4990. 14. Executive Order 12356, National Security Information,
  4991.          6 April 1982.
  4992.  
  4993. 15. Faurer, L. D.    "Keeping the Secrets Secret," in Government
  4994.          Data Systems, November - December 1981, pp. 14-17.
  4995.  
  4996. 16. Federal Information Processing Standards Publication (FIPS
  4997.          PUB) 39, Glossary for Computer Systems Security,
  4998.          15 February 1976.
  4999.  
  5000. 17. Federal Information Processing Standards Publication (FIPS
  5001.          PUB) 73, Guidelines for Security of Computer
  5002.          Applications, 30 June 1980.
  5003.  
  5004. 18. Federal Information Processing Standards Publication (FIPS
  5005.          PUB) 102, Guideline for Computer Security Certification
  5006.          and Accreditation.
  5007.  
  5008. 19. Lampson, B. W.  "A Note on the Confinement Problem," in
  5009.          Communications of the ACM, vol. 16, no. 10 (October
  5010.          1973), pp. 613-615.
  5011.  
  5012. 20. Lee, T. M. P., et al.     "Processors, Operating Systems and
  5013.          Nearby Peripherals: A Consensus Report," in Audit and
  5014.          Evaluation of Computer Security II: System
  5015.          Vulnerabilities and Controls, Z. Ruthberg, ed., NBS
  5016.          Special Publication #500-57, MD78733, April 1980.
  5017.  
  5018. 21. Lipner, S. B.    A Comment on the Confinement Problem, MITRE
  5019.          Corp., Bedford, Mass.
  5020.  
  5021. 22. Millen, J. K.    "An Example of a Formal Flow Violation," in
  5022.          Proceedings of the IEEE Computer Society 2nd
  5023.          International Computer Software and Applications
  5024.          Conference, November 1978, pp. 204-208.
  5025.  
  5026. 23. Millen, J. K.    "Security Kernel Validation in Practice," in
  5027.          Communications of the ACM, vol. 19, no. 5 (May 1976),
  5028.          pp. 243-250.
  5029.  
  5030. 24. Nibaldi, G. H.  Proposed Technical Evaluation Criteria for
  5031.          Trusted Computer Systems, MITRE Corp., Bedford, Mass.,
  5032.          M79-225, AD-A108-832, 25 October 1979.
  5033.  
  5034. 25. Nibaldi, G. H.  Specification of A Trusted Computing Base,
  5035.          (TCB), MITRE Corp., Bedford, Mass., M79-228, AD-A108-
  5036.          831, 30 November 1979.
  5037.  
  5038. 26. OMB Circular A-71, Transmittal Memorandum No. 1, Security of
  5039.          Federal Automated Information Systems, 27 July 1978.
  5040.  
  5041. 27. OMB Circular A-123, Internal Control Systems, 5 November
  5042.          1981.
  5043.  
  5044. 28. Ruthberg, Z. and McKenzie, R., eds.  Audit and Evaluation of
  5045.          Computer Security, in NBS Special Publication #500-19,
  5046.          October 1977.
  5047.  
  5048. 29. Schaefer, M., Linde, R. R., et al.  "Program Confinement in
  5049.          KVM/370," in Proceedings of the ACM National
  5050.          Conference, October 1977, Seattle.
  5051.  
  5052. 30. Schell, R. R.    "Security Kernels: A Methodical Design of
  5053.          System Security," in Technical Papers, USE Inc. Spring
  5054.          Conference, 5-9 March 1979, pp. 245-250.
  5055.  
  5056. 31. Trotter, E. T. and Tasker, P. S.  Industry Trusted Computer
  5057.          Systems Evaluation Process, MITRE Corp., Bedford,
  5058.          Mass., MTR-3931, 1 May 1980.
  5059.  
  5060. 32. Turn, R.  Trusted Computer Systems: Needs and Incentives for
  5061.          Use in government and Private Sector, (AD # A103399),
  5062.          Rand Corporation (R-28811-DR&E), June 1981.
  5063.  
  5064. 33. Walker, S. T.    "The Advent of Trusted Computer Operating
  5065.          Systems," in National Computer Conference Proceedings,
  5066.          May 1980, pp. 655-665.
  5067.  
  5068. 34. Ware, W. H., ed., Security Controls for Computer Systems:
  5069.          Report of Defense Science Board Task Force on Computer
  5070.          Security, AD # A076617/0, Rand Corporation, Santa
  5071.          Monica, Calif., February 1970, reissued October 1979.
  5072.  
  5073.    DoD STANDARD 5200.28:  SUMMARY OF THE DIFFERENCES 
  5074.                           BETWEEN IT AND CSC-STD-001-83
  5075.  
  5076.  
  5077. Note: Text which has been added or changed is indented and preceded by > sign.
  5078. Text which has been deleted is enclosed in slashes (/).  "Computer Security
  5079. Center" was changed to "National Computer Security Center" throughout the
  5080. document.
  5081.  
  5082. The FOREWORD Section was rewritten and signed by Mr. Don Latham on
  5083. 26 Dec 85.  The ACKNOWLEDGEMENTS Section was updated.
  5084.                                      
  5085. The PREFACE was changed as follows: 
  5086.  
  5087.                                  PREFACE 
  5088.  
  5089.  
  5090. The trusted computer system evaluation criteria defined in this 
  5091. document classify systems into four broad hierarchical divisions 
  5092. of enhanced security protection.  The criteria provide a basis 
  5093. for the evaluation of effectiveness of security controls built 
  5094. into automatic data processing system products.  The criteria 
  5095. were developed with three objectives in mind:  (a) to provide 
  5096. users with a yardstick with which to assess the degree of trust 
  5097. that can be placed in computer systems for the secure processing 
  5098. of classified or other sensitive information; (b) to provide 
  5099. guidance to manufacturers as to what to build into their new, 
  5100. widely-available trusted commercial products in order to satisfy 
  5101. trust requirements for sensitive applications; and (c) to provide 
  5102. a basis for specifying security requirements in acquisition 
  5103. specifications.  Two types of requirements are delineated for 
  5104. secure processing: (a) specific security feature requirements and 
  5105. (b) assurance requirements.  Some of the latter requirements 
  5106. enable evaluation personnel to determine if the required features 
  5107. are present and functioning as intended.  
  5108.  
  5109.         >The scope of these criteria is to be applied to
  5110.         >the set of components comprising a trusted system, and is
  5111.         >not necessarily to be applied to each system component
  5112.         >individually.  Hence, some components of a system may be
  5113.         >completely untrusted, while others may be individually
  5114.         >evaluated to a lower or higher evaluation class than the
  5115.         >trusted product considered as a whole system.  In trusted
  5116.         >products at the high end of the range, the strength of the
  5117.         >reference monitor is such that most of the system
  5118.         >components can be completely untrusted.  
  5119.  
  5120. Though the criteria are 
  5121.  
  5122.         >intended to be
  5123.  
  5124. application-independent, /it is recognized that/ the
  5125. specific security feature requirements may have to be
  5126. interpreted when applying the criteria to specific 
  5127.  
  5128.         >systems with their own functional requirements,
  5129.         >applications or special environments (e.g., communications
  5130.         >processors, process control computers, and embedded systems
  5131.         >in general).
  5132.  
  5133. The underlying assurance requirements can be
  5134. applied across the entire spectrum of ADP system or
  5135. application processing environments without special
  5136. interpretation.
  5137.  
  5138.                                      
  5139. The SCOPE Section was changed as follows:
  5140.  
  5141. Scope
  5142.  
  5143. The trusted computer system evaluation criteria defined in this 
  5144. document apply 
  5145.  
  5146.         >primarily
  5147.  
  5148. to /both/ trusted, commercially available 
  5149. automatic data processing (ADP) systems.  
  5150.  
  5151.         >They are also applicable, as amplified below, to the
  5152.         >evaluation of existing systems and to the specification of
  5153.         >security requirements for ADP systems acquisition.
  5154.  
  5155. Included are two distinct sets of requirements: l) specific security
  5156. feature requirements; and 2) assurance requirements.  The specific 
  5157. feature requirements encompass the capabilities typically found 
  5158. in information processing systems employing general-purpose 
  5159. operating systems that are distinct from the applications programs
  5160. being supported.  
  5161.  
  5162.         >However, specific security feature requirements
  5163.         >may also apply to specific systems with their own functional
  5164.         >requirements, applications or special environments (e.g.,
  5165.         >communications processors, process control computers, and embedded
  5166.         >systems in general).  
  5167.  
  5168. The assurance requirements, on the other hand,
  5169. apply to systems that cover the full range of computing environments
  5170. from dedicated controllers to full range multilevel secure resource
  5171. sharing systems.
  5172.  
  5173.                                      
  5174. Changed the Purpose Section as follows:  
  5175.  
  5176. Purpose
  5177.  
  5178. As outlined in the Preface, the criteria have been developed to
  5179. serve a number of intended purposes: 
  5180.  
  5181.      To provide 
  5182.  
  5183.             >a standard 
  5184.  
  5185.      to manufacturers as to what security features to build
  5186.      into their new and planned, ... trust requirements      
  5187.  
  5188.            >(with particular emphasis on preventing the       
  5189.          >disclosure of data)
  5190.  
  5191.      for sensitive applications.
  5192.  
  5193.      To provide 
  5194.  
  5195.                 >DoD components 
  5196.  
  5197.      with a metric with which to evaluate 
  5198.      the degree of trust that can be placed in ...
  5199.  
  5200.      To provide a basis for specifying security requirements in 
  5201.      acquisition specifications.
  5202.  
  5203. With respect to the 
  5204.  
  5205.         >second
  5206.  
  5207. purpose for development of the criteria, i.e., providing
  5208.  
  5209.         >DoD components 
  5210.  
  5211. with a security evaluation metric, evaluations can be
  5212. delineated into two types: (a) an evaluation can be
  5213. performed on a computer product from a perspective that
  5214. excludes the application environment; or, (b) it can be
  5215. done to assess whether appropriate security measures ...
  5216.  
  5217. The latter type of evaluation, i.e., those done for the purpose 
  5218. of assessing a system's security attributes with respect to a 
  5219. specific operational mission, is known as a certification 
  5220. evaluation.  It must be understood that the completion of a 
  5221. formal product evaluation does not constitute certification or 
  5222. accreditation for the system to be used in any specific 
  5223. application environment.  On the contrary, the evaluation report 
  5224. only provides a trusted computer system's evaluation rating along 
  5225. with supporting data describing the product system's strengths 
  5226. and weaknesses from a computer security point of view.  The 
  5227. system security certification and the formal 
  5228. approval/accreditation procedure, done in accordance with the 
  5229. applicable policies of the issuing agencies, must still be 
  5230. followed before a system can be approved for use in processing or 
  5231. handling classified information.,8;9.  
  5232.  
  5233.         >Designated Approving Authorities (DAAs) remain ultimately
  5234.         >responsible for specifying security of systems they
  5235.         >accredit.      
  5236.  
  5237. The trusted computer system evaluation criteria will be used 
  5238. directly and indirectly in the certification process.  Along with 
  5239. applicable policy, it will be used directly as 
  5240.  
  5241.         >technical guidance
  5242.  
  5243. for evaluation of the total system and for specifying system
  5244. security and certification requirements for new acquisitions.  Where
  5245. a system being evaluated for certification employs a product that 
  5246. has undergone a Commercial Product Evaluation, reports from that 
  5247. process will be used as input to the certification evaluation. 
  5248. Technical data will be furnished to designers, evaluators and the 
  5249. Designated Approving Authorities to support their needs for 
  5250. making decisions.
  5251.  
  5252.  
  5253.                                      
  5254.      2.1.4.3  Test Documentation
  5255.  
  5256.           The system developer will provide to the evaluators a 
  5257.           document that describes the test plan, 
  5258.  
  5259.             >test procedures that show how the security mechanisms were tested,
  5260.  
  5261.           and results of the security mechanisms' functional testing.
  5262.  
  5263.  
  5264.  
  5265.  
  5266. Changed Section 2.2.1.1 as follows:  
  5267.  
  5268.      2.2.1.1  Discretionary Access Control
  5269.  
  5270.           The TCB shall define and control access between named 
  5271.           users and named objects (e.g., files and programs) in 
  5272.           the ADP system.  The enforcement mechanism (e.g., 
  5273.           self/group/public controls, access control lists) shall 
  5274.           allow users to specify and control sharing of those 
  5275.           objects by named individuals, or defined groups of 
  5276.           individuals, or by both, 
  5277.  
  5278.                 >and shall provide controls to 
  5279.                 >limit propagation of access rights.  
  5280.  
  5281.           The discretionary access control mechanism shall,
  5282.           either by explicit user action or by default, provide that
  5283.         objects are protected from unauthorized access.  These
  5284.         access controls shall be capable of including or excluding
  5285.         access to the granularity of a single user.  Access
  5286.         permission to an object by users not already possessing
  5287.         access permission shall only be assigned by authorized
  5288.         users.
  5289.  
  5290.                                      
  5291.  
  5292. Completely Reworded Section 2.2.1.2 as follows:  
  5293.  
  5294.      2.2.1.2  Object Reuse
  5295.  
  5296.  
  5297.           All authorizations to the information contained within 
  5298.           a storage object shall be revoked prior to initial 
  5299.           assignment, allocation or reallocation to a subject 
  5300.           from the TCB's pool of unused storage objects.  No 
  5301.           information, including encrypted representations of 
  5302.           information, produced by a prior subject's actions is 
  5303.           to be available to any subject that obtains access to 
  5304.           an object that has been released back to the system.  
  5305.  
  5306.  
  5307.                                      
  5308.  
  5309. Reworded Section 2.2.2.2 as follows:  
  5310.  
  5311.      2.2.2.2  Audit
  5312.  
  5313.           The TCB shall be able to create, maintain, and protect 
  5314.           from modification or unauthorized access or destruction 
  5315.           an audit trail of accesses to the objects it protects. 
  5316.           The audit data shall be protected by the TCB so that 
  5317.           read access to it is limited to those who are 
  5318.           authorized for audit data.  The TCB shall be able to 
  5319.           record the following types of events:  use of 
  5320.           identification and authentication mechanisms, 
  5321.           introduction of objects into a user's address space 
  5322.           (e.g., file open, program initiation), deletion of 
  5323.           objects, actions taken by computer operators and system 
  5324.           administrators and/or system security officers, 
  5325.  
  5326.                 >and other security relevant events.
  5327.  
  5328.           For each recorded event, the audit record shall
  5329.         identify: date and time of the event, user, type of event,
  5330.         and success or failure of the event.  For
  5331.         identification/authentication events the origin of request
  5332.         (e.g., terminal ID) shall be included in the audit record.
  5333.         For events that introduce an object into a user's address
  5334.         space and for object deletion events the audit record shall
  5335.         include the name of the object.  The ADP system
  5336.         administrator shall be able to selectively audit the
  5337.         actions of any one or more users based on individual
  5338.         identity.
  5339.  
  5340.                                      
  5341.  
  5342.  
  5343.  
  5344. Changed Section 2.2.4.3 as follows: 
  5345.  
  5346.     2.2.4.3  Test Documentation
  5347.  
  5348.           The system developer will provide to the evaluators a 
  5349.           document that describes the test plan, 
  5350.  
  5351.                 >test procedures that show how the
  5352.                 >security mechanisms were tested, 
  5353.  
  5354.           and results of the security mechanisms' functional testing.
  5355.  
  5356.  
  5357.  
  5358. Changed Section 3.1.1.1 as follows: 
  5359.  
  5360.      3.1.1.1  Discretionary Access Control
  5361.  
  5362.           The TCB shall define and control access between named 
  5363.           users and named objects (e.g., files and programs) in 
  5364.           the ADP system.  The enforcement mechanism (e.g., 
  5365.           self/group/public controls, access control lists) shall 
  5366.           allow users to specify and control sharing of those 
  5367.           objects by named individuals, or defined groups of 
  5368.           individuals, or by both, 
  5369.  
  5370.                 >and shall provide controls to 
  5371.                   >limit propagation of access rights.
  5372.  
  5373.           The discretionary access control mechanism shall,
  5374.         either by explicit user action or by default, provide that
  5375.         objects are protected from unauthorized access.  These
  5376.         access controls shall be capable of including or excluding
  5377.         access to the granularity of a single user.  Access
  5378.         permission to an object by users not already possessing
  5379.         access permission shall only be assigned by authorized
  5380.         users.
  5381.  
  5382.                                      
  5383.  
  5384. Completely reworded Section 3.1.1.2 as follows:  
  5385.  
  5386.      3.1.1.2  Object Reuse
  5387.  
  5388.           All authorizations to the information contained within 
  5389.           a storage object shall be revoked prior to initial 
  5390.           assignment, allocation or reallocation to a subject 
  5391.           from the TCB's pool of unused storage objects.  No 
  5392.           information, including encrypted representations of 
  5393.           information, produced by a prior subject's actions is 
  5394.           to be available to any subject that obtains access to 
  5395.           an object that has been released back to the system.  
  5396.  
  5397.  
  5398.  
  5399.  
  5400. Changed Section 3.1.1.3.2 as follows: 
  5401.  
  5402.           3.1.1.3.2  Exportation of Labeled Information
  5403.  
  5404.                The TCB shall designate each communication channel 
  5405.                and I/O device as either single-level or 
  5406.                multilevel.  Any change in this designation shall 
  5407.                be done manually and shall be auditable by the 
  5408.                TCB.  The TCB shall maintain and be able to audit 
  5409.                any change in the /current/ security level or 
  5410.                levels associated with a /single-level/ communication 
  5411.                channel or I/O device.
  5412.  
  5413.  
  5414. Appended a sentence to Section 3.1.1.4 as follows:
  5415.  
  5416.                 3.1.1.4  Mandatory Access Control
  5417.  
  5418.                 ... Identification and authentication data shall be used
  5419.                     by the TCB to authenticate the user's identity 
  5420.                 and to ensure that the security level and authorization
  5421.                 of subjects external to the TCB that may be created to
  5422.                 act on behalf of the individual user are dominated by
  5423.                 the clearance and authorization of that user.
  5424.  
  5425.  
  5426. Changed one sentence in Section 3.1.2.1 as follows:
  5427.  
  5428.                 3.1.2.1.  Identification and Authentication
  5429.  
  5430.                 ... This data shall be used by the TCB to authenticate
  5431.                 the user's identity and /to determine/ 
  5432.  
  5433.                         >to ensure that
  5434.  
  5435.                 the security level and authorizations of subjects
  5436.  
  5437.                         >external to the TCB 
  5438.  
  5439.                 that may be created to act on
  5440.                 behalf of the individual user 
  5441.  
  5442.                         >are dominated by the clearance 
  5443.                         >and authorization of that user.                 
  5444.                    
  5445.                                      
  5446. Reworded Section 3.1.2.2 as follows: 
  5447.  
  5448.      3.1.2.2  Audit
  5449.  
  5450.           The TCB shall be able to create, maintain, and protect 
  5451.           from modification or unauthorized access or destruction 
  5452.           an audit trail of accesses to the objects it protects. 
  5453.           The audit data shall be protected by the TCB so that 
  5454.           read access to it is limited to those who are 
  5455.           authorized for audit data.  The TCB shall be able to 
  5456.           record the following types of events:  use of 
  5457.           identification and authentication mechanisms, 
  5458.           introduction of objects into a user's address space 
  5459.           (e.g., file open, program initiation), deletion of 
  5460.           objects, actions taken by computer operators and system 
  5461.           administrators and/or system security officers,
  5462.  
  5463.                 > and other security relevant events. 
  5464.  
  5465.         The TCB shall also be able to audit any override
  5466.         of human-readable output markings.  For each recorded
  5467.         event, the audit record shall identify: date and time of
  5468.         the event, user, type of event, and success or failure of
  5469.         the event.  For identification/authentication events the
  5470.         origin of request (e.g., terminal ID) shall be included in
  5471.         the audit record.  For events that introduce an object into
  5472.         a user's address space and for object deletion events the
  5473.         audit record shall include the name of the object and the
  5474.         object's security level.  The ADP system administrator
  5475.         shall be able to selectively audit the actions of any one
  5476.         or more users based on individual identity and/or object
  5477.         security level.
  5478.  
  5479.  
  5480. 'Unbolded' the first sentence of Section 3.1.3.2.1.
  5481.  
  5482.  
  5483. Reworded Section 3.1.3.2.2 as follows: 
  5484.  
  5485.           3.1.3.2.2  Design Specification and Verification
  5486.  
  5487.                An informal or formal model of the security policy 
  5488.                supported by the TCB shall be maintained  
  5489.  
  5490.                 >over the life cycle of the ADP system and demonstrated 
  5491.  
  5492.              to be consistent with its axioms.
  5493.  
  5494.  
  5495. Changed sentence as follows: 
  5496.  
  5497.      3.1.4.3  Test Documentation
  5498.  
  5499.           The system developer will provide to the evaluators a 
  5500.           document that describes the test plan, 
  5501.  
  5502.                 >test procedures that show how the security 
  5503.                 >mechanisms were tested, 
  5504.  
  5505.         and results of the security mechanisms' functional testing.
  5506.  
  5507.  
  5508. Changed Section 3.2.1.1 as follows: 
  5509.  
  5510.      3.2.1.1  Discretionary Access Control
  5511.  
  5512.           The TCB shall define and control access between named 
  5513.           users and named objects (e.g., files and programs) in 
  5514.           the ADP system.  The enforcement mechanism (e.g., 
  5515.           self/group/public controls, access control lists) shall 
  5516.           allow users to specify and control sharing of those 
  5517.           objects by named individuals, or defined groups of 
  5518.           individuals, or by both, 
  5519.  
  5520.                 >and shall provide controls to 
  5521.                 >limit propagation of access rights.  
  5522.  
  5523.         The discretionary access control mechanism shall,
  5524.         either by explicit user action or by default, provide that
  5525.         objects are protected from unauthorized access.  These
  5526.         access controls shall be capable of including or excluding
  5527.         access to the granularity of a single user.  Access
  5528.         permission to an object by users not already possessing
  5529.         access permission shall only be assigned by authorized
  5530.         users.
  5531.  
  5532.                                      
  5533. Completely reworded Section 3.2.1.2 as follows: 
  5534.  
  5535.      3.2.1.2  Object Reuse
  5536.  
  5537.           All authorizations to the information contained within 
  5538.           a storage object shall be revoked prior to initial 
  5539.           assignment, allocation or reallocation to a subject 
  5540.           from the TCB's pool of unused storage objects.  No 
  5541.           information, including encrypted representations of 
  5542.           information, produced by a prior subject's actions is 
  5543.           to be available to any subject that obtains access to 
  5544.           an object that has been released back to the system.  
  5545.  
  5546.  
  5547.  
  5548.  
  5549. Changed Section 3.2.1.3 as follows: 
  5550.  
  5551.      3.2.1.3  Labels
  5552.  
  5553.           Sensitivity labels associated with each ADP system 
  5554.           resource (e.g., subject, storage object, ROM) that is 
  5555.           directly or indirectly accessible by subjects external 
  5556.           to the TCB shall be maintained by the TCB.  These 
  5557.           labels shall be used as the basis for mandatory access 
  5558.           control decisions.  In order to import non-labeled 
  5559.           data, the TCB shall request and receive from an 
  5560.           authorized user the security level of the data, and all 
  5561.           such actions shall be auditable by the TCB.
  5562.  
  5563.                                      
  5564.  
  5565. Changed Section 3.2.1.3.2 as follows: 
  5566.  
  5567.           3.2.1.3.2  Exportation of Labeled Information
  5568.  
  5569.                The TCB shall designate each communication channel 
  5570.                and I/O device as either single-level or 
  5571.                multilevel.  Any change in this designation shall 
  5572.                be done manually and shall be auditable by the 
  5573.                TCB.  The TCB shall maintain and be able to audit 
  5574.                any change in the /current/ security level or 
  5575.                levels associated with a /single-level/ 
  5576.                communication channel or I/O device.
  5577.  
  5578.  
  5579. Appended Sectence to Section 3.2.1.4 as follows:
  5580.  
  5581.                 3.2.1.4  Mandatory Access Control
  5582.  
  5583.                 ... Identification and authentication data shall be
  5584.                 used by the TCB to authenticate the user's identity
  5585.                 and to ensure that the security level and authorization
  5586.                 of subjects external to the TCB that may be created to
  5587.                 act on behalf of the individual user are dominated by
  5588.                 the clearance and authorization of that user.
  5589.  
  5590. Changed Section 3.2.2.1 as follows:
  5591.  
  5592.                 3.2.2.1  Identification and Authentication
  5593.  
  5594.                 ... This data shall be used by the TCB to authenticate
  5595.                 the user's identity and /to determine/
  5596.  
  5597.                         >to ensure that
  5598.  
  5599.                 the security level and authorizations of subjects
  5600.  
  5601.                         >external to the TCB 
  5602.  
  5603.                 that may be created to act on
  5604.                 behalf of the individual user 
  5605.  
  5606.                         >are dominated by the clearance
  5607.                         >and authorization of that user.                 
  5608.             
  5609.  
  5610.                                      
  5611. Reworded section 3.2.2.2 as follows:  
  5612.  
  5613.      3.2.2.2  Audit
  5614.  
  5615.           The TCB shall be able to create, maintain, and protect 
  5616.           from modification or unauthorized access or destruction 
  5617.           an audit trail of accesses to the objects it protects. 
  5618.           The audit data shall be protected by the TCB so that 
  5619.           read access to it is limited to those who are 
  5620.           authorized for audit data.  The TCB shall be able to 
  5621.           record the following types of events:  use of 
  5622.           identification and authentication mechanisms, 
  5623.           introduction of objects into a user's address space 
  5624.           (e.g., file open, program initiation), deletion of 
  5625.           objects, actions taken by computer operators and system 
  5626.           administrators and/or system security officers, 
  5627.  
  5628.                 >and other security relevant events. 
  5629.  
  5630.         The TCB shall also be able to audit any override
  5631.         of human-readable output markings.  For each recorded
  5632.         event, the audit record shall identify: date and time of
  5633.         the event, user, type of event, and success or failure of
  5634.         the event.  For identification/authentication events the
  5635.         origin of request (e.g., terminal ID) shall be included in
  5636.         the audit record.  For events that introduce an object into
  5637.         a user's address space and for object deletion events the
  5638.         audit record shall include the name of the object and the
  5639.         object's security level.  The ADP system administrator
  5640.         shall be able to selectively audit the actions of any one
  5641.         or more users based on individual identity and/or object
  5642.         security level.  The TCB shall be able to audit the
  5643.         identified events that may be used in the exploitation of
  5644.         covert storage channels.
  5645.  
  5646.                                      
  5647.  
  5648. Changed Section 3.2.3.2.2 as follows: 
  5649.  
  5650.           3.2.3.2.2  Design Specification and Verification
  5651.  
  5652.                A formal model of the security policy supported by 
  5653.                the TCB shall be maintained 
  5654.  
  5655.                 >over the life cycle of the ADP system 
  5656.  
  5657.                that is proven consistent with its 
  5658.                axioms.  A descriptive top-level specification 
  5659.                (DTLS) of the TCB shall be maintained that 
  5660.                completely and accurately describes the TCB in 
  5661.                terms of exceptions, error messages, and effects. 
  5662.                It shall be shown to be an accurate description of 
  5663.                the TCB interface.
  5664.  
  5665.  
  5666.  
  5667. Changed Section 3.2.4.3 as follows: 
  5668.  
  5669.      3.2.4.3  Test Documentation
  5670.  
  5671.           The system developer shall provide to the evaluators a 
  5672.           document that describes the test plan, 
  5673.  
  5674.                 >test procedures that show how the 
  5675.                 >security mechanisms were tested, 
  5676.  
  5677.         and results of the security mechanisms' functional testing. 
  5678.           It shall include results of testing the effectiveness 
  5679.           of the methods used to reduce covert channel 
  5680.           bandwidths.
  5681.  
  5682.                                      
  5683.  
  5684. Replaced "tamperproof" with "tamper resistant":  
  5685.  
  5686.      3.2.4.4  Design Documentation
  5687.  
  5688.           Documentation shall be available that provides a 
  5689.           description of the manufacturer's philosophy of 
  5690.           protection and an explanation of how this philosophy is 
  5691.           translated into the TCB.  The interfaces between the 
  5692.           TCB modules shall be described.  A formal description 
  5693.           of the security policy model enforced by the TCB shall 
  5694.           be available and proven that it is sufficient to 
  5695.           enforce the security policy.  The specific TCB 
  5696.           protection mechanisms shall be identified and an 
  5697.           explanation given to show that they satisfy the model. 
  5698.           The descriptive top-level specification (DTLS) shall be 
  5699.           shown to be an accurate description of the TCB 
  5700.           interface.  Documentation shall describe how the TCB 
  5701.           implements the reference monitor concept and give an 
  5702.           explanation why it is 
  5703.  
  5704.                 >tamper resistant, 
  5705.  
  5706.         cannot be bypassed, and is correctly implemented.
  5707.         Documentation shall describe how the TCB is structured to
  5708.         facilitate testing and to enforce least privilege.  This
  5709.         documentation shall also present the results of the covert
  5710.         channel analysis and the tradeoffs involved in restricting
  5711.         the channels.  All auditable events that may be used in the
  5712.         exploitation of known covert storage channels shall be
  5713.         identified.  The bandwidths of known covert storage
  5714.         channels, the use of which is not detectable by the
  5715.         auditing mechanisms, shall be provided.  (See the Covert
  5716.         Channel Guideline section.)
  5717.  
  5718.                                      
  5719.  
  5720. Changed Section 3.3.1.1 as follows: 
  5721.  
  5722.      3.3.1.1  Discretionary Access Control
  5723.  
  5724.           The TCB shall define and control access between named 
  5725.           users and named objects (e.g., files and programs) in 
  5726.           the ADP system.  The enforcement mechanism (e.g., 
  5727.           access control lists) shall allow users to specify and 
  5728.           control sharing of those objects, 
  5729.  
  5730.                 >and shall provide controls to limit 
  5731.                 >propagation of access rights.  
  5732.  
  5733.         The discretionary access control mechanism shall, either by 
  5734.           explicit user action or by default, provide that 
  5735.           objects are protected from unauthorized access.  These 
  5736.           access controls shall be capable of specifying, for 
  5737.           each named object, a list of named individuals and a 
  5738.           list of groups of named individuals with their 
  5739.           respective modes of access to that object. 
  5740.           Furthermore, for each such named object, it shall be 
  5741.           possible to specify a list of named individuals and a 
  5742.           list of groups of named individuals for which no access 
  5743.           to the object is to be given.  Access permission to an 
  5744.           object by users not already possessing access 
  5745.           permission shall only be assigned by authorized users.
  5746.  
  5747.  
  5748.  
  5749. Completely reworded Section 3.3.1.2 as follows:  
  5750.  
  5751.      3.3.1.2  Object Reuse
  5752.  
  5753.           All authorizations to the information contained within 
  5754.           a storage object shall be revoked prior to initial 
  5755.           assignment, allocation or reallocation to a subject 
  5756.           from the TCB's pool of unused storage objects.  No 
  5757.           information, including encrypted representations of 
  5758.           information, produced by a prior subject's actions is 
  5759.           to be available to any subject that obtains access to 
  5760.           an object that has been released back to the system.  
  5761.  
  5762.  
  5763.  
  5764.  
  5765. Changed Section 3.3.1.3 as follows: 
  5766.  
  5767.      3.3.1.3  Labels
  5768.  
  5769.           Sensitivity labels associated with each ADP system 
  5770.           resource (e.g., subject, storage object, ROM) that is 
  5771.           directly or indirectly accessible by subjects external 
  5772.           to the TCB shall be maintained by the TCB.  These 
  5773.           labels shall be used as the basis for mandatory access 
  5774.           control decisions.  In order to import non-labeled 
  5775.           data, the TCB shall request and receive from an 
  5776.           authorized user the security level of the data, and all 
  5777.           such actions shall be auditable by the TCB.
  5778.  
  5779.  
  5780.                                      
  5781. Changed Section 3.3.1.3.2 as follows: 
  5782.  
  5783.           3.3.1.3.2  Exportation of Labeled Information
  5784.  
  5785.                The TCB shall designate each communication channel 
  5786.                and I/O device as either single-level or 
  5787.                multilevel.  Any change in this designation shall 
  5788.                be done manually and shall be auditable by the 
  5789.                TCB.  The TCB shall maintain and be able to audit 
  5790.                any change in the /current/ security level or 
  5791.                levels associated with a /single-level/ 
  5792.                communication channel or I/O device.
  5793.                                      
  5794.  
  5795. Appended Sentence to Section 3.3.1.4 as follows:
  5796.  
  5797.                 3.3.1.4  Mandatory Access Control
  5798.  
  5799.                 ... Identification and authentication data shall be used
  5800.                     by the TCB to authenticate the user's identity 
  5801.                 and to ensure that the security level and authorization
  5802.                 of subjects external to the TCB that may be created to
  5803.                 act on behalf of the individual user are dominated by
  5804.                 the clearance and authorization of that user.
  5805.  
  5806.  
  5807.  
  5808. Changed Section 3.3.2.1 as follows:
  5809.  
  5810.                 3.3.2.1  Identification and Authentication
  5811.  
  5812.                 ... This data shall be used by the TCB to authenticate
  5813.                 the user's identity and /to determine/ 
  5814.  
  5815.                         >to ensure that
  5816.  
  5817.                 the security level and authorizations of subjects
  5818.  
  5819.                         >external to the TCB 
  5820.  
  5821.                 that may be created to act on
  5822.                 behalf of the individual user 
  5823.  
  5824.                         >are dominated by the clearance 
  5825.                         >and authorization of that user.                 
  5826.             
  5827.  
  5828.  
  5829.                                      
  5830. Changed Section 3.3.2.2 as follows: 
  5831.  
  5832.      3.3.2.2  Audit
  5833.  
  5834.           The TCB shall be able to create, maintain, and protect 
  5835.           from modification or unauthorized access or destruction 
  5836.           an audit trail of accesses to the objects it protects. 
  5837.           The audit data shall be protected by the TCB so that 
  5838.           read access to it is limited to those who are 
  5839.           authorized for audit data.  The TCB shall be able to 
  5840.           record the following types of events:  use of 
  5841.           identification and authentication mechanisms, 
  5842.           introduction of objects into a user's address space 
  5843.           (e.g., file open, program initiation), deletion of 
  5844.           objects, actions taken by computer operators and system 
  5845.           administrators and/or system security officers, 
  5846.         
  5847.                 >and other security relevant events.  
  5848.         
  5849.         The TCB shall also be able to audit any override
  5850.         of human-readable output markings.  For each recorded
  5851.         event, the audit record shall identify: date and time of
  5852.         the event, user, type of event, and success or failure of
  5853.         the event.  For identification/authentication events the
  5854.         origin of request (e.g., terminal ID) shall be included in
  5855.         the audit record.  For events that introduce an object into
  5856.         a user's address space and for object deletion events the
  5857.         audit record shall include the name of the object and the
  5858.         object's security level.  The ADP system administrator
  5859.         shall be able to selectively audit the actions of any one
  5860.         or more users based on individual identity and/or object
  5861.         security level.  The TCB shall be able to audit the
  5862.         identified events that may be used in the exploitation of
  5863.         covert storage channels.  The TCB shall contain a mechanism
  5864.         that is able to monitor the occurrence or accumulation of
  5865.         security auditable events that may indicate an imminent
  5866.         violation of security policy.  This mechanism shall be able
  5867.         to immediately notify the security administrator when
  5868.         thresholds are exceeded, 
  5869.  
  5870.                 >and if the occurrence or accumulation
  5871.                 >of these security relevant events continues, 
  5872.                 >the system shall take the least disruptive 
  5873.                 >action to terminate the event.
  5874.  
  5875.  
  5876. Changed the first sentence of Section 3.3.3.2.2 as follows:
  5877.  
  5878.         3.3.3.2.2  Design Specification and Verification
  5879.  
  5880.                 A formal model of the security policy supported by
  5881.                 the TCB shall be maintained 
  5882.  
  5883.                         >over the life cycle of
  5884.                         >the ADP system 
  5885.  
  5886.                 that is proven consistent with its axioms. ...
  5887.  
  5888. Changed Section 3.3.4.3 as follows:  
  5889.  
  5890.      3.3.4.3  Test Documentation
  5891.  
  5892.           The system developer shall provide to the evaluators a 
  5893.           document that describes the test plan, 
  5894.  
  5895.                 >test procedures that show how the 
  5896.                 >security mechanisms were tested, 
  5897.  
  5898.         and results of the security mechanisms' functional testing. 
  5899.           It shall include results of testing the effectiveness 
  5900.           of the methods used to reduce covert channel 
  5901.           bandwidths.
  5902.  
  5903. Replaced "tamperproof" with "tamper resistant" in Section 3.3.4.4.
  5904.  
  5905.                                      
  5906.  
  5907. Changed Section 4.1.1.1 as follows:  
  5908.  
  5909.      4.1.1.1  Discretionary Access Control
  5910.  
  5911.           The TCB shall define and control access between named 
  5912.           users and named objects (e.g., files and programs) in 
  5913.           the ADP system.  The enforcement mechanism (e.g., 
  5914.           access control lists) shall allow users to specify and 
  5915.           control sharing of those objects, 
  5916.  
  5917.                 >and shall provide controls to 
  5918.                 >limit propagation of access rights.  
  5919.  
  5920.         The discretionary access control mechanism shall, either by 
  5921.           explicit user action or by default, provide that 
  5922.           objects are protected from unauthorized access.  These 
  5923.           access controls shall be capable of specifying, for 
  5924.           each named object, a list of named individuals and a 
  5925.           list of groups of named individuals with their 
  5926.           respective modes of access to that object. 
  5927.           Furthermore, for each such named object, it shall be 
  5928.           possible to specify a list of named individuals and a 
  5929.           list of groups of named individuals for which no access 
  5930.           to the object is to be given.  Access permission to an 
  5931.           object by users not already possessing access 
  5932.           permission shall only be assigned by authorized users.
  5933.                                      
  5934.  
  5935.  
  5936. Completely reworded Section 4.1.1.2 as follows:  
  5937.  
  5938.      4.1.1.2  Object Reuse
  5939.  
  5940.           All authorizations to the information contained within 
  5941.           a storage object shall be revoked prior to initial 
  5942.           assignment, allocation or reallocation to a subject 
  5943.           from the TCB's pool of unused storage objects.  No 
  5944.           information, including encrypted representations of 
  5945.           information, produced by a prior subject's actions is 
  5946.           to be available to any subject that obtains access to 
  5947.           an object that has been released back to the system.  
  5948.  
  5949.  
  5950.  
  5951.  
  5952. Changed Section 4.1.1.3 as follows:  
  5953.  
  5954.      4.1.1.3  Labels
  5955.  
  5956.           Sensitivity labels associated with each ADP system 
  5957.           resource (e.g., subject, storage object, 
  5958.  
  5959.                 >ROM) 
  5960.  
  5961.         that is directly or indirectly accessible by subjects 
  5962.         external to the TCB shall be maintained by the TCB.  These 
  5963.           labels shall be used as the basis for mandatory access 
  5964.           control decisions.  In order to import non-labeled 
  5965.           data, the TCB shall request and receive from an 
  5966.           authorized user the security level of the data, and all 
  5967.           such actions shall be auditable by the TCB.
  5968.  
  5969.                                      
  5970.  
  5971. Changed Section 4.1.1.3.2 as follows: 
  5972.  
  5973.           4.1.1.3.2  Exportation of Labeled Information
  5974.  
  5975.                The TCB shall designate each communication channel 
  5976.                and I/O device as either single-level or 
  5977.                multilevel.  Any change in this designation shall 
  5978.                be done manually and shall be auditable by the 
  5979.                TCB.  The TCB shall maintain and be able to audit 
  5980.                any change in the /current/ security level 
  5981.  
  5982.                 >or levels 
  5983.  
  5984.              associated with a /single-level/ 
  5985.                communication channel or I/O device.
  5986.  
  5987.  
  5988. Appended Sentence to Section 4.1.1.4 as follows:
  5989.  
  5990.                 4.1.1.4  Mandatory Access Control
  5991.  
  5992.                 ... Identification and authentication data shall be used
  5993.                 by the TCB to authenticate the user's identity 
  5994.                 and to ensure that the security level and authorization 
  5995.                 of subjects external to the TCB that may be created to 
  5996.                 act on behalf of the individual user are dominated by 
  5997.                 the clearance and authorization of that user.
  5998.  
  5999.  
  6000.  
  6001. Changed Section 4.1.2.1 as follows:
  6002.  
  6003.                 4.1.2.1  Identification and Authentication
  6004.  
  6005.                 ... This data shall be used by the TCB to authenticate
  6006.                 the user's identity and /to determine/ 
  6007.  
  6008.                         >to ensure that
  6009.  
  6010.                 the security level and authorizations of subjects
  6011.  
  6012.                         >external to the TCB 
  6013.  
  6014.                 that may be created to act on
  6015.                 behalf of the individual user 
  6016.  
  6017.                         >are dominated by the clearance 
  6018.                         >and authorization of that user.                 
  6019.                
  6020.  
  6021.  
  6022. Changed Section 4.1.2.2 as follows: 
  6023.  
  6024.  
  6025.      4.1.2.2  Audit
  6026.  
  6027.           The TCB shall be able to create, maintain, and protect 
  6028.           from modification or unauthorized access or destruction 
  6029.           an audit trail of accesses to the objects it protects. 
  6030.           The audit data shall be protected by the TCB so that 
  6031.           read access to it is limited to those who are 
  6032.           authorized for audit data.  The TCB shall be able to 
  6033.           record the following types of events:  use of 
  6034.           identification and authentication mechanisms, 
  6035.           introduction of objects into a user's address space 
  6036.           (e.g., file open, program initiation), deletion of 
  6037.           objects, actions taken by computer operators and system 
  6038.           administrators and/or system security officers, 
  6039.  
  6040.                 >and other security relevant events.  
  6041.  
  6042.         The TCB shall also be able to audit any override
  6043.         of human-readable output markings.  For each recorded
  6044.         event, the audit record shall identify: date and time of
  6045.         the event, user, type of event, and success or failure of
  6046.         the event.  For identification/authentication events the
  6047.         origin of request (e.g., terminal ID) shall be included in
  6048.         the audit record.  For events that introduce an object into
  6049.         a user's address space and for object deletion events the
  6050.         audit record shall include the name of the object and the
  6051.         object's security level.  The ADP system administrator
  6052.         shall be able to selectively audit the actions of any one
  6053.         or more users based on individual identity and/or object
  6054.         security level.  The TCB shall be able to audit the
  6055.         identified events that may be used in the exploitation of
  6056.         covert storage channels.  The TCB shall contain a mechanism
  6057.         that is able to monitor the occurrence or accumulation of
  6058.         security auditable events that may indicate an imminent
  6059.         violation of security policy.  This mechanism shall be able
  6060.         to immediately notify the security administrator when
  6061.         thresholds are exceeded, 
  6062.  
  6063.                 >and, if the occurrence or accumulation of these 
  6064.                 >security relevant events continues, the system 
  6065.                 >shall take the least disruptive action to
  6066.                 >terminate the event.
  6067.  
  6068.                                      
  6069. 'Unbolded' the words "covert channels" in Section 4.1.3.1.3.
  6070.  
  6071.  
  6072. Changed the first sentence of Section 4.1.3.2.2 as follows:
  6073.  
  6074.         4.1.3.2.2  Design Specification and Verification
  6075.  
  6076.                 A formal model of the security policy supported by
  6077.                 the TCB shall be maintained 
  6078.  
  6079.                         >over the life cycle of the ADP system 
  6080.  
  6081.                 that is proven consistent with its axioms. ...
  6082.  
  6083.  
  6084.  
  6085. Changed Section 4.1.4.3 as follows: 
  6086.  
  6087.      4.1.4.3  Test Documentation
  6088.  
  6089.           The system developer shall provide to the evaluators a 
  6090.           document that describes the test plan, 
  6091.  
  6092.                 >test procedures that show how the security 
  6093.                 >mechanisms were tested, and 
  6094.  
  6095.           results of the security mechanisms' functional testing. 
  6096.           It shall include results of testing the effectiveness 
  6097.           of the methods used to reduce covert channel 
  6098.           bandwidths.  The results of the mapping between the 
  6099.           formal top-level specification and the TCB source code 
  6100.           shall be given.
  6101.  
  6102.  
  6103.  
  6104. Replaced "tamperproof" with "tamper resistant" in Section 4.1.4.4.
  6105.  
  6106.  
  6107. Changed the last paragraph of Section 5.1 as follows:
  6108.  
  6109.                                      
  6110. 5.1  A Need for Consensus
  6111.  
  6112.      A major goal of ... 
  6113.  
  6114.      As described ... 
  6115.  
  6116.         >The Purpose of this section is to describe in detail the 
  6117.         >fundamental control objectives.  These objectives lay the 
  6118.         >foundation for the requirements outlined in the criteria. 
  6119.  
  6120.      The goal is to explain the foundations so that those outside 
  6121.      the National Security Establishment can assess their 
  6122.      universality and, by extension, the universal applicability 
  6123.      of the criteria requirements to processing all types of 
  6124.      sensitive applications whether they be for National Security 
  6125.      or the private sector.
  6126.  
  6127.  
  6128.  
  6129. Changed the second paragraph of Section 6.2 as follows:
  6130.  
  6131. 6.2  A Formal Policy Model
  6132.  
  6133.         Following the publication of ...
  6134.  
  6135.                 >A subject can act on behalf of a user or another 
  6136.                 >subject.  The subject is created as a surrogate 
  6137.                 >for the cleared user and is assigned a formal 
  6138.                 >security level based on their classification.
  6139.                 >The state transitions and invariants of the formal 
  6140.                 >policy model define the invariant relationships 
  6141.                 >that must hold between the clearance of the user, 
  6142.                 >the formal security level of any process that can 
  6143.                 >act on the user's behalf, and the formal security 
  6144.                 >level of the devices and other objects to which any 
  6145.                 >process can obtain specific modes of access.  
  6146.  
  6147.         The Bell and LaPadula model, 
  6148.  
  6149.                 >for example, 
  6150.  
  6151.         defines a relationship between 
  6152.  
  6153.                 >formal security levels of subjects and objects, 
  6154.  
  6155.         now referenced as the "dominance relation."  From this definition ...
  6156.         ... Both the Simple Security Condition and the *-Property 
  6157.         include mandatory security provisions based on the dominance
  6158.         relation between the 
  6159.  
  6160.                 >formal security levels of subjects and objects.  
  6161.  
  6162.         The Discretionary Security Property ...
  6163.  
  6164.                                      
  6165.  
  6166.  
  6167. Added a sentence to the end of Section 7.0: 
  6168.  
  6169.  
  6170. 7.0  THE RELATIONSHIP BETWEEN POLICY AND THE CRITERIA
  6171.  
  6172.      Section 1 presents fundamental computer security 
  6173.      requirements and Section 5 presents the control objectives 
  6174.      for Trusted Computer Systems.  They are general 
  6175.      requirements, useful and necessary, for the development of 
  6176.      all secure systems.  However, when designing systems that 
  6177.      will be used to process classified or other sensitive 
  6178.      information, functional requirements for meeting the Control 
  6179.      Objectives become more specific.  There is a large body of 
  6180.      policy laid down in the form of Regulations, Directives, 
  6181.      Presidential Executive Orders, and OMB Circulars that form 
  6182.      the basis of the procedures for the handling and processing 
  6183.      of Federal information in general and classified information 
  6184.      specifically.  This section presents pertinent excerpts from 
  6185.      these policy statements and discusses their relationship to 
  6186.      the Control Objectives.  
  6187.  
  6188.         >These excerpts are examples to illustrate the relationship 
  6189.         >of the policies to criteria and may not be complete.
  6190.  
  6191.  
  6192.  
  6193.                                      
  6194. Inserted the following 
  6195.  
  6196.         >as the next to last paragraph 
  6197.  
  6198. of Section 7.2:    
  6199.  
  6200.         >DoD Directive 5200.28 provides the security requirements for 
  6201.         >ADP systems.  For some types of information, such as 
  6202.         >Sensitive Compartmented Information (SCI), DoD Directive 
  6203.         >5200.28 states that other minimum security requirements also 
  6204.         >apply.  These minima are found in DCID 1/16 (new reference 
  6205.         >number 5) which is implemented in DIAM 50-4 (new reference 
  6206.         >number 6) for DoD and DoD contractor ADP systems.
  6207.  
  6208.      From requirements imposed by ... 
  6209.  
  6210.  
  6211. Changed Footnote #1 referenced by Section 7.2 as follows:
  6212.  
  6213.         Replaced "Health and Human Services Department" with "U.S. 
  6214.         Information Agency."
  6215.  
  6216.  
  6217.  
  6218. Changed (updated) the quote from DoD 5220.22-M, Section 7.3.1, as 
  6219. follows:
  6220.                                      
  6221. 7.3  Criteria Control Objective for Security Policy
  6222.  
  6223.      7.3.1  Marking
  6224.  
  6225.           The control objective for marking ... 
  6226.  
  6227.           DoD 5220.22-M, "Industrial Security ... 
  6228.  
  6229.                   >"a.  General.  Classification designation by physical 
  6230.                   >marking, notation or other means serves to warn and to 
  6231.                   >inform the holder what degree of protection against 
  6232.                   >unauthorized disclosure is required for that 
  6233.                   >information or material." (14)
  6234.  
  6235.  
  6236.  
  6237. Changed the 
  6238.  
  6239.         >last paragraph 
  6240.  
  6241. of Section 7.5 as follows:
  6242.  
  6243.         A major component of assurance, life-cycle assurance, 
  6244.  
  6245.                 >as described in DoD Directive 7920.1, 
  6246.  
  6247. is concerned with testing ADP systems both in the
  6248. development phase as well as during operation.
  6249.  
  6250.         >(17) 
  6251.  
  6252. DoD Directive 5215.1 ...
  6253.  
  6254.  
  6255.  
  6256. Changed Section 9.0 as follows:
  6257.                                      
  6258.  
  6259. 9.0  A GUIDELINE ON CONFIGURING MANDATORY ACCESS CONTROL FEATURES
  6260.  
  6261.      The Mandatory Access Control requirement ... 
  6262.  
  6263.      *    The number of hierarchical classifications should be 
  6264.           greater than or equal to 
  6265.  
  6266.                 >sixteen (16).
  6267.  
  6268.      *    The number of non-hierarchical categories should be 
  6269.           greater than or equal to 
  6270.  
  6271.                 >sixty-four (64)..
  6272.  
  6273.  
  6274.  
  6275. Completely reworded the third paragraph of Formal Product
  6276. Evaluation, in Appendix A, as follows:
  6277.                                      
  6278. Formal Product Evaluation
  6279.  
  6280. The formal product evaluation provides ... 
  6281.  
  6282. A formal product evaluation begins with ...   
  6283.  
  6284.         >The evaluation team writes a final report on their findings about 
  6285.         >the system.  The report is publicly available (containing no 
  6286.         >proprietary or sensitive information) and contains the overall 
  6287.         >class rating assigned to the system and the details of the 
  6288.         >evaluation team's findings when comparing the product against the 
  6289.         >evaluation criteria.  Detailed information concerning 
  6290.         >vulnerabilities found by the evaluation team is furnished to the 
  6291.         >system developers and designers as each is found so that the 
  6292.         >vendor has a chance to eliminate as many of them as possible 
  6293.         >prior to the completion of the Formal Product Evaluation. 
  6294.         >Vulnerability analyses and other proprietary or sensitive 
  6295.         >information are controlled within the Center through the 
  6296.         >Vulnerability Reporting Program and are distributed only within 
  6297.         >the U.S. Government on a strict need-to-know and non-disclosure 
  6298.         >basis, and to the vendor.
  6299.  
  6300.  
  6301.  
  6302. Changed two paragraphs in Audit (Appendix D) as follows: 
  6303.  
  6304.  
  6305.  C2: NEW: The TCB shall be able to create, maintain, and protect 
  6306.      from modification or unauthorized access or destruction an 
  6307.      audit trail of accesses to the objects it protects.  The 
  6308.      audit data shall be protected by the TCB so that read access 
  6309.      to it is limited to those who are authorized for audit data. 
  6310.      The TCB shall be able to record the following types of 
  6311.      events: use of identification and authentication mechanisms, 
  6312.      introduction of objects into a user's address space (e.g., 
  6313.      file open, program initiation), deletion of objects, actions 
  6314.      taken by computer operators and system administrators and/or 
  6315.      system security officers, 
  6316.  
  6317.         >and other security relevant events.  
  6318.  
  6319.      or each recorded event, the audit record shall 
  6320.      identify:  date and time of the event, user, type of event, 
  6321.      and success or failure of the event.  For 
  6322.      identification/authentication events the origin of request 
  6323.      (e.g., terminal ID) shall be included in the audit record. 
  6324.      For events that introduce an object into a user's  address 
  6325.      space and for object deletion events the audit record shall 
  6326.      include the name of the object.  The ADP system 
  6327.      administrator shall be able to selectively audit the actions 
  6328.      of any one or more users based on individual identity.
  6329.  
  6330.  B3: ADD: ...when thresholds are exceeded, 
  6331.  
  6332.                 >and, if the occurrence or accumulation of these 
  6333.                 >security relevant events continues, the system 
  6334.                 >shall take the least disruptive action to terminate
  6335.                 >the event.
  6336.  
  6337.  
  6338. Changed one paragraph in Design Documentation (Appendix D):
  6339.  
  6340.  B2: ADD: Change "tamperproof" to "tamper resistant." 
  6341.  
  6342.  
  6343. Changed two paragraphs in Design Specification and Verification:
  6344.  
  6345.  B1: NEW: An informal or formal model of the security policy
  6346.         supported by the TCB shall be maintained 
  6347.  
  6348.               >over the life cycle of the ADP system and demonstrated 
  6349.  
  6350.         to be consistent with its axioms.
  6351.  
  6352.  B2: CHANGE: A formal model of the security policy supported by
  6353.         the TCB shall be maintained 
  6354.  
  6355.                 >over the life cycle of the ADP system 
  6356.  
  6357.           that is proven consistent with its axioms.
  6358.  
  6359.  
  6360.  
  6361. Changed two paragraphs in Discretionary Access Control as follows:  
  6362.  
  6363.  C2: CHANGE: The enforcement mechanism (e.g., self/group/public 
  6364.      controls, access control lists) shall allow users to specify 
  6365.      and control sharing of those objects by named individuals, 
  6366.      or defined groups of individuals, or by both, 
  6367.  
  6368.         >and shall provide controls to limit propagation of access rights.  
  6369.  
  6370.  B3: CHANGE: The enforcement mechanism (e.g., access control 
  6371.      lists) shall allow users to specify and control sharing of 
  6372.      those objects, 
  6373.  
  6374.         >and shall provide controls to limit propagation of access rights.  
  6375.  
  6376.      These access controls shall be capable of specifying, for each 
  6377.      named object, a list of named individuals and a list of groups of
  6378.      named individuals with their respective modes of access to that object.
  6379.  
  6380.                                      
  6381. Changed 1 paragraph in Exportation of Labeled Information:
  6382.  
  6383.  
  6384.  B1: NEW: The TCB shall designate each communication channel and 
  6385.      I/O device as either single-level or multilevel.  Any change 
  6386.      in this designation shall be done manually and shall be 
  6387.      auditable by the TCB.  The TCB shall maintain and be able to 
  6388.      audit any change in the /current/ security level 
  6389.  
  6390.         >or levels 
  6391.  
  6392.      associated with a /single-level/ communication channel or 
  6393.      I/O device.
  6394.  
  6395.  
  6396. Changed 1 paragraph in Identification and Authorization:
  6397.  
  6398.  B1: CHANGE: ... This data shall be used by the TCB to authenticate
  6399.         the user's identity and 
  6400.  
  6401.                 >to ensure that 
  6402.  
  6403.         the security level and authorizations of subjects external to 
  6404.         the TCB that may be     created to act on behalf of the individual 
  6405.         user 
  6406.  
  6407.                 >are dominated by the clearance and authorization 
  6408.                 >of that user.
  6409.  
  6410.  
  6411. Changed 1 paragraph in Labels:
  6412.  
  6413.  B2: CHANGE: ... (e.g., subject, storage object, ROM) ...
  6414.  
  6415.  
  6416. Changed 1 paragraph in Mandatory Access Control:
  6417.  
  6418.  B1: NEW: ... Identification and authentication data shall be used
  6419.  
  6420.         >by the TCB to authenticate the user's identity and to ensure
  6421.         >that the security level and authorization of subjects external
  6422.         >to the TCB that may be created to act on behalf of the
  6423.         >individual user are dominated by the clearance and authoriza-
  6424.         >tion of that user.
  6425.  
  6426.  
  6427. Rewrote 1 paragraph in Object Reuse:
  6428.  
  6429.  C2: NEW: 
  6430.         >All authorizations to the information contained 
  6431.      >within a storage object shall be revoked prior to initial 
  6432.      >assignment, allocation or reallocation to a subject from the 
  6433.      >TCB's pool of unused storage objects.  No information, 
  6434.      >including encrypted representations of information, produced 
  6435.      >by a prior subject's actions is to be available to any 
  6436.      >subject that obtains access to an object that has been 
  6437.      >released back to the system.
  6438.  
  6439.  
  6440. Changed l paragraph in Test Documentation:
  6441.  
  6442.  C1: NEW: The system developer shall provide to the evaluators a
  6443.         document that describes the test plan, 
  6444.  
  6445.                 >test procedures that show how the security 
  6446.                 >mechanisms were tested, 
  6447.  
  6448.         and results of the security mechanisms' functional testing.
  6449.  
  6450.  
  6451.                                      
  6452.                                  GLOSSARY 
  6453.  
  6454.  
  6455.  
  6456. Changed Discretionary Access Control: 
  6457.  
  6458. Discretionary Access Control - A means of restricting access to 
  6459.      objects based on the identity of subjects and/or groups to 
  6460.      which they belong.  The controls are discretionary in the 
  6461.      sense that a subject with a certain access permission is 
  6462.      capable of passing that permission (perhaps indirectly) on 
  6463.      to any other subject 
  6464.  
  6465.         (unless restrained by mandatory access control).
  6466.  
  6467. Added:
  6468.  
  6469. Front-End Security Filter - A process that is invoked to process 
  6470.      data according to a specified security policy prior to 
  6471.      releasing the data outside the processing environment or 
  6472.      upon receiving data from an external source.
  6473.  
  6474.  
  6475. Granularity - The relative fineness or coarseness by which a 
  6476.      mechanism can be adjusted.  The phrase "the granularity of 
  6477.      a single user" means the access control mechanism can be 
  6478.      adjusted to include or exclude any single user. 
  6479.  
  6480.  
  6481. Read-Only Memory (ROM) - A storage area in which the contents 
  6482.      can be read but not altered during normal computer 
  6483.      processing.
  6484.  
  6485.                                     
  6486. Security Relevant Event - Any event that attempts to change the 
  6487.      security state of the system, (e.g., change discretionary 
  6488.      access controls, change the security level of the subject, 
  6489.      change user password, etc.).  Also, any event that attempts 
  6490.      to violate the security policy of the system, (e.g., too 
  6491.      many attempts to login, attempts to violate the mandatory 
  6492.      access control limits of a device, attempts to downgrade a 
  6493.      file, etc.).
  6494.  
  6495.  
  6496. Changed the name of the term:
  6497.  
  6498. Simple Security /Property/ 
  6499.  
  6500.         >Condition 
  6501.  
  6502. - A Bell-LaPadula security model rule allowing a subject
  6503. read access to an object only if the security level of the
  6504. subject dominates the security level of the object.
  6505.  
  6506.  
  6507. Changed definition:  
  6508.  
  6509.  Trusted Computing Base (TCB) - The totality of protection 
  6510.      mechanisms within a computer system --including hardware, 
  6511.      firmware, and software -- the combination of which is 
  6512.      responsible for enforcing a security policy.  
  6513.  
  6514.         >A TCB consists of one or more components that together enforce 
  6515.         >a unified security policy over a product or system.  
  6516.  
  6517.      The ability of a TCB to correctly enforce a security
  6518.      policy depends solely on the mechanisms within the TCB and
  6519.      on the correct input by system administrative personnel of
  6520.      parameters (e.g., a user's clearance) related to the
  6521.      security policy.
  6522.  
  6523.                                      
  6524.                                 REFERENCES 
  6525.  
  6526.  
  6527. Added:  (References were renumbered as necessary)
  6528.  
  6529. 5.   DCID 1/16, Security of Foreign Intelligence in Automated 
  6530.      Data Processing Systems and Networks (U), 4 January 1983. 
  6531.  
  6532. 6.   DIAM 50-4, Security of Compartmented Computer Operations (U),  
  6533.      24 June 1980. 
  6534.  
  6535. 9.   DoD Directive 5000.29, Management of Computer Resources in     
  6536.      Major Defense Systems, 26 April 1976.
  6537.  
  6538. 17.  DoD Directive 7920.1, Life Cycle Management of Automated 
  6539.      Information Systems (AIS), 17 October 1978.
  6540.  
  6541.  
  6542. Corrected dates on the following References:
  6543.  
  6544. 14.  DoD 5220.22-M, Industrial Security Manual for Safeguarding 
  6545.      Classified Information, March 1984.
  6546.  
  6547. 15.  DoD 5220.22-R, Industrial Security Regulation, February 
  6548.      1984.
  6549.  
  6550.  
  6551. %