home *** CD-ROM | disk | FTP | other *** search
/ Handbook of Infosec Terms 2.0 / Handbook_of_Infosec_Terms_Version_2.0_ISSO.iso / text / secpubs / tg002.txt < prev    next >
Text File  |  1995-09-15  |  53KB  |  1,094 lines

  1.  
  2.  
  3.                     NCSC -TG-002<DJ0>
  4.                      Library No. S-228,538
  5.                     Version 1
  6.  
  7. FOREWORD
  8.  
  9. The National Computer Security Center has established an aggressive program to
  10. study and implement computer security technology, and to encourage the
  11. widespread availability of trusted computer products for use by any
  12. organization desiring better protection of their important data. The Trusted
  13. Product Evaluation Program focuses on the security evaluation of commercially
  14. produced and supported computer systems by evaluating the technical protection
  15. capabilities against the established criteria presented in the Trusted
  16. Computer System Evaluation Criteria. This program, and the open and
  17. cooperative business relationship being forged with the computer and
  18. telecommunications industries, will result in the fulfillment of our country's
  19. computer security requirements.  We are resolved to meet the challenge of
  20. identifying trusted computer products suitable for use in processing sensitive
  21. information.  A key service of the National Computer Security Center to the
  22. computer security community is to act as a clearinghouse for computer security
  23. issues and to develop technical security guidelines for automatic data
  24. processing systems and networks.  This technical information exchange provides
  25. guidance and interpretations for the security evaluation process and offers
  26. the vendors a central point for technical exchange.
  27.  
  28.  
  29. PATRICK R.  GALLAGHER, JR.                  1 March 1988
  30. DIRECTOR
  31. NATIONAL COMPUTER SECURITY CENTER 
  32.  
  33.  
  34.                  PREFACE
  35.  
  36.  
  37. This publication describes procedures for interacting with the National
  38. Security Agency's Information Security Organization as related to the Trusted
  39. Product Evaluation Program within the National Computer Security Center. It
  40. provides the information needed to submit a computer product for technical
  41. security evaluation and outlines the National Security Agency's
  42. responsibilities for positive, timely acknowledgements. This publication
  43. specifically covers the National Computer Security Center's relationship with
  44. vendors of proposed trusted computer products from the initial contact with
  45. the vendor through the completion of the security evaluation process and
  46. follow-on programs.  Although more detailed instructions will be referenced in
  47. this publication, sufficient guidelines are established for any first-time
  48. user of the National Computer Security Center's services.  The Office of
  49. Industrial Relations invites your comments on this document and on the
  50. National Computer Security Center's procedures for conducting security
  51. evaluations of computer products.  In cooperation with the computer industry,
  52. we can improve our national security through the availability of trusted
  53. computer products.  
  54.  
  55.                INTRODUCTION
  56.  
  57. In January 1981 the Director of the National Security Agency was assigned the
  58. responsibility for computer security for the Department of Defense.  This
  59. action led to the formation of the Computer Security Center at the National
  60. Security Agency. The Computer Security Center's Charter, promulgated in
  61. Department of Defense Directive 5215.1 in October 1982, specifically tasks the
  62. Computer Security Center to establish and maintain "...  technical standards
  63. and criteria for the security evaluation of trusted computer systems that can
  64. be incorporated readily into the Department of Defense component life-cycle
  65. management process..." The developmental experiments in the 1970's ranged from
  66. attempts to add security front-ends to existing systems to designing secure
  67. systems and hardware from scratch.  Early research and development efforts
  68. defined a graduated scale of security features and design principles. These
  69. features and principles were incorporated in the Department of Defense Trusted
  70. Computer System Evaluation Criteria (Orange Book).  The Orange Book was issued
  71. in August 1983.  In December 1985, the Orange Book was reissued as a
  72. Department of Defense Standard (DOD 5200.28-STD).  The National Computer
  73. Security Center (the Center) responds to a growing need for, and recognizes
  74. technical challenges involved in, providing effective protection within
  75. computer systems and networks of systems. The Center relies on an open and
  76. cooperative relationship with government, industry representatives, and the
  77. academic community to accomplish these important objectives. The government
  78. encourages industry to provide the computer security capabilities government
  79. needs. The Center sponsors critical research, and makes the results widely
  80. available to encourage their incorporation into trusted computer products and
  81. secure applications. The Center performs security evaluations of computer
  82. software and hardware products on commercially or government-produced computer
  83. systems.  A trusted computer system is defined as a system that employs
  84. sufficient hardware and software integrity measures to allow its use to
  85. simultaneously process a range of sensitive unclassified or classified (e.
  86. g., confidential through top secret) information for a diverse set of users
  87. without violating access privileges.  Levels of trust are based on the ability
  88. of the computer system to enforce access privileges to authorized users and to
  89. system protected files.  The Center evaluates the security features of trusted
  90. products against established technical standards and criteria, and maintains
  91. the Evaluated Products List.  The Evaluated Products List is a compilation of
  92. all computer products which have undergone formal security evaluations, and
  93. indicates the relative security merit of each computer product.  The criteria
  94. against which computer systems are evaluated is the Orange Book. This provides
  95. a metric for distinguishing a range of features and assurances for security
  96. controls built into automatic data processing system products.  The Orange
  97. Book establishes specific requirements that a computer system must meet in
  98. order to achieve a specific level of trustworthiness.  The levels are arranged
  99. hierarchically into four major divisions of protection, each with certain
  100. security-relevant characteristics.  These divisions are subdivided into levels
  101. of trust.  In recognition of the complex and technical nature of the issues
  102. addressed by the Orange Book, the Center has established a Technical
  103. Guidelines Program.  This program augments information provided in the Orange
  104. Book by publishing additional guidance on issues and features addressed
  105. therein.
  106.  
  107. TRUSTED PRODUCT SECURITY EVALUATION
  108.  
  109. This section provides the potential computer product vendor with an overview
  110. of the Center's Trusted Product Evaluation Program.  The process of a trusted
  111. product evaluation is illustrated in Figure One.  The Pre-Evaluation Review
  112. includes the initial contact between the vendor and the National Security
  113. Agency, the decision-making process to initiate, and the signing of a
  114. Memorandum of Understanding.  Note: subsystem products do not require a
  115. Memorandum of Understanding but are initiated with a Memorandum of Agreement.
  116. The Trusted Product Developmental Process provides the vendor the opportunity
  117. to obtain assistance from the Center during the development of a system or
  118. network product.  The formal product evaluation consists of the actual
  119. security evaluation of the vendor's computer system.  Successful completion of
  120. this process results in the vendor's computer product being placed on the
  121. Evaluated Products List.  
  122.  
  123. PRE-EVALUATION REVIEW
  124.  
  125. Five milestones in the application process must be reached before the security
  126. evaluation of a proposed computer product can begin.  
  127.      1.  Initial Contact
  128.      2.  Certificate Pertaining to Foreign Interests
  129.      3.  Proposal Package
  130.      4.  Program Decision
  131.      5.  Memorandum of Understanding (Memorandum of
  132.          Agreement for Subsystems)
  133.  
  134. INITIAL CONTACT
  135.  
  136. The National Security Agency point of contact for the Trusted Product
  137. Evaluation Program is the Office of Industrial Relations.  Interested
  138. companies are encouraged to call or write to: 
  139.  
  140.         Director, National Security Agency
  141.         Attention: Office of Industrial Relations
  142.         9800 Savage Road 
  143.         Fort George G. Meade, Maryland 20755-6000
  144.         (301) 688-6581
  145.  
  146. CERTIFICATE PERTAINING TO FOREIGN INTERESTS
  147.  
  148. Before submitting an application for the Trusted Product Evaluation Program,
  149. the Center requires that all companies submit a completed Certificate
  150. Pertaining to Foreign Interests prior to undertaking the additional effort to
  151. prepare a proposal package.  For those companies that already have a facility
  152. security clearance, a current DD Form 441s may be sent in lieu of the
  153. Certificate Pertaining to Foreign Interests.  Please submit the certificate or
  154. DD Form 441s to the Office of Industrial Relations, as listed above.
  155.  
  156.  
  157. PROPOSAL PACKAGE
  158.  
  159. After contact has been established, the vendor must prepare a proposal package
  160. in accordance with the following guidance. Four copies of the proposal package
  161. are required.  
  162.  
  163. This point cannot be over emphasized; information marked Company Proprietary
  164. is protected to the fullest extent permitted under the law, and must be marked
  165. accordingly.  The product proposal package should demonstrate corporate-level
  166. support for the product evaluation effort and consist of a company profile,
  167. market information and a written product proposal.
  168.  
  169. COMPANY PROFILE
  170.  
  171.     Potential computer security product vendors, whether requesting a
  172.     system, a network, or a subsystem evaluation, must establish a
  173.     formal working relationship with the Center. Vendors are encouraged
  174.     to submit as much detailed documentation as necessary to establish
  175.     their capability and suitability for the Trusted Product Evaluation
  176.     Program. The company profile portion of the submission shall include
  177.     at least the following information: 
  178.     
  179.     Company name and address.  
  180.     
  181.     State of incorporation and composition of ownership.  
  182.     
  183.     Principal point of contact, a technical point of contact, and a
  184.     public point of contact.  For each, include name and title, business
  185.     address, and business telephone.  Public point of contact names will
  186.     be placed on a list that can be provided to any requestor desiring
  187.     to establish a business connection with your company.  
  188.     
  189.     Product or services offered.  This could be supplemented with a
  190.     company capabilities brochure.  
  191.     
  192.     A recent annual or certified financial report.
  193.     
  194.     Number of people employed by the company, and in the case of a
  195.     system or network product, the projected size of the team which will
  196.     be developing, enhancing and/or maintaining the proposed product.
  197.  
  198.  
  199. MARKET INFORMATION
  200.  
  201. To evaluate the requirements for any proposed product, the vendor must provide
  202. sufficient detail to identify the utility in the market place.  The
  203. information below covers the minimum market information the Center requires to
  204. assess the probable need in the community.  The market information portion of
  205. the proposal package shall identify:
  206.  
  207.      Intended market by product type and level of trust, including a specific
  208.      customer base and/or firmly established requirements.
  209.  
  210.      Portion of markets intended to address.  How the specific market
  211.      projections were derived.  In cases where the product to be developed is
  212.      a retrofit to existing equipment, include the potential volumne of sales
  213.      for those existing equipments that are already fielded.
  214.  
  215.      Known or projected U.S.  Government requirements that the product will
  216.      satisfy.  Distinguish between DOD and Civil Agency.
  217.  
  218.      Known or projected commercial requirements that the product will satisfy.
  219.      
  220. WRITTEN PRODUCT PROPOSAL
  221.  
  222. A separate proposal is required for each computer product submitted for
  223. security evaluation.  These products must be of direct and obvious benefit to
  224. the information security posture of the nation, and should address the
  225. applicable requirements outlined in established criteria or interpretations.
  226. This determination will be based on the information contained in the product
  227. proposal, measured against national computer security needs and priorities.
  228.  
  229. The Center presently conducts three distinct types of product evaluations: 1)
  230. the system evaluation, 2) the network evaluation, and 3) the subsystem
  231. evaluation.  
  232.  
  233. Proposals For System Evaluations
  234.  
  235. The Center evaluates as a system that product which
  236. addresses all of the requirements of a given class of the Orange Book.
  237.  
  238. Although complete information about the proposed product may not
  239. be available at this stage of the design, the written product proposal should
  240. provide the following information:
  241.  
  242.     Technical description of the product.  
  243.     
  244.     What is the targeted class or level of trust?  
  245.     
  246.     What is the operating system for your product?  
  247.     
  248.     Is the proposed product currently in use?  If so, what is the
  249.     current installed base?
  250.     
  251.     What is the projected installed base over the nextve years?  
  252.     
  253.     What is the target development schedule?  How flexible is this
  254.     schedule and by what date do you plan to bring this product to
  255.     market?  
  256.     
  257.     What are the known or projected requirements that the product will
  258.     satisfy?  (Distinguish between the Department of Defense and Civil
  259.     Agencies.)
  260.     
  261.     What are the differences between and advantages of the proposed
  262.     product relative to similar products which are currently available?
  263.     
  264.     
  265. Proposals For Network Evaluations
  266.  
  267.           The Center defines a network as everything that is needed to
  268.           accomplish a job, end user to end user.  The Center defines a
  269.           network component as any part of a network.  
  270.           
  271.           The Trusted Network Interpretation of The Trusted Computer System
  272.           Evaluation Criteria (TNI) is currently the criteria against which
  273.           networks are evaluated.
  274.           
  275.           Written product proposals should provide the following information:
  276.           
  277.            A technical description of the product.  
  278.            
  279.            What is the underlying security policy of the product?  
  280.            
  281.            What level of protection is provided by the product?  
  282.            
  283.            What is the projected schedule for development?
  284.  
  285.            What are the environments for which the product is intended?
  286.            Include an overall description of the product.  Compare it to
  287.            another product currently available if possible.  
  288.            
  289.            Does your product interact with users directly?  If so, does it
  290.            provide all of the functionality identified at one of the criteria
  291.            levels in Part I of the TNI, or only a subset?  
  292.            
  293.            If it is a network system, what level of trust does it meet
  294.            according to Part I of the TNI?  
  295.            
  296.            If it is a network component, which of the following
  297.            functionalities does it provide, and at which level of trust is
  298.            each functionality provided?  
  299.            
  300.            Mandatory Access Control 
  301.            
  302.            Discretionary Access Control
  303.            
  304.            Identification and Authenication
  305.            
  306.            What other security services mentioned in Part II of the TNI does
  307.            your product provide?  
  308.            
  309.            What type of carrier medium, if any, is used or supported
  310.            by your product?  
  311.            
  312. Proposals For Subsystem Evaluations
  313.  
  314. The Center defines a computer security subsystem as a physical device or
  315. software mechanism which is added to a computer system to enhance the computer
  316. security functionality of the overall system.  
  317.  
  318. To be considered for a subsystem evaluation, a company must have an existing
  319. product which is designed to provide one or more of the following
  320. capabilities, as described in the Trusted Computer System Evaluation Criteria:
  321.  
  322.     1) mandatory access control;
  323.     
  324.     2) audit; 
  325.     
  326.     3) discretionary access control;
  327.     
  328.     4) identification and authentication; or.
  329.           
  330.     5) object re-use. 
  331.  
  332. Written product proposals should provide the following information:
  333.  
  334.  
  335.     A technical description of the product.  
  336.     
  337.     Which of the five subsystem functionalities does the product
  338.     implement?
  339.     
  340.     
  341.     What is the current installed base?  What is the projected installed
  342.     base over the next five years?  
  343.     
  344.     What is the current or projected market for your product (to include
  345.     specific customer base and/or firmly established requirements, if
  346.     possible)? What portion of this market do you intend to address?
  347.     How were the specific market projections derived?  
  348.     
  349.     What are the known or projected requirements that the product will
  350.     satisfy?  (Distinguish between the Department of Defense and Civil
  351.     Agencies.) 
  352.     
  353.     What are the differences between and advantages of the proposed
  354.     product relative to similar products which are currently available?
  355.     
  356. PROGRAM DECISION 
  357.  
  358. Upon receipt of the company's proposal package, the Office of Industrial
  359. Relations will send the company written notification that the package has been
  360. received and is under consideration.  The proposal will be reviewed to
  361. determine its value while assessing the capabilities of the company, the
  362. utility of the product to the Federal Government, and the degree to which the
  363. product addresses the technical aspects of computer security.  The
  364. availability of adequate Center resources to support the evaluation program is
  365. also a prime consideration in the program decision.  The Center may need to
  366. meet with the vendor's technical experts to ensure decision making processes
  367. are based on sound technical understanding of the product.  When a decision is
  368. reached, the Office of Industrial Relations will notify the vendor in writing
  369. whether the product has been accepted for evaluation.  System and network
  370. evaluations will enter into the Trusted Product Developmental Process as
  371. described below.  Subsystem evaluations enter directly into the formal
  372. evaluation.
  373.  
  374.  
  375. MEMORANDUM OF UNDERSTANDING
  376.  
  377.  
  378. If a package for a system or network product is accepted, a Memorandum of
  379. Understanding is executed between the vendor and the National Security Agency.
  380. The purpose and function of the Memorandum of Understanding is to establish a
  381. legal relationship between the National Security Agency and the potential
  382. vendor in which: 
  383.  
  384.     The National Security Agency agrees to provide necessary and
  385.     relevant computer security information and guidance to the potential
  386.     vendor.  
  387.     
  388.     The vendor agrees to provide the National Security Agency the
  389.     information necessary to assess the security of the proposed
  390.     product.  
  391.     
  392.     The vendor agrees to follow the intent and requirements of the
  393.     procedures leading to a system, network or subsystem evaluation.
  394.     
  395.     
  396.     The National Security Agency agrees to protect vendor proprietary
  397.     information which is provided under the Memorandum of Understanding.
  398.     
  399.     Both parties agree to review the continuation and terms of the
  400.     Memorandum of Understanding periodically.
  401.  
  402. A program manager within the Requirements and Resources Division at the Center
  403. will be assigned to monitor and coordinate technical and/or administrative
  404. responses to the vendor, and a technical point of contact within the Product
  405. Evaluation Division will be identified to the vendor.  To determine the
  406. division and class at which all requirements are met by a computer system, the
  407. system must be evaluated against the Orange Book.  This security evaluation
  408. will be conducted by a Center evaluation team.
  409.  
  410.  
  411. TRUSTED PRODUCT DEVELOPMENTAL PROCESS
  412.  
  413.  
  414. The primary thrust of this phase is an in-depth examination of a
  415. vendor's design either for a new trusted product (system or network) or for
  416. security enhancements to an existing product.It is intended to ensure that the
  417. product is actually ready for evaluation with all necessary evidence available
  418. so the evaluation can be completed without delays for additional development
  419. or evidence generation.  This phase is based primarily on design documentation
  420. and information supplied by the vendor, and it involves little or no "hands
  421. on" use of the product.  
  422.  
  423. This phase results in the production of an Initial Product Assessment Report.
  424. This report documents the evaluation team's understanding of the system based
  425. on the information presented by the vendor, and assigns a candidate Orange
  426. Book class rating to the system.  The candidate rating is an estimate of the
  427. highest class for which the product has displayed some evidence for each of
  428. the requirements in the Orange Book.  
  429.  
  430. The Center's Technical Review Board provides a consistency check on the
  431. application of the Orange Book requirements, and ensures the product is ready
  432. for evaluation.  Because the Initial Product Assessment Report does not
  433. represent a complete analysis of the computer product and may contain
  434. proprietary information, distribution is restricted to the respective vendor
  435. and the Center.
  436.  
  437.  
  438. SYSTEM AND NETWORK FORMAL EVALUATIONS
  439.  
  440.  
  441. To enter this formal evaluation phase, the design of a computer system must be
  442. finalized and marketable.  In addition, the product release being evaluated
  443. must not undergo any additional development.  Once the product is accepted for
  444. evaluation, a Memorandum of Agreement is signed between the Center and the
  445. vendor, to address the formal aspects of the product receiving an Evaluated
  446. Products List rating and the accompanying responsibilities.
  447.  
  448. At the start of this phase, a Product Bulletin is released by the enter
  449. announcing the evaluation. The Product Bulletin is a brief description of the
  450. computer system undergoing security evaluation, and includes the candidate
  451. rating of the system.
  452.  
  453. The evaluation phase is a detailed analysis of the hardware and software
  454. components of a system, all system documentation, and a mapping of the
  455. security features and assurances to the Orange Book.á The analysis performed
  456. during this phase requires "hands on" testing (i.e., functional testing and,
  457. if applicable, penetration testing).
  458.  
  459. The evaluation phase leads to the Center publishing a Final Evaluation Report
  460. and an Evaluated Products List entry. The Final Evaluation Report is a summary
  461. of the security evaluation and includes the Evaluated Products List rating,
  462. which is the final class at which the product successfully met all Orange Book
  463. requirements in terms of both security features and assurances. The Final
  464. Evaluation Report and the Evaluated Products List entry are made public.  The
  465. evaluation process represents a firm commitment from the vendor, and at its
  466. completion the product will receive a rating from the Center.
  467.  
  468.  
  469. SUBSYSTEM FORMAL EVALUATIONS
  470.  
  471.  
  472. While the Center devotes much of its resources to encouraging the production
  473. and use of multipurpose trusted computer systems, there is a recognized need
  474. for guidance on, and security evaluation of, supplementary computer security
  475. products. These subsystems may not meet all of the security feature,
  476. architecture, or assurance requirements of any one security class or level of
  477. the Orange Book. To meet this need, the Center has established the subsystem
  478. evaluation process.
  479.  
  480. The goal of the Center's subsystem evaluations is to provide computer
  481. installation managers with information on subsystems that would be helpful in
  482. providing immediate computer security improvements in existing installations.
  483. Once a subsystem product is accepted for evaluation, a Memorandum of Agreement
  484. is signed between the Center and the vendor, addressing the formal aspects of
  485. the product being included in the Evaluated Products List and the accompanying
  486. responsibilities.
  487.  
  488. Subsystems are special-purpose products which can be added to existing
  489. computer systems to increase some aspect of security and have the potential of
  490. meeting automatic data processing security needs. For the most part, the scope
  491. of a subsystem evaluation is limited to consideration of the subsystem itself,
  492. and does not address or attempt to rate the overall security of the processing
  493. environment or computer system on which the subsystem may be implemented. To
  494. promote consistency in evaluations, an attempt is made to assess a subsystem's
  495. security-relevant performance in light of applicable standards and features
  496. outlined in the Orange Book. In addition, the evaluation team reviews the
  497. vendor's claims and documentation for obvious flaws which would violate the
  498. product's security features, and verifies, through functional testing, that
  499. the computer product performs as advertised. Upon completion, a summary of the
  500. Final Evaluation Report will be placed on the Evaluated Products List.
  501.  
  502. The Final Evaluation Report will not assign a specific rating to the computer
  503. product, but will provide an assessment of the product's effectiveness and
  504. usefulness in increasing computer security.  The Final Evaluation Report and
  505. the Evaluated Products List entry are made public.
  506.  
  507. EVALUATED PRODUCTS LIST 
  508.  
  509. The Evaluated Products List provides computer users, managers and security
  510. officials, an authoritative and unbiased security evaluation of a computer
  511. system's suitability for use in processing classified and sensitive
  512. information. All products on the Evaluated Products List have been evaluated
  513. against the established criteria and interpretations. A Final Evaluation
  514. Report is issued for all products.  The rating given to a system product is
  515. the highest class for which all the requirements in the Orange Book have been
  516. met.  Trusted product security evaluation results are published in formal
  517. reports available from either the Government Printing Office or the National
  518. Technical Information Service.  
  519.  
  520. The overall evaluation class ratings given in the Evaluated Products List
  521. apply only to the specific hardware/software configurations listed.  As such,
  522. the rating indicates that the product met or exceeded each of the individual
  523. requirements for the overall Evaluation Class.  Although the computer product
  524. was subjected to the detailed security testing specified in the Orange Book,
  525. it must be emphasized that such testing is not sufficient to guarantee the
  526. absence of flaws in the product.  The Evaluated Products List entry does not
  527. constitute a general or overall endorsement of the product by the government,
  528. nor does it constitute a Department of Defense certification or accreditation
  529. of the trusted computer product for use in classified or sensitive
  530. unclassified processing environments.  Rather, the security evaluation
  531. provides an essential part of the technical evidence required for follow on
  532. certification and accreditation.  Ultimate responsibility for the continuing
  533. integrity provided by the security mechanisms of any trusted computer product
  534. evaluated by the Center rests solely with the vendor. The Evaluated Products
  535. List, which documents evaluated computer products, is available to vendors to
  536. actively market and advertise the overall evaluation class rating achieved by
  537. their products to procurement authorities and the general public.  
  538.  
  539. The Evaluated Products List contains entries for general-purpose operating
  540. systems, add-on packages, and subsystems. Product Bulletins, which are
  541. synopses of computer systems currently undergoing formal security evaluations
  542. by the Center, are also included on the Evaluated Products List.  
  543.  
  544. A hard copy of the Evaluated Products List is included in the Information
  545. Systems Security Products and Services Catalogue.  This catalogue is updated
  546. quarterly and is available through the Government Printing Office.
  547.  
  548.  
  549.  
  550. RATINGS MAINTENANCE PHASE 
  551.  
  552. The Ratings Maintenance Phase provides a mechanism to ensure the validity of a
  553. previous rating for a new version of an evaluated computer system product.  As
  554. enhancements are made to the computer product the Ratings Maintenance Phase
  555. ensures that the level of trust is not degraded. A complete re-evaluation is
  556. required to achieve a higher rating.  
  557.  
  558. The Ratings Maintenance Phase is designed to keep the Evaluated Products List
  559. current.  This is accomplished by using the personnel involved in the
  560. maintenance of the product to manage the change process and reduce the effort
  561. required to extend the rating.
  562.  
  563. Success of the Ratings Maintenance Phase depends upon the development of a
  564. cadre of vendor personnel with a strong technical knowledge of computer
  565. security and of their computer product.  These trained personnel will oversee
  566. the vendor's computer product modification process.  They will certify to the
  567. Center that any modifications or enhancements applied to the product will
  568. preserve the security mechanisms and maintan the assurances.
  569.  
  570. The Ratings Maintenance Phase is initially designed for C1 - B1 level of trust
  571. systems.  As experience is gained in the program, the intent is to extend to
  572. higher level systems and to networks.
  573.  
  574.  
  575.  
  576. EVALUATION SUPPORT SERVICES
  577.  
  578. The Center supports the trusted product security evaluation process within the
  579. Trusted Product Evaluation Program.  The following specialized technical
  580. services are available to benefit the interactive relationship between the
  581. computer product vendors and the technical staff of the Center. To obtain
  582. these services or to gain more insight into their particular detail, refer to
  583. the Points of Contact section.
  584.  
  585. DOCKMASTER
  586.  
  587.      
  588.      DOCKMASTER is an unclassified computer system used by the Center for the
  589.      nationwide dissemination and exchange of computer security information.
  590.      DOCKMASTER serves the entire information security community including the
  591.      Federal Government, universities, and private industry. It can distribute
  592.      electronic mail via connections to the ARPANET.  DOCKMASTER is accessible
  593.      by direct dial, the MILNET, and McDonnell Douglas Tymnet network.
  594.  
  595.      DOCKMASTER is the primary means of communications between the vendor and
  596.      the Center throughout the computer product security evaluation process.
  597.      It allows vendors to use electronic mail, file transfer protocols, and
  598.      the Forum subsystem.  Forum is an on-line, interactive meeting facility
  599.      that permits an individual to "meet" with other users through the use of
  600.      a computer terminal.
  601.  
  602. VERIFICATION TOOLS
  603.      
  604.      
  605.      Vendors who are developing systems that are targeted to meet the
  606.      class A1 requirements of the Orange Book must provide assurance that the
  607.      system implementation is consistent with the system's design.  This
  608.      assurance is gained by developing a Formal Top Level Specification of the
  609.      design and verifying that the specifications are consistent with the
  610.      formal security policy model (the security requirements) for the system.
  611.      After the design verification has been completed, an informal mapping is
  612.      performed from the Formal Top Level Specification to the implementation.
  613.      This completes the evidence.  Formal Top Level Specification development
  614.      and subsequent verification is a rigorous, mathematical process that can
  615.      be greatly aided by the use of automated verification tools.  The Orange
  616.      Book requires the use of such a tool in the verification of A1 systems:
  617.      "This verification evidence shall be consistent with that provided within
  618.      the state-of-the-art of the particular Center endorsed formal
  619.      specification and verification system used."
  620.      
  621.      The Center endorsed verification tools are maintained on the
  622.      Endorsed Tools List.  Examples of these verification tools are Formal
  623.      Development Methodology, Gypsy, and Enhanced Hierarchical Development
  624.      Methodology.  For information concerning the current entries on the
  625.      Endorsed Tools List, vendors should contact the Computer Hardware and
  626.      Software Support Division.
  627.      
  628.  
  629. TECHNICAL GUIDELINES
  630.  
  631. To complement the information contained in the Orange Book, the Center
  632. publishes technical guidelines which serve as additional guidance in
  633. interpreting the established standard.  These technical guidelines aid in the
  634. evaluation and selection of computer security products, both complete systems
  635. and subsystems.  In addition, they are used throughout the Federal Government
  636. and by Federal Government contractors as guidance for the procurement, use,
  637. and disposal of automation systems and their associated magnetic storage
  638. media.
  639.  
  640. The Technical Guidelines Program contributes to the technical literature on
  641. issues of computer security. Guidelines are written in response to
  642. demonstrated need in automated processing environments.
  643.  
  644. Participation in the development of technical guidelines is provided by the
  645. technical staff of the Center and its associated offices within the National
  646. Security Agency, by representatives of the Department of Defense and the
  647. Intelligence Community, by civil agencies of the Federal Government, by
  648. Federally Funded Research and Development Centers, by contracted analytic and
  649. technical firms, and by selected experts in the particular field of endeavor.
  650. Draft versions of proposed documents are extensively reviewed by a wide
  651. audience of interests, and comments are fielded for consideration before
  652. publication.
  653.  
  654. PUBLICATIONS
  655.  
  656. Technical guidelines that are published by the Center, and useful to a vendor
  657. in order to process a computer product through the Trusted Product Evaluation
  658. Program, will be provided in limited quantity by the INFOSEC Awareness
  659. Organization.
  660.  
  661. TRAINING
  662.                      
  663. The Center provides training on topics of major importance to vendors
  664. interested in the trusted product security evaluation process.
  665.  
  666. OTHER RELATED SERVICES  
  667.  
  668. Within the Information Security Organization, there are several separate but
  669. complementary programs which relate to the Trusted Product Evaluation Program.
  670. A brief description of each program is provided in subsequent paragraphs.  For
  671. more details, please contact the specific program office in the Points of
  672. Contact list.
  673.  
  674. Like the Trusted Product Evaluation Program, the Commercial Communications
  675. Security Endorsement Program is a business relationship which combines private
  676. sector leadership and expertise in equipment design, development and high
  677. volume production with the information security expertise of the National
  678. Security Agency. Specifically, this program is designed to encourage industry
  679. to embed United States Government proprietary cryptography into
  680. telecommunications products to meet the need to protect its classified and
  681. sensitive unclassified information. The Commercial Communications Security
  682. Endorsement Program products that are endorsed for protecting sensitive
  683. unclassified government information only are also available to the private
  684. sector. In today's computer networking environment, many products require both
  685. an encryption capability and a trusted computing base to meet user
  686. requirements. Companies whose products merge both communications and computer
  687. security disciplines are encouraged to become familiar with the requirements
  688. of the Commercial Communications Security Endorsement Program.
  689.  
  690. The Secure Data Network System Program was established in August 1986, when
  691. the National Security Agency joined in partnership with ten major
  692. telecommunications and computer companies to develop a security architecture
  693. and a user-friendly key management system using the Open Systems
  694. Interconnection model.á The ultimate goal of the Secure Data Network System
  695. Program is to provide for the development of information security products
  696. that can operate over a broad range of commercial data networks.  Once the
  697. Secure Data Network System architecture is formalized, the development of
  698. Secure Data Network System products will be carried out under the auspices of
  699. the Commercial Communications Security Endorsement Program.
  700.  
  701. The Industrial TEMPEST Program is designed to aid industry in developing and
  702. testing TEMPEST-suppressed equipment which can be offered for sale to the
  703. United States Government.  Companies developing trusted computing products
  704. should be aware that the United States Government may require that products
  705. protecting classified information be TEMPEST-suppressed.  
  706.  
  707. A company that produces computer security products may be interested in the
  708. Department of Treasury's Electronic Funds Transfer Certification Program if
  709. the primary function of its product is to provide message authentication in
  710. support of United States Government financial transactions.  The program
  711. specifically provides for testing, evaluating and certifying Message
  712. Authentication Code devices for Federal electronic funds transfer use in
  713. accordance with American National Standards Institute Standard X9.9.  In
  714. addition, elements of Federal Standard 1027 covering minimum general security
  715. requirements for implementing the Data Encryption Standard encryption
  716. algorithm are included.  Optional electronic key management is based on
  717. American National Standards Institute Standard X9.17.
  718.  
  719. Vendors who are developing trusted computer products as Independent Research
  720. and Development Projects may obtain technical assistance and technical plan
  721. evaluations by contacting the Center's Office of Computer Security Research
  722. and Development.
  723.  
  724. The Computer Security Technical Vulnerability Reporting Program, promulgated
  725. in Department of Defense Instruction 5215.2 in September 1986, provides a
  726. mechanism for reporting weaknesses or design deficiencies in hardware,
  727. firmware, or software that leave automated information systems open to
  728. potential exploitation.  Technical vulnerabilities reported in Evaluated
  729. Products List items could possibly change the overall rating of the product.
  730.  
  731.             Points of Contact
  732.  
  733. COMMERCIAL COMMUNICATIONS SECURITY ENDORSEMENT PROGRAM
  734.  
  735.         Director, National Security Agency
  736.         Attention: Office of Industrial Relations
  737.         9800 Savage Road
  738.         Fort George G.Meade, MD 20755-6000 
  739.         (301) 688-6581 
  740.         
  741. TRUSTED PRODUCT EVALUATION PROGRAM 
  742.         Director,National Security Agency
  743.         Attention: Office of Industrial Relations
  744.         9800 Savage Road
  745.         Fort George G.Meade, MD 20755-6000 
  746.         (301) 688-6581 
  747.         
  748. COMPUTER SECURITY TECHNICAL VULNERABILITY REPORTING PROGRAM
  749.         Director,National Security Agency
  750.         Attention: Vulnerability Reporting Program
  751.         9800 Savage Road 
  752.         Fort George G.  Meade, MD 20755-6000
  753.         (301) 688-6079
  754.         
  755. DEPARTMENT OF TREASURY'S ELECTRONIC FUNDS TRANSFER CERTIFICATION PROGRAM
  756.         Assistant Director, Security Programs 
  757.         Department of Treasury
  758.         15th and Pennsylvania Avenue NW 
  759.         Washington, DC 20220
  760.         (202) 566-5152
  761.         
  762. DOCKMASTER AND VERIFICATION TOOLS
  763.         National Computer Security Center 
  764.         Attention: Computer Hardware and Software Support Division
  765.         9800 Savage Road
  766.         Fort George G.  Meade, MD 20755-6000
  767.         (301) 859-4360
  768.         
  769.         
  770. INDEPENDENT RESEARCH AND DEVELOPMENT PROJECTS PROGRAM
  771.         National Computer Security Center
  772.         Attention: Office of Computer Security Research and 
  773.              Development 
  774.         9800 Savage Road
  775.         Fort George G.Meade, MD 20755-6000
  776.         (301) 859-4486
  777.         
  778. INDUSTRIAL TEMPEST PROGRAM
  779.         Ford Aerospace and Communications Corporation
  780.         Attention: Mail Stop 3 (Industrial TEMPEST Program)
  781.         7170 Standard Drive
  782.         Hanover, MD 21076
  783.         (301) 796-5254
  784.         
  785. PUBLICATIONS AND TRAINING
  786.         Superintendent of Documents
  787.         U.S.  Government Printing Office
  788.         ashington, DC 20402
  789.         (202) 783-3238 
  790.         
  791.         U.S.  Department of Commerce
  792.         National Technical Information Service
  793.         5285 Port Royal Road 
  794.         Springfield, VA 22161
  795.         (703) 487-4650
  796.         
  797. SECURE DATA NETWORK SYSTEM PROGRAM
  798.         Director, National Security Agency
  799.         Attention: Secure Data Network Systems SPO
  800.         9800 Savage Road
  801.         Fort George G.  Meade, MD 20755-6000
  802.         (301)668-7110
  803.         
  804. TECHNICAL GUIDELINES
  805.         National Computer Security Center
  806.         Attention: Technical Guidelines Division
  807.         9800 Savage Road
  808.         Fort George G.  Meade, MD 20755-6000
  809.         
  810.         
  811.  
  812.                 REFERENCES
  813.         
  814.         
  815. DoD 3204.1, Independent Research and Development, Under Secretary of Defense
  816. for Research and Engineering, 1 December 1983.
  817.  
  818.  
  819. DoD Directive 5200.28, Security Requirements for Automatic Data Processing
  820. (ADP) Systems, revised April 1978.
  821.  
  822. DoD 5200.28-STD, Department of Defense Standard, Department of Defense Trusted
  823. Computer System Evaluation Criteria, December 1985; supersedes CSC-STD-001,
  824. dated 15 August 1983.
  825.  
  826. DoD Directive 5215.1, Computer Security Evaluation Center, 25 October 1982.
  827.  
  828. DoD Instruction 5215.2, Computer Security Technical Vulnerability Reporting
  829. Program, 2 September 1986.
  830.  
  831. National Telecommunications and Information System Security Policy No.  200,
  832. National Policy on Controlled Access Protection Policy, 15 July 1987.
  833.  
  834. NCSC-TG-005 Version 1, Trusted Network Interpretation of The Trusted Computer
  835. System Evaluation Criteria, 31 July 1987.
  836.  
  837.  
  838. ATTACHMENT I
  839.  
  840. SPECIFICATIONS AND DESIGN DOCUMENTATION
  841.  
  842. When a vendor enters into a product evaluation, he must present evidence that
  843. his system and its design meets the appropriate criteria requirements.
  844. Examples of the type of evidence normally submitted to support an evaluation
  845. include the design specifications that explain the security mechanisms, the
  846. Trusted Computing Base (TCB) arguments that show how the TCB is tamperproof,
  847. always invoked and small enough to be analyzed.  Also, the model (or
  848. philosophy of protection) and how it relates to the implementation are
  849. important parts of the evidence.  The best test of evidence is that it must
  850. include all the information such that a new team that is basically unfamiliar
  851. with the product could evaluate only the evidence and reach the proper
  852. conclusion.  
  853.  
  854. In order for the evaluation team to review this evidence and determine whether
  855. the system complies with these requirements, the team must develop a
  856. conceptual understanding of how the system being evaluated operates.
  857. Generally, the evaluation team can acquire this level of understanding by
  858. reviewing the vendor's system documentation and specifications.  The following
  859. types of high level system documents are typically required by the evaluation
  860. team:
  861.  
  862.     User-Level Documentation
  863.     
  864.     Provides users an overview of the system, its functioning, and
  865.     information on user services.  
  866.     
  867.     Operational Manuals
  868.     
  869.     Contains general description,implementation and usage information
  870.     for the system.  It is intended for use by system programmers who
  871.     service the system.  
  872.     
  873.     Program Logic Manuals
  874.     
  875.     Documents the internal operation and organization of a system.  It
  876.     is intended for use by system programmers for program maintenance
  877.     and to determine the location of program malfunctions.  
  878.     
  879.     Administrative Manuals
  880.     
  881.     Documents the procedures for installing and generating the system.  
  882.     
  883.     Hardware and Software System Specifications
  884.     
  885.     Includes Hardware and Software design and implementation details of
  886.     the system major components
  887.     
  888.     
  889.               ATTACHMENT II
  890.  
  891. TEST PLANNING
  892.  
  893. The Department of Defense Trusted Computer System Evaluation Criteria (Orange
  894. Book) requires that vendors provide a document to the evaluators that
  895. describes the test plan, test procedures, and the results of the security
  896. mechanisms functional testing.  Security mechanisms are those mechanisms that
  897. are relevant to the Orange Book.  These include object reuse, labeling,
  898. discretionary access control (DAC), mandatory access control (MAC),
  899. identification and authentication, auditing, and trusted path.  A security
  900. related functional test plan should determine whether the system being
  901. evaluated has any design and implementation flaws that would permit a subject
  902. external to the Trusted Computing Base (TCB) to read, change, or delete data
  903. which he would not normally have access to under the mandatory or
  904. discretionary security policy enforced by the TCB.  [The TCB is defined by the
  905. TCSEC as "the totality of protection mechanisms within a computer system --
  906. including hardware, firmware, and software --the combination of which is
  907. responsible for enforcing a security policy"].  Security related functional
  908. tests involve all security properties of a system (i.e., all aspect of the TCB
  909. that affect or can be affected by a security mechanism).
  910.  
  911. COVERAGE OF TESTING
  912.  
  913. Although many standard testing methods are acceptable in fulfilling the Orange
  914. Book testing requirements, they are, for all but very small or simplistic
  915. systems, impractical to use due to the large amount of resources required.
  916. Some methods of testing that have in the past proven to be sufficient and were
  917. reasonable to implement are Interface and Mechanism testing.  
  918.  
  919. Interface testing refers to testing the TCB at the user interface (i.e., user
  920. callable routines).  Generally, critical boundaries of each security mechanism
  921. are determined and test cases on both sides of these boundaries are generated.
  922. The critical boundary of a security mechanism is the point at which the rule
  923. it is designed to implement is or is not invoked.  This provides more
  924. assurance that the view of the system presented to a user is correct.
  925.  
  926. Mechanism testing refers to the testing of the security mechanisms that the
  927. TCB supports (i.e., DAC , object reuse, audit, etc.).  Mechanism can consist
  928. of one or more interface, and some interfaces can be called by different
  929. mechanisms.  Mechanism testing shows that the TCB supports these mechanisms.
  930. The sufficiency of the different methods of testing are dependent on the
  931. particular class of the Orange Book the system is being evaluated against.
  932.  
  933.  
  934. TESTING A B2-A1 SYSTEM:
  935.  
  936. TCB interface testing is sufficient.  Every interface must be tested.  Since
  937. B2, B3 or A1 systems are well structured, and their Detailed Top Level
  938. Specifications (DTLS) and Formal Top Level Specifications (FTLS) provide a
  939. complete and accurate description of the TCB interface, the testing of the TCB
  940. interfaces can reasonably be expected to be very comprehensive.
  941.  
  942. TESTING A C1-B1 SYSTEM:
  943.  
  944. Mechanism testing is probably sufficient.  The structure allowed by a C1-B1
  945. architecture would most likely make interface testing impractical.  It is
  946. likely that an evaluation team may determine, through inspection of the
  947. system's test plan and its architecture, that black box testing of the
  948. interface is insufficient and requires "white box" testing of instrumental
  949. code sections.
  950.     
  951. DOCUMENTATION
  952.  
  953. Documentation of a test should be specific and briefly describe the TCB
  954. mechanism being tested.  The expected results of each test case should be set
  955. forth.  The test documentation should also contain an overview of the test
  956. methods being used, and the security properties which are and are not
  957. pertinent for each particular mechanism.  A list of all assumptions being made
  958. about the testing environment should also be included .  
  959.  
  960. The Orange Book functional testing requirements also require that both the
  961. system and the test plan be maintained using good configuration management
  962. techniques.  This allows the vendor to provide a form of Life-cycle assurances
  963. for the system.  Life-cycle assurance is a procedure for managing system
  964. design, development, and maintenance using a method of rigorous and formalized
  965. controls and standards.  It allows the vendor to reevaluate the system when
  966. changes are made to determine whether the integrity of the protection
  967. mechanism has been affected 
  968.  
  969.  
  970. ATTACHMENT III
  971.  
  972.  
  973. REQUIRED DOCUMENTATION
  974.  
  975. The Orange Book requires that a vendor produce documentation which describes
  976. the system protection mechanisms, how the system can operate using these
  977. protection mechanisms, how the system developer designed security into the
  978. system, and how these security features and system were tested.  The amount of
  979. documentation required increases with the targeted Orange Book class.  The
  980. specific requirements are listed below starting at the lower Orange Book
  981. classes and progressing through the higher classes.  In some cases, additional
  982. documentation may be required
  983.  
  984. C1 - DISCRETIONARY ACCESS CONTROL
  985.  
  986. Security Features User's Guide tells users how to use the security mechanisms
  987. of the system.  It provides the necessary information to understand and
  988. effectively use the discretionary access control mechanisms to protect
  989. information.
  990.  
  991. Trusted Facility Manual tells the system administrator how to set the system
  992. up so that it stays secure.  It should tell the administrator how to select
  993. the proper options such that the system is operated in a mode that meets the
  994. requirements of the Criteria.  If there are unsecure modes that the system can
  995. run in, the manual should clearly state their impact on the security and
  996. include warnings as appropriate.  This manual should also include any
  997. procedures the administrator should use during operations to maintain
  998. security.  If any of the hardware/software features require administrator
  999. actions to complete the security protection, they should be thoroughly
  1000. described.
  1001.  
  1002. Test Documentation describes results of security mechanism's functional
  1003. testing.  This documentation is used by the evaluation team to assess the
  1004. testing performed by the vendor.  This document describes those tests, how
  1005. they are run, and how to properly interpret the results.
  1006.  
  1007. Design documentation provides the rationale and supporting evidence for the
  1008. security of the design of the system.  The descriptive specifications are
  1009. included in this evidence.  It is intended to provide the sort of information
  1010. a new developer would need in order to support the system.  It should include
  1011. the manufacturer's philosophy of protection.  If the TCB consists of distinct
  1012. modules, the design documentation describes the interfaces between these
  1013. modules.
  1014.  
  1015. C2 - CONTROLLED ACCESS PROTECTION
  1016.  
  1017. Security Features User's Guide remains the same as C1.  
  1018.  
  1019. Trusted Facility Manual is the same as C1, but also requires details on how to
  1020. maintain audit data.
  1021.  
  1022. Test Documentation remains the same as C1.
  1023.  
  1024. Design Documentation is the same as C1.
  1025.  
  1026. B1 - MANDATORY PROTECTION
  1027.  
  1028. Security Features User's Guide remains the same as C2., but also describes the
  1029. additional security mechanisms required at this class (i.e., Mandatory Access
  1030. Control).
  1031.  
  1032. Trusted Facility Manual remains the same as C2, but also describes the
  1033. operator and administrator functions related to security.  This includes an
  1034. explanation of what's involved in changing the security characteristics of a
  1035. user, and a description of facility procedures, warnings, and privileges that
  1036. need to be controlled in order to operate the facility in a secure manner.
  1037.  
  1038. Test Documentation remains the same as C2.
  1039.  
  1040. Design Documentation remains the same as C2, but also describes the security
  1041. policy model (either formally, i.e., mathematically, or informally, i.e., in
  1042. English) and how the TCB implements this model.
  1043.  
  1044. B2 - STRUCTURED PROTECTION
  1045.  
  1046. Security Features User's Guide remains the same as B1, but also describes the
  1047. additional security mechanisms required by this class (i.e., Trusted Path).
  1048.  
  1049. Trusted Facility Manual remains the same as B1, but also details what
  1050. constitutes the TCB and how it can be modified.  It also describes how
  1051. separate operator and administrator functions need to be supported.
  1052.  
  1053. Test Documentation remains the same as B1, but includes the results of covert
  1054. channel tests.  Covert channels are communication paths that allow a process
  1055. to transfer information in a manner that violates the system's security
  1056. policy.
  1057.  
  1058. Design Documentation remains the same as B1, but also includes a formal
  1059. description of the model, and proof that it is sufficient for the policy.  It
  1060. will also describe how the TCB implements the reference monitor concept and
  1061. how it enforces the principle of least privilege.
  1062.  
  1063. B3 - SECURITY DOMAINS
  1064.  
  1065. Security Features User's Guide remains the same as B2, but also describes the
  1066. additional security mechanisms required at this class .
  1067.  
  1068. Trusted Facility Manual remains the same as B2, but also includes a
  1069. description on how to start up and restore the system security.  It also
  1070. describes the role of the Security Administrator.
  1071.  
  1072. Test Documentation remains the same as B2.
  1073.  
  1074. Design Documentation remains the same as B2, but also includes the
  1075. correspondence between the Detailed Top Level Specifications and the TCB.  The
  1076. TCB implementation is also shown to be informally consistent with the Detailed
  1077. Top Level Specifications.
  1078.  
  1079. A1 - VERIFIED PROTECTION
  1080.  
  1081. Security Features Users's Guide remains the same as B3.
  1082.  
  1083. Trusted Facility Manual remains the same as B3.
  1084.  
  1085. Test Documentation remains the same as B3, but also includes the results of
  1086. the mapping between the Formal Top Level Specifications and the TCB source
  1087. code.
  1088.  
  1089. Design Documentation remains the same as B3, but also includes a description
  1090. of the components that are strictly internal to the TCB.  It also includes a
  1091. Formal Top Level Specification to TCB correspondence.
  1092.  
  1093.     
  1094.