Trusted Computer System Evaluation Criteria ['Orange Book']

3y ago
27 Views
2 Downloads
239.72 KB
116 Pages
Last View : 1m ago
Last Download : 3m ago
Upload by : River Barajas
Transcription

DoD 5200.28-STDSupersedesCSC-STD-00l-83, dtd l5 Aug 83Library No. S225,7llDEPARTMENT OF DEFENSE STANDARDDEPARTMENT OFDEFENSETRUSTED COMPUTERSYSTEM EVALUATIONCRITERIADECEMBER l985December 26, l985Page 1

FOREWORDThis publication, DoD 5200.28-STD, "Department of Defense Trusted ComputerSystem Evaluation Criteria," is issued under the authority of an in accordancewith DoD Directive 5200.28, "Security Requirements for Automatic DataProcessing (ADP) Systems," and in furtherance of responsibilities assigned byDoD Directive 52l5.l, "Computer Security Evaluation Center." Its purpose isto provide technical hardware/firmware/software security criteria andassociated technical evaluation methodologies in support of the overall ADPsystem security policy, evaluation and approval/accreditation responsibilitiespromulgated by DoD Directive 5200.28.The provisions of this document apply to the Office of the Secretary ofDefense (ASD), the Military Departments, the Organization of the JointChiefs of Staff, the Unified and Specified Commands, the Defense Agenciesand activities administratively supported by OSD (hereafter called "DoDComponents").This publication is effective immediately and is mandatory for use by all DoDComponents in carrying out ADP system technical security evaluation activitiesapplicable to the processing and storage of classified and other sensitive DoDinformation and applications as set forth herein.Recommendations for revisions to this publication are encouraged and will bereviewed biannually by the National Computer Security Center through a formalreview process. Address all proposals for revision through appropriatechannels to: National Computer Security Center, Attention: Chief, ComputerSecurity Standards.DoD Components may obtain copies of this publication through their ownpublications channels. Other federal agencies and the public may obtaincopies from: Office of Standards and Products, National Computer SecurityCenter, Fort Meade, MD 20755-6000, Attention: Chief, Computer SecurityStandards.Donald C. LathamAssistant Secretary of Defense(Command, Control, Communications, and Intelligence)Page 2

ACKNOWLEDGEMENTSSpecial recognition is extended to Sheila L. Brand, National Computer SecurityCenter (NCSC), who integrated theory, policy, and practice into and directedthe production of this document.Acknowledgment is also given for the contributions of: Grace Hammonds andPeter S. Tasker, the MITRE Corp., Daniel J. Edwards, NCSC, Roger R. Schell,former Deputy Director of NCSC, Marvin Schaefer, NCSC, and Theodore M. P. Lee,Sperry Corp., who as original architects formulated and articulated thetechnical issues and solutions presented in this document; Jeff Makey,formerly NCSC, Warren F. Shadle, NCSC, and Carole S. Jordan, NCSC, whoassisted in the preparation of this document; James P. Anderson, James P.Anderson & Co., Steven B. Lipner, Digital Equipment Corp., Clark Weissman,System Development Corp., LTC Lawrence A. Noble, formerly U.S. Air Force,Stephen T. Walker, formerly DoD, Eugene V. Epperly, DoD, and James E.Studer, formerly Dept. of the Army, who gave generously of their time andexpertise in the review and critique of this document; and finally, thanks aregiven to the computer industry and others interested in trusted computingfor their enthusiastic advice and assistance throughout this effort.Page 3

CONTENTSFOREWORD. . . . . . . . . . . . . . . . . . . . . . . . . . . .iACKNOWLEDGMENTS . . . . . . . . . . . . . . . . . . . . . . . iiPREFACE . . . . . . . . . . . . . . . . . . . . . . . . . . . .vINTRODUCTION. . . . . . . . . . . . . . . . . . . . . . . . . .1PART I:THE CRITERIA1.0DIVISION D:MINIMAL PROTECTION. . . . . . . . . . . . . .92.0DIVISION C: DISCRETIONARY PROTECTION. . . . . . . . . . 112.1Class (C1): Discretionary Security Protection . . 122.2Class (C2): Controlled Access Protection. . . . . 153.0DIVISION B: MANDATORY PROTECTION. . . . . . .3.1Class (B1): Labeled Security Protection3.2Class (B2): Structured Protection . . .3.3Class (B3): Security Domains. . . . . .4.0DIVISION A: VERIFIED PROTECTION . . . . . . . . . . . . 414.1Class (A1): Verified Design . . . . . . . . . . . 424.2Beyond Class (A1). . . . . . . . . . . . . . . . . 51PART II:.19202633RATIONALE AND GUIDELINES5.0CONTROL OBJECTIVES FOR TRUSTED COMPUTER SYSTEMS.5.1A Need for Consensus . . . . . . . . . . .5.2Definition and Usefulness. . . . . . . . .5.3Criteria Control Objective . . . . . . . .555656566.0RATIONALE BEHIND THE EVALUATION CLASSES.6.1The Reference Monitor Concept. . .6.2A Formal Security Policy Model . .6.3The Trusted Computing Base . . . .6.4Assurance. . . . . . . . . . . . .6.5The Classes. . . . . . . . . . . .6364646565667.0THE RELATIONSHIP BETWEEN POLICY AND THE CRITERIA . .7.1Established Federal Policies . . . . . . . . .7.2DoD Policies . . . . . . . . . . . . . . . . .7.3Criteria Control Objective For Security Policy7.4Criteria Control Objective for Accountability.7.5Criteria Control Objective for Assurance . . .6970707174768.0A GUIDELINE ON COVERT CHANNELS . . . . . . . . . . . . . 79.Page 4

9.010.0A GUIDELINE ON CONFIGURING MANDATORY ACCESS CONTROLFEATURES . . . . . . . . . . . . . . . . . . . . . . . . 81A GUIDELINE ON SECURITY TESTING10.1 Testing for Division C . .10.2 Testing for Division B . .10.3 Testing for Division A . .83848485APPENDIX A:Commercial Product Evaluation Process. . . . . . 87APPENDIX B:Summary of Evaluation Criteria Divisions . . . . 89APPENDIX C:Sumary of Evaluation Criteria Classes. . . . . . 91APPENDIX D:Requirement Directory. . . . . . . . . . . . . . 93GLOSSARY. . . . . . . . . . . . . . . . . . . . . . . . . . .109REFERENCES. . . . . . . . . . . . . . . . . . . . . . . . . .115Page 5

PREFACEThe trusted computer system evaluation criteria defined in this documentclassify systems into four broad hierarchical divisions of enhanced securityprotection. They provide a basis for the evaluation of effectiveness ofsecurity controls built into automatic data processing system products. Thecriteria were developed with three objectives in mind: (a) to provide userswith a yardstick with which to assess the degree of trust that can be placedin computer systems for the secure processing of classified or other sensitiveinformation; (b) to provide guidance to manufacturers as to what to build intotheir new, widely-available trusted commercial products in order to satisfytrust requirements for sensitive applications; and (c) to provide a basis forspecifying security requirements in acquisition specifications. Two types ofrequirements are delineated for secure processing: (a) specific securityfeature requirements and (b) assurance requirements. Some of the latterrequirements enable evaluation personnel to determine if the required featuresare present and functioning as intended. The scope of these criteria is to beapplied to the set of components comprising a trusted system, and is notnecessarily to be applied to each system component individually. Hence, somecomponents of a system may be completely untrusted, while others may beindividually evaluated to a lower or higher evaluation class than the trustedproduct considered as a whole system. In trusted products at the high end ofthe range, the strength of the reference monitor is such that most of thecomponents can be completely untrusted. Though the criteria are intended tobe application-independent, the specific security feature requirements mayhave to be interpreted when applying the criteria to specific systems withtheir own functional requirements, applications or special environments (e.g.,communications processors, process control computers, and embedded systems ingeneral). The underlying assurance requirements can be applied across theentire spectrum of ADP system or application processing environments withoutspecial interpretation.Page 6

INTRODUCTIONHistorical PerspectiveIn October 1967, a task force was assembled under the auspices of the DefenseScience Board to address computer security safeguards that would protectclassified information in remote-access, resource-sharing computer systems.The Task Force report, "Security Controls for Computer Systems," published inFebruary 1970, made a number of policy and technical recommendations onactions to be taken to reduce the threat of compromise of classifiedinformation processed on remote-access computer systems.[34] Department ofDefense Directive 5200.28 and its accompanying manual DoD 5200.28-M, publishedin 1972 and 1973 respectively, responded to one of these recommendations byestablishing uniform DoD policy, security requirements, administrativecontrols, and technical measures to protect classified information processedby DoD computer systems.[8;9] Research and development work undertaken by theAir Force, Advanced Research Projects Agency, and other defense agencies inthe early and mid 70's developed and demonstrated solution approaches for thetechnical problems associated with controlling the flow of information inresource and information sharing computer systems.[1] The DoD ComputerSecurity Initiative was started in 1977 under the auspices of the UnderSecretary of Defense for Research and Engineering to focus DoD effortsaddressing computer security issues.[33]Concurrent with DoD efforts to address computer security issues, work wasbegun under the leadership of the National Bureau of Standards (NBS) to defineproblems and solutions for building, evaluating, and auditing secure computersystems.[17] As part of this work NBS held two invitational workshops on thesubject of audit and evaluation of computer security.[20;28] The first washeld in March 1977, and the second in November of 1978. One of the productsof the second workshop was a definitive paper on the problems related toproviding criteria for the evaluation of technical computer securityeffectiveness.[20] As an outgrowth of recommendations from this report, andin support of the DoD Computer Security Initiative, the MITRE Corporationbegan work on a set of computer security evaluation criteria that could beused to assess the degree of trust one could place in a computer system toprotect classified data.[24;25;31] The preliminary concepts for computersecurity evaluation were defined and expanded upon at invitational workshopsand symposia whose participants represented computer security expertisedrawn from industry and academia in addition to the government. Their workhas since been subjected to much peer review and constructive technicalcriticism from the DoD, industrial research and development organizations,universities, and computer manufacturers.The DoD Computer Security Center (the Center) was formed in January 1981 tostaff and expand on the work started by the DoD Computer SecurityInitiative.[15] A major goal of the Center as given in its DoD Charter is toencourage the widespread availability of trusted computer systems for use bythose who process classified or other sensitive information.[10] The criteriapresented in this document have evolved from the earlier NBS and MITREevaluation material.ScopePage 7

The trusted computer system evaluation criteria defined in this document applyprimarily to trusted commercially available automatic data processing (ADP)systems. They are also applicable, as amplified below, the the evaluation ofexisting systems and to the specification of security requirements for ADPsystems acquisition. Included are two distinct sets of requirements: 1)specific security feature requirements; and 2) assurance requirements. Thespecific feature requirements encompass the capabilities typically found ininformation processing systems employing general-purpose operating systemsthat are distinct from the applications programs being supported. However,specific security feature requirements may also apply to specific systems withtheir own functional requirements, applications or special environments (e.g.,communications processors, process control computers, and embedded systems ingeneral). The assurance requirements, on the other hand, apply to systemsthat cover the full range of computing environments from dedicated controllersto full range multilevel secure resource sharing systems.PurposeAs outlined in the Preface, the criteria have been developedto serve a numberof intended purposes:* To provide a standard to manufacturers as to what securityfeatures to build into their new and planned, commercialproducts in order to provide widely available systems thatsatisfy trust requirements (with particular emphasis on preventingthe disclosure of data) for sensitive applications.* To provide DoD components with a metric with which to evaluatethe degree of trust that can be placed in computer systems forthe secure processing of classified and other sensitiveinformation.* To provide a basis for specifying security requirements inacquisition specifications.With respect to the second purpose for development of the criteria, i.e.,providing DoD components with a security evaluation metric, evaluations can bedelineated into two types: (a) an evaluation can be performed on a computerproduct from a perspective that excludes the application environment; or, (b)it can be done to assess whether appropriate security measures have been takento permit the system to be used operationally in a specific environment. Theformer type of evaluation is done by the Computer Security Center through theCommercial Product Evaluation Process. That process is described in AppendixA.The latter type of evaluation, i.e., those done for the purpose of assessing asystem's security attributes with respect to a specific operational mission,is known as a certification evaluation. It must be understood that thecompletion of a formal product evaluation does not constitute certification oraccreditation for the system to be used in any specific applicationenvironment. On the contrary, the evaluation report only provides a trustedcomputer system's evaluation rating along with supporting data describing theproduct system's strengths and weaknesses from a computer security point ofPage 8

view. The system security certification and the formal approval/accreditationprocedure, done in accordance with the applicable policies of the issuingagencies, must still be followed-before a system can be approved for use inprocessing or handling classified information.[8;9] Designated ApprovingAuthorities (DAAs) remain ultimately responsible for specifying security ofsystems they accredit.The trusted computer system evaluation criteria will be used directly andindirectly in the certification process. Along with applicable policy, itwill be used directly as technical guidance for evaluation of the total systemand for specifying system security and certification requirements for newacquisitions. Where a system being evaluated for certification employs aproduct that has undergone a Commercial Product Evaluation, reports from thatprocess will be used as input to the certification evaluation. Technical datawill be furnished to designers, evaluators and the Designated ApprovingAuthorities to support their needs for making decisions.Fundamental Computer Security RequirementsAny discussion of computer security necessarily starts from a statement ofrequirements, i.e., what it really means to call a computer system "secure."In general, secure systems will control, through use of specific securityfeatures, access to information such that only properly authorizedindividuals, or processes operating on their behalf, will have access to read,write, create, or delete information. Six fundamental requirements arederived from this basic statement of objective: four deal with what needs tobe provided to control access to information; and two deal with how one canobtain credible assurances that this is accomplished in a trusted computersystem.PolicyRequirement 1 - SECURITY POLICY - There must be an explicit andwell-defined security policy enforced by the system. Given identifiedsubjects and objects, there must be a set of rules that are used by the systemto determine whether a given subject can be permitted to gain access to aspecific object. Computer systems of interest must enforce a mandatorysecurity policy that can effectively implement access rules for handlingsensitive (e.g., classified) information.[7] These rules include requirementssuch as: No person lacking proper personnel security clearance shall obtainaccess to classified information. In addition, discretionary securitycontrols are required to ensure that only selected users or groups of usersmay obtain access to data (e.g., based on a need-to-know).Requirement 2 - MARKING - Access control labels must be associatedwith objects. In order to control access to information stored in a computer,according to the rules of a mandatory security policy, it must be possible tomark every object with a label that reliably identifies the object'ssensitivity level (e.g., classification), and/or the modes of access accordedthose subjects who may potentially access the object.Page 9

AccountabilityRequirement 3 - IDENTIFICATION - Individual subjects must beidentified. Each access to information must be mediated based on who isaccessing the information and what classes of information they are authorizedto deal with. This identification and authorization information must besecurely maintained by the computer system and be associated with every activeelement that performs some security-relevant action in the system.Requirement 4 - ACCOUNTABILITY - Audit information must beselectively kept and protected so that actions affecting security can betraced to the responsible party. A trusted system must be able to record theoccurrences of security-relevant events in an audit log. The capability toselect the audit events to be recorded is necessary to minimize the expense ofauditing and to allow efficient analysis. Audit data must be protected frommodification and unauthorized destruction to permit detection andafter-the-fact investigations of security violations.AssuranceRequirement 5 - ASSURANCE - The computer system must containhardware/software mechanisms that can be independently evaluated to providesufficient assurance that the system enforces requirements 1 through 4 above.In order to assure that the four requirements of Security Policy, Marking,Identification, and Accountability are enforced by a computer system, theremust be some identified and unified collection of hardware and softwarecontrols that perform those functions. These mechanisms are typicallyembedded in the operating system and are designed to carry out the assignedtasks in a secure manner. The basis for trusting such system mechanisms intheir operational setting must be clearly documented such that it ispossible to independently examine the evidence to evaluate their sufficiency.Requirement 6 - CONTINUOUS PROTECTION - The trusted mechanisms thatenforce these basic requirements must be continuously protected againsttampering and/or unauthorized changes. No computer system can be consideredtruly secure if the basic hardware and software mechanisms that enforce thesecurity policy are themselves subject to unauthorized modification orsubversion. The continuous protection requirement has direct implicationsthroughout the computer system's life-cycle.These fundamental requirements form the basis for the individual evaluationcriteria applicable for each evaluation division and class. The interestedreader is referred to Section 5 of this document, "Control Objectives forTrusted Computer Systems," for a more complete discussion and furtheramplification of these fundamental requirements as they apply togeneral-purpose information processing systems and to Section 7 foramplification of the relationship between Policy and these requireme

This publication, DoD 5200.28-STD, "Department of Defense Trusted Computer System Evaluation Criteria," is issued under the authority of an in accordance with DoD Directive 5200.28, "Security Requirements for Automatic Data Processing (ADP) Systems," and in furtherance of responsibilities assigned by

Related Documents:

Trusted Computing refers to a platform of the type specified by the Trusted Computing Group (TCG)1 as well as the next generation of hardware [43, 81, 4] and operating system [63, 49, 9] designed to provide trusted features and hardware-enforced isolation. A trusted platform (TP) is a platform that has a

2.3 Trusted Computing The Trusted Computing Group (TCG) [10] proposed a set of hardware and software technologies to enable the construction of trusted platforms. In particular, the TCG proposeda standardforthe design of the trusted platform module (TPM) chip that is now bundled with com

TC Trusted Computing TCG Trusted Computing Group, group of companies developing the TC specs TCPA Trusted Computing Platform Alliance, predecessor of TCG TPM Trusted Platform Module, the hardware Palladium, LaGrande, implementations from various companies, are not always

92 Trusted Computing and Linux a section on future work. 2 Goals of Trusted Computing The Trusted Computing Group (TCG) has cre-ated the Trusted Computing specifications in response to growing security problems in the technology field. “The purpose of TCG is to develop,

The Trusted Contact(s) must be at least 18 years old. Trusted Contact Information . Trusted Contact information provided on this form will replace all Trusted Contact information currently on file. Person 1. If you have no changes to your existing Trusted Contact, please skip this section. Name . Title, First Middle Name Last Name, Suffix .

ACES DIGITAL CERTIFICATE PROGRAM ACES Trusted Agent Summary of Relevant Policy Provisions ACES CP Provisions (Edited) 1.3.2 Trusted Agents CAs may choose to use the services of Trusted Agents to assist CAs in performing identity verification tasks. Trusted Agents do not have privileged access to CA functions, but are considered agents of the CA.

o OpenStack can launch VMs and Containers with the extensions that are already mainstream (Trusted Compute Pools) o Get engaged, get started with Trusted VMs and OpenStack. Extensions to OpenStack for Trusted Docker containers, will be available in Q3 timeframe. o iKGT is available now on 01.org. Download it and try it out. Summary & Call to Action

Pipe Size ASTM Designation in mm D2310 D2996 2 - 6 50 - 150 RTRP-11FU RTRP-11FU1-6430 8 - 16 200 - 400 RTRP-11FU RTRP-11FU1-3220. Fittings 2 to 6 inch Compression-molded fiberglass reinforced epoxy elbows and tees Filament-wound and/or mitered crosses, wyes, laterals and reducers 8 to 16 inch Filament-wound fiberglass reinforced epoxy elbows. Filament-wound and/or mitered crosses, tees, wyes .