Search the FAQ Archives

3 - A - B - C - D - E - F - G - H - I - J - K - L - M
N - O - P - Q - R - S - T - U - V - W - X - Y - Z
faqs.org - Internet FAQ Archives

Computer Security Evaluation FAQ, Version 2.1


[ Usenet FAQs | Web FAQs | Documents | RFC Index | Business Photos and Profiles ]
Posting-Frequency: monthly
Archive-name: computer-security/evaluations

See reader questions & answers on this topic! - Help others by sharing your knowledge
The Computer Security Evaluation Frequently Answered Questions (V2.1)

This FAQ is designed to answer common questions about the evaluation of
trusted products.  It is being posted to comp.security.misc
comp.security.unix, comp.answers and news.answers.  We have attempted to be as
clear, precise, accurate, and correct as possible.  Some answers are
undoubtedly closer to this ideal than others.  Comments on the FAQ may be sent
to TPEP@dockmaster.ncsc.mil.  The current official version of this FAQ may be
found at <http://www.radium.ncsc.mil/tpep/process/faq.html>.

----------

Subject: Contents

Section I: The Trusted Product Evaluation Program (TPEP)
  1. What is the National Computer Security Center (NCSC)?
  2. What is TPEP?
  3. How is TPEP related to the National Security Agency (NSA)?
  4. How is TPEP related to the National Institute of Standards
     and Technology (NIST)?
  5. How do I contact the TPEP?
  6. What is the TTAP?
  7. What is Dockmaster?
  8. Why doesn't TPEP have a WWW server on Dockmaster?
Section II: Criteria
  1. What is the criteria used for evaluation?
  2. What is the TCSEC?
  3. What is the Orange Book?
  4. What are interpretations?
  5. What is the Interpreted TCSEC (ITCSEC)?
  6. What is the ITSEC (as opposed to the ITCSEC)?
  7. What is the CTCPEC?
  8. What is the Common Criteria?
  9. What is the TNI?
 10. What is the TDI?
 11. What is the Rainbow Series?
 12. What are Process Action Team (PAT) Guidance Working Group (PGWG)
     documents?
 13. Is there a criteria for commercial (as opposed to military) systems?
 14. What is the Federal Criteria?
 15. What are the CMWREQs and the CMWEC?
Section III: Criteria Concepts
  1. What are security features?
  2. What is assurance?
  3. What is a division?
  4. What is a class?
  5. What is a network component?
  6. What is a Network Security Architecture Design (NSAD) document?
  7. How do I interpret a rating?
  8. The TCSEC is 10 years old, doesn't that mean it's outdated?
  9. How do the TCSEC and its interpretations apply to routers and
     firewalls?
 10. Does a trusted system require custom hardware?
 11. What are the requirements for a D/C1/C2/B1/B2/B3/A1 system?
Section IV: Evaluations
  1. How do I get my product evaluated?
  2. What is the evaluation process?
  3. How long does an evaluation take?
  4. How much does an evaluation cost?
  5. How do I find out about the evaluation process?
  6. Who actually performs the evaluations?
  7. What information is released about an evaluated product?
  8. What is RAMP?
Section V: Evaluated Products
  1. Should I buy an evaluated product?
  2. Does NSA buy/use evaluated products?
  3. How do I know if a product is evaluated?
  4. What does it mean for a product to be "in evaluation"?
  5. What does it mean for a product to be "compliant" with the TCSEC?
  6. What and where is the Evaluated Products List (EPL)?
  7. How do I get a copy of an evaluation report?
  8. Is an evaluated product "hacker proof?"
  9. What is the rating of DOS?
 10. What is the rating of UNIX?
 11. What should I do if evaluated Product X appears to fail a requirement?
 12. Why should I buy a B2/B3/A1 product over a C2/B1 product?
 13. Is there an approved program to declassify my hard drive?

----------

Subject: Section I: The Trusted Product Evaluation Program (TPEP)

  1. What is the National Computer Security Center (NCSC)?

          The Department of Defense Computer Security Center was
          established in 1981 to encourage the widespread availability of
          trusted computer systems for use by facilities processing
          classified or other sensitive information.  In August 1985 the
          name of the organization was changed to the National Computer
          Security Center (NCSC).  The NCSC may be reached at:

              National Computer Security Center
              9800 SAVAGE ROAD
              FT MEADE MD 20755-6000

          or by phone at (410) 859-4376.

  2. What is TPEP?

          The Trusted Product Evaluation Program (TPEP) is the program by
          which the NCSC evaluates computer systems against security
          criteria.  The Trusted Product Evaluation Program (TPEP) is
          operated by an organization separate from the National Computer
          Security Center (NCSC).  The TPEP performs computer security
          evaluations for, and on behalf of, the NCSC.

  3. How is TPEP related to the National Security Agency (NSA)?

          Both the Trusted Product Evaluation Program (TPEP) and the
          National Computer Security Center (NCSC) are organizational
          units within the National Security Agency (NSA).  The TPEP and
          NCSC are two of a number of organizational units within the NSA
          responsible for the information system security mission with
          respect to classified and sensitive data (see
          <http://www.nsa.gov:8080/>).

  4. How is TPEP related to the National Institute of Standards
     and Technology (NIST)?

          In Public Law 100-235 congress directed the National Security
          Agency (NSA), of which the Trusted Product Evaluation Program
          (TPEP) is a part, to lead the efforts of the United States
          Government in information systems security for classified
          information.  The National Institute of Standards and Technology
          (NIST) as part of the Department of Commerce is directed to
          lead the efforts for sensitive but unclassified information
          with technical support from the NSA.  The NSA and NIST have
          established a Memorandum of Understanding detailing the
          responsibilities of each organization with respect to the other
          in this area.  While NSA and NIST each have individual efforts,
          the agencies attempt to develop methods and standards that are
          compatible.  (see <http://csrc.ncsl.nist.gov/>)
          
  5. How do I contact the TPEP?

          The Trusted Product Evaluation Program can be reached by mail at

             V24, TRUSTED PRODUCT EVALUATION PROGRAM
             NATIONAL SECURITY AGENCY
             9800 SAVAGE ROAD STE 6753
             FT MEAD MD 20755-6753
          
          or by phone at (410) 859-4458.
          
  6. What is the TTAP?

          The Trust Technology Assessment Program (TTAP) is a joint
          National Security Agency (NSA) and National Institute of
          Standards and Technology (NIST) effort to commercialize the
          evaluation of commercial-off-the-shelf (COTS) products at the
          lower levels of trust.  Under the auspice of the National
          Voluntary Laboratory Accreditation Program (NVLAP), TTAP will
          establish, accredit and oversee commercial evaluation
          laboratories focusing initially on products with features and
          assurances characterized by the Trusted Computer System
          Evaluation Criteria (TCSEC) B1 and lower levels of trust
          (see Section II, Question 2 and Section III, Question 4).
          Vendors desiring a level of trust evaluation will contract with
          an accredited laboratory and pay a fee for their product's
          evaluation. (see <http://csrc.ncsl.nist.gov/ttap/>)

          TTAP approval and oversight mechanisms will assure continued
          quality and fairness.  Using the NVLAP model of standardized
          testing and analysis procedures, TTAP will strive to achieve
          mutual recognition of evaluations with other nations.  The
          European Community evaluations are performed under the purview
          of national test standardization bodies associated with NVLAP.

          The TTAP is being established with a planned transition from
          TCSEC based evaluations to Common Criteria based evaluations
          (see Section II, Question 8).  The implementation of the Common
          Criteria will occur upon acceptance of the Common Criteria and
          the Common Evaluation Methodology, which is in the process of
          being developed.

  7. What is Dockmaster?

          Dockmaster, or more precisely dockmaster.ncsc.mil, is an
          unclassified computer system used by the Trusted Product
          Evaluation Program (TPEP) to exchange information between
          product evaluators, vendors, and others within the computer
          system security community.  Dockmaster is based on the
          B2-evaluated Honeywell MULTICS product.  This is a very old
          platform, and efforts are underway to replace Dockmaster with a
          more current product.  In addition to use by the TPEP and the
          NCSC, dockmaster provides service to the information security
          community through electronic mail, bulletin boards, and forums
          for the exchange of ideas.  Online access to the INFOSEC Product
          and Services Catalogue is available.  Information is provided
          about training courses and scheduled INFOSEC conferences.

          To register for an account, write to:

              Attn: Dockmaster Accounts Administrator
              National Computer Security Center
              9800 SAVAGE ROAD
              FT MEADE MD 20755-6000

  8. Why doesn't TPEP have a WWW server on Dockmaster?

          Many desirable network access features are not available in the
          MULTICS operating system used by Dockmaster.  As the system is
          upgraded, it is anticipated that it will support some of these
          features.  The TPEP WWW server is available at
          <http://www.radium.ncsc.mil/tpep/>.
          
----------

Subject: Section II: Criteria

  1. What is the criteria used for evaluation?

          The criteria currently used by the Trusted Product Evaluation
          Program (TPEP) to grade the security offered by a product is
          the Trusted Computer System Evaluation Criteria (TCSEC), dated
          1985 (see Section II, Question 2)

  2. What is the TCSEC?

          The Trusted Computer System Evaluation Criteria (TCSEC) is a
          collection of criteria used to grade or rate the security
          offered by a computer system product.  The TCSEC is sometimes
          referred to as "the Orange Book" because of its orange cover.
          The current version is dated 1985 (DOD 5200.28-STD, Library No.
          S225,711)  The TCSEC, its interpretations and guidelines all
          have different color covers, and are sometimes known as the
          "Rainbow Series" (see Section II, Question 11.) It is available at
          <http://www.radium.ncsc.mil/tpep/library/rainbow/5200.28-STD.html>

  3. What is the Orange Book?

          See Section II, Question 2.

  4. What are interpretations?

          It is often the case that there are several ways to read a
          given statement in the Trusted Computer System Evaluation
          Criteria (TCSEC).  Interpretations are official statements
          articulating which of a number of possible ways to read the
          requirement are the acceptable ways for purposes of evaluation
          by the TPEP.  Interpretations are developed by an group of
          highly experienced product evaluators.  These interpretations
          in proposed form are available for comment by all users of
          Dockmaster (see Section 1, Question 6) including vendors with
          products in evaluation.  After considering the comments and
          revising the interpretation as appropriate (sometime through
          several rounds of comments and revision) the interpretation is
          accepted by the TPEP and officially announced.

  5. What is the Interpreted TCSEC (ITCSEC)?

          The Interpreted Trusted Computer System Evaluation Criteria
          (ITCSEC) is a version of the TCSEC maintained by the Trusted
          Product Evaluation Program (TPEP) that annotates the TCSEC
          requirements with all current interpretations.  It is available
          in postscript from
          <http://www.radium.ncsc.mil/tpep/library/tpep/ITCSEC.ps>.

  6. What is the ITSEC (as opposed to the ITCSEC)?

          The Information Technology Security Evaluation Criteria (ITSEC)
          is a European-developed criteria filling a role roughly
          equivalent to the TCSEC.  While the ITSEC and TCSEC have many
          similar requirements, there are some important distinctions.
          The ITSEC places increased emphasis on integrity and
          availability, and attempts to provide a uniform approach to the
          evaluation of both products and systems.  The ITSEC also
          introduces a distinction between doing the right job
          (effectiveness) and doing the job right (correctness).  In so
          doing, the ITSEC allows less restricted collections of
          requirements for a system at the expense of more complex and
          less comparable ratings and the need for effectiveness analysis
          of the features claimed for the evaluation.  The question of
          whether the ITSEC or TCSEC is the better approach is the
          subject of sometimes intense debate.  The ITSEC is available in
          postscript at
          <http://www.radium.ncsc.mil/tpep/library/non-US/ITSEC-1.2.html>.

          On 21 August 1995, The National Institute of Standards and
          Technology (NIST) released a draft National Computer Systems
          Laboratoty (NCSL) Bulletin.  This draft bulletin adresses the
          relationship of low assurance products evaluated under the
          TCSEC, ITSEC, and CTCPEC.  In the case of the ITSEC, it is
          recommended that if an appropriate C2 rated product is not
          available, that ITSEC rated FC2/E2 products be used.

  7. What is the CTCPEC?

          The Canadian Trusted Computer Product Evaluation Criteria is
          the Canadian equivalent of the TCSEC.  It is somewhat more
          flexible than the TCSEC (along the lines of the ITSEC) while
          maintaining fairly close compatibility with individual TCSEC
          requirements.  The CTCPEC is available at
          <http://www.cse.dnd.ca/Services/Criteria/English/Criteria.html>.

          On 21 August 1995, The National Institute of Standards and
          Technology (NIST) released a draft National Computer Systems
          Laboratoty (NCSL) Bulletin.  This draft bulletin adresses the
          relationship of low assurance products evaluated under the
          TCSEC, ITSEC, and CTCPEC.  In the case of the CTCPEC, it is
          recommended that if an appropriate C2 rated product is not
          available, that CTCPEC products rated with a C2 functionality
          profile and T1 assurance be used.

  8. What is the Common Criteria?

          The Common Criteria (CC) occasionally (and somewhat
          incorrectly) referred to as the Harmonized Criteria, is a
          multinational effort to write a successor to the TCSEC and
          ITSEC that combines the best aspects of both.  An initial
          version (V 1.0) was released in January of 1996.  The CC has
          a structure closer to the ITSEC than the TCSEC and includes
          the concept of a "profile" to collect requirements into easily
          specified and compared sets.  The TPEP is actively working to
          develop profiles and an evaluation process for the CC.  We
          anticipate beginning several trial CC evaluations late in
          calendar year 1996. It is available in postscript from
          <http://www.radium.ncsc.mil/tpep/library/ccitse/>

  9. What is the TNI?

          The Trusted Network Interpretation (TNI) of the TCSEC, also
          referred to as "The Red Book," is a restating of the
          requirements of the TCSEC in a network context.  Evaluations of
          the type of systems (sometimes called distributed or
          homogeneous) described by Part I are often evaluated directly
          against the TCSEC without reference to the TNI.  TNI component
          evaluations are evaluations performed against Appendix A of the
          TNI.  (see Section III, Question 5)  It is available in at
          <http://www.radium.ncsc.mil/tpep/library/rainbow/NCSC-TG-005.html>.

  10. What is the TDI?

          The Trusted Database Interpretation (TDI) of the TCSEC is
          similar to the Trusted Network Interpretation (TNI) in that it
          decomposes a system into independently evaluatable components.
          It differs from the TNI in that the paradigm for this
          decomposition is the evaluation of an application (e.g.,
          database) running on an already evaluated system.  The Trusted
          Product Evaluation Program (TPEP) has to date only evaluated
          databases using this interpretation.  In principle arbitrary
          trusted applications could be evaluated.  It is available at
          <http://www.radium.ncsc.mil/tpep/library/rainbow/NCSC-TG-021.html>.

 11. What is the Rainbow Series?

          The "Rainbow Series" is the name given to the collection of
          interpretation documents (e.g., TNI and TDI) and guidance
          documents (e.g., Guide to understanding MAC, Password
          Guidelines) published by the National Computer Security Center
          (NCSC).  Each document has a different color cover, thus the
          name "Rainbow Series."  The guidelines of the rainbow series,
          are designed to expand on, and clarify, the requirements in the
          Trusted Computer System Evaluation Criteria (TCSEC).  They are,
          however, only guidance.  The words of the requirements and
          interpretations are used as the metric for evaluation, not the
          guidelines.  A single copy of every rainbow series
          document is available without charge to U.S. addresses
          by writing to:

              INFOSEC AWARENESS, ATTN: Y13/IAOC
              DEPARTMENT OF DEFENSE
              9800 SAVAGE ROAD
              FT MEADE MD 20755-6000

          or by calling (410) 766-8729.  Additional copies may be
          obtained from the Government Printing Office.  The Trusted
          Computer System Evaluation Criteria (TCSEC) and most of the
          other rainbow series documents are available at
          <http://www.radium.ncsc.mil/tpep/library/rainbow/>.

 12. What are Process Action Team (PAT) Guidance Working Group (PGWG)
     documents?

          The PGWG (often pronounced pig-wig) documents are also known
          as the Form and Content documents.  These documents are
          published directly by the Trusted Product Evaluation Program
          (TPEP) and are designed to provide guidance to vendors
          submitting products for evaluation.  This guidance is not
          security or requirements guidance in the Rainbow Series style.
          Rather, these documents provide rules used by the TPEP in
          accepting products into evaluation to ensure that the
          information provided to the evaluation team is in a state that
          is most conducive to a expeditious and trouble-free
          evaluation.  The document discussing design documentation is
          available in postscript at
          <http://www.radium.ncsc.mil/tpep/library/process_documents/PATdesign.ps>.
          The document discussing test documentation is available in
          postscript from
          <http://www.radium.ncsc.mil/tpep/library/process_documents/PATtest.ps>.

 13. Is there a criteria for commercial (as opposed to military) systems?

          The Trusted Product Evaluation Program (TPEP) is prohibited by
          the Computer Security Act of 1987 from attempting to directly
          address the needs of commercial systems.  The TPEP does not
          subscribe, however, to the often loudly espoused belief that
          the requirements of military systems are entirely divorced from
          the requirements of commercial systems.  It seems reasonable to
          believe that commercial computer system users require many of
          the same basic features of military systems: identification and
          authentication of the users requesting information or service
          from the system; ability to audit the actions of users; and
          control of access to information, both at the discretion of the
          information owner and by corporate policy.  Because the TCSEC
          couched its requirements in terms of DoD classifications, many
          people have not thought about applying them to similar needs
          for mandatory controls on protected information pertaining to
          product development, marketing, and personnel decisions.  It is
          one of the aims of the Common Criteria to provide criteria that
          use more general terminology.

 14. What is the Federal Criteria?

          The Federal Criteria was an attempt to develop a criteria to
          replace the Trusted Computer System Evaluation Criteria
          (TCSEC).  A draft version was released for public comment in
          December 1992.  However, this effort was supplanted by the
          Common Criteria effort (see Section II, Question 8), and the
          Federal Criteria never moved beyond the draft stage (although
          many of its ideas are retained in the Common Criteria).  There
          is no FINAL Federal Criteria; the draft should not be treated
          as a final criteria document.  The draft of the Federal
          Criteria is available at <http://hightop.nrl.navy.mil/rainbow.html>.

 15. What are the CMWREQs and the CMWEC?

          The criteria used by the Defense Intelligence Agency (DIA) to
          rate a product as a Compartmented Mode Workstation (CMW) is the
          Compartmented Mode Workstation Evaluation Criteria (CMWEC),
          which superseded the CMW Requirements (CMWREQs) in 1991. This
          criteria defines a minimum level of assurance equivalent to the
          B1 level of the TCSEC (see Section III, Questions 2-4).  It
          also defines a minimum set of functionality and usability
          features outside the scope of the TCSEC (e.g. a graphical user
          interface via a window system is required along with the
          capability to cut and paste between windows).  Neither set of
          requirements are currently used by the Trusted Product Evaluation
          Program (TPEP) although products that are designed to have these
          features may be evaluated as B1 or higher products.


----------

Subject: Section III: Criteria Concepts

  1. What are security features?

          A security feature is a specific implementable function in a
          system which supports some part of the system's security
          policy.  Examples of security features would be access control,
          trusted path, and audit.  The Trusted Computer System
          Evaluation Criteria (TCSEC) (see Section II, Question 1)
          ratings are not designed to express the rating of individual
          features, as are some other criteria.  Rather, each class
          specifies a set of security features that a system must
          implement in order to be rated at that class.  However, many
          evaluations are given "extra credit" in the evaluation results
          for successful implementations of features that are required
          only in a higher overall rating in the criteria.

  2. What is assurance?

          In the context of the Trusted Computer System Evaluation
          Criteria (TCSEC), assurance coincides with correctness
          assurance.  It is a measure of confidence that the security
          features and architecture of a computer system accurately
          mediate and enforce the system security policy.  The TCSEC's
          assurance-related requirements constrain development methods
          (e.g., configuration management) and software engineering
          practices (e.g., modular code).  Higher evaluation classes
          contain more assurance-promoting requirements and give more
          confidence in correctness.

  3. What is a division?

          A division is a set of classes (see Question 5) from the
          Trusted Computer System Evaluation Criteria (TCSEC) (see
          Section II, Question 1).  There are 4 divisions A, B, C, and D
          in decreasing order of assurance and features.  Thus, a system
          evaluated at a class in division B has more security features
          and/or a higher confidence that the features work as intended
          than a system evaluated at a class in division C.  Although the
          Computer Security Subsystem Interpretation (CSSI) of the TCSEC
          specifies criteria for various D ratings, these are not
          reflected in the TCSEC itself, which has no requirements for D
          division systems.  An unrated system is, by default, division
          D.

  4. What is a class?

          A class is the specific collection of requirements in the
          Trusted Computer System Evaluation Criteria (TCSEC) to which an
          evaluated system conforms.  There are seven classes in the
          TCSEC A1, B3, B2, B1, C2, C1, and D, in decreasing order of
          features and assurances.  Thus, a system evaluated at class B3
          has more security features and/or greater confidence that the
          security features work as intended than a system evaluated at
          class B1.  The requirements for a higher class are always a
          superset of the lower class.  Thus a B2 system meets every C2
          functional requirement and has a higher level of assurance.
          
  5. What is a network component?

          A "network component" is the target of evaluation for a Trusted
          Network Interpretation (TNI) evaluation (see Section II,
          Question 9) done against appendix A of the TNI.  These
          "network component" evaluations allocate basic requirements
          (Mandatory Access Control (MAC); Discretionary Access Control
          (DAC); Audit; and Identification and Authentication) to
          components of a "network system".  Each component may be
          evaluated in isolation.  The TPEP does evaluate degenerate TNI
          components that independently meet all basic requirements (but
          nevertheless have an interface to other, perhaps identical
          components), but has not evaluated any degenerate TNI component
          that met none of the basic requirements (relying totally on
          other components for the security features).  The TPEP is
          currently developing a more integrated approach to the evaluation
          of TNI components.  The preliminary report of the changes
          envisioned are available in postscript at
          <http://www.radium.ncsc.mil/tpep/library/process_documents/cwg-draft.ps>.

  6. What is a Network Security Architecture Design (NSAD) document?

          The documentation for a network component (see Section III,
          Question 5) must include a Network Security Architecture Design
          (NSAD) document which describes the security expectations by this
          component about other components.  Each component evaluation
          proceeds under the assumption that the expectations of the NSAD
          are met by the other components.  A collection of components
          designed around the same architecture should interoperate
          securely.
  
  7. How do I interpret a rating?

          A product evaluated by the Trusted Product Evaluation Program
          (TPEP) will have one of several styles of ratings.  A product
          evaluated against the Trusted Computer System Evaluation
          Criteria (TCSEC) will have one of the seven class ratings: A1,
          B3, B2, B1, C2, C1, or D (see Section III, Question 4.)  In
          addition a TCSEC evaluated product may be evaluated to have met
          requirements above it's class.  These would be specified
          additionally such as "meets the B1 requirements and the B2
          Trusted Path requirement."  It is very important to note that,
          for example, a B1 evaluated system with B2 trusted path,
          provides significantly less confidence that trusted path is
          implemented correctly than a B2 evaluated system.  That is to
          say that the assurance is always that of the system's rated
          class.

          Some systems have been evaluated against the Compartmented Mode
          Workstation (CMW) criteria.  The CMW criteria levies minimum
          features and assurances from the TCSEC as well as additional
          usability criteria (e.g., specifying that the window system must
          manipulate windows at multiple levels in certain ways.)  The
          TPEP has treated these systems as standard TCSEC evaluations
          with additional requirements.  From a security perspective the
          CMW requirements do not preclude a B2 or higher CMW, however,
          to this point all CMW evaluated systems are B1 evaluated with
          additional TCSEC features above the evaluated class.

          Another form of rating is a Trusted Network Interpretation
          (TNI) component (see Section III, Question 5) rating.  TNI
          component ratings specify the evaluated class as well as which
          of the four basic security services the evaluated component
          provides.  Thus, a B2-MD component is one that provides both
          Mandatory Access Control (MAC) and Discretionary Access Control
          (DAC).  A B1-MDIA component is one that provides MAC, DAC,
          Identification and Authentication, and Audit.  Since a B1-MDIA
          component meets all the Trusted Computer System Evaluation
          Criteria (TCSEC) requirements for B1, it is likely that this
          component is also evaluated as a B1 system if it can be used in
          a non-network configuration.

          A third form of rating is a Trusted Database Interpretation
          (TDI) rating.  This rating is the same as a TCSEC rating except
          that the rating applies to the composite of the evaluated
          application and each of the listed underlying systems.

          Finally, products evaluated against the Computer Security
          Subsystem Interpretation (CSSI) of the TCSEC have been given
          variations of D division (see Question 4) ratings.  These
          appear for example as I&A/D2, Audit/D1, DAC/D3, and OR/D.
          These products all have very low assurance regardless of the
          features.

  8. The TCSEC is 10 years old, doesn't that mean it's outdated?

          The Trusted Computer System Evaluation Criteria (TCSEC) was
          published in 1985.  While some of the details need
          interpretation for current systems, in general the requirements
          of the TCSEC are at a level of abstraction that has not
          experienced great change.  For the areas where it is becoming
          difficult to use the TCSEC, the Common Criteria (see Section
          II, Question 8) should provide more relevant criteria.

  9. How do the TCSEC and its interpretations apply to routers and
     firewalls?

          The Trusted Network Interpretation (TNI) of the TCSEC has been
          used to evaluate these types of products.  While there is some
          value to those evaluations it is true that many of the specific
          mechanisms of these products on which one might wish to have an
          evaluator comment are not recognized by the TNI.  It is hoped
          that the Common Criteria (see Section II, Question 8) will be
          able to address these products more directly with, for example,
          an appropriate profile.

 10. Does a trusted system require custom hardware?

          A system does not require custom hardware to be successfully
          evaluated against the Trusted Computer System Evaluation
          Criteria (TCSEC).  However, an evaluation does consider the
          security of the system hardware as well as software.  For every
          evaluated product, there is an evaluated configuration.  The
          evaluated configuration lists the specific hardware and
          software evaluated.  A given evaluation may require hardware
          with certain security features used by the software, and the
          software may require certain optional features be enabled or
          disabled.  The Final Evaluation Report (FER) (see Section V,
          Question 7) lists the evaluated hardware and software.  The
          Trusted Facility Manual (TFM) for the product will give
          detailed guidance on configuring the hardware and software
          securely.

 11. What are the requirements for a D/C1/C2/B1/B2/B3/A1 system?

          The Interpreted Trusted Computer System Evaluation Criteria
          (ITCSEC) available in postscript at
          <http://www.radium.ncsc.mil/tpep/library/tcsec/ITCSEC.ps>
          contains the definitive set of requirements for each TCSEC
          class.  In Summary:

            Class D: Minimal Protection

          Class D is reserved for those systems that have been evaluated
          but that fail to meet the requirements for a higher evaluation
          class.

            Class C1: Discretionary Security Protection

          The Trusted Computing Base (TCB) of a class C1 system
          nominally satisfies the discretionary security requirements by
          providing separation of users and data.  It incorporates some
          form of credible controls capable of enforcing access
          limitations on an individual basis, i.e., ostensibly suitable
          for allowing users to be able to protect project or private
          information and to keep other users from accidentally reading
          or destroying their data.  The class C1 environment is
          expected to be one of cooperating users processing data at the
          same level of sensitivity.

            Class C2: Controlled Access Protection

          Systems in this class enforce a more finely grained
          discretionary access control than C1 systems, making users
          individually accountable for their actions through login
          procedures, auditing of security-relevant events, and resource
          isolation.

            Class B1: Labeled Security Protection

          Class B1 systems require all the features required for class
          C2.  In addition, an informal statement of the security policy
          model, data labeling (e.g., secret or proprietary), and
          mandatory access control over named subjects and objects must
          be present.  The capability must exist for accurately labeling
          exported information.

            Class B2: Structured Protection

          In class B2 systems, the TCB is based on a clearly defined and
          documented formal security policy model that requires the
          discretionary and mandatory access control enforcement found
          in class B1 systems be extended to all subjects and objects in
          the automated data processing system.  In addition, covert
          channels are addressed.  The TCB must be carefully structured
          into protection-critical and non- protection-critical
          elements.  The TCB interface is well-defined and the TCB
          design and implementation enable it to be subjected to more
          thorough testing and more complete review.  Authentication
          mechanisms are strengthened, trusted facility management is
          provided in the form of support for system administrator and
          operator functions, and stringent configuration management
          controls are imposed.  The system is relatively resistant to
          penetration.

            Class B3: Security Domains

          The class B3 TCB must satisfy the reference monitor
          requirements that it mediate all accesses of subjects to
          objects, be tamperproof, and be small enough to be subjected
          to analysis and tests.  To this end, the TCB is structured to
          exclude code not essential to security policy enforcement,
          with significant system engineering during TCB design and
          implementation directed toward minimizing its complexity.  A
          security administrator is supported, audit mechanisms are
          expanded to signal security-relevant events, and system
          recovery procedures are required.  The system is highly
          resistant to penetration.

            Class A1: Verified Design

          Systems in class A1 are functionally equivalent to those in
          class B3 in that no additional architectural features or
          policy requirements are added.  The distinguishing feature of
          systems in this class is the analysis derived from formal
          design specification and verification techniques and the
          resulting high degree of assurance that the TCB is correctly
          implemented.  This assurance is developmental in nature,
          starting with a formal model of the security policy and a
          formal top-level specification (FTLS) of the design.  An FTLS
          is a top level specification of the system written in a
          formal mathematical language to allow theorems (showing the
          coorespondence of the system specification to its formal
          requirements) to be hypothesized and formally proven.  In
          keeping with the extensive design and development analysis of
          the TCB required of systems in class A1, more stringent
          configuration management is required and procedures are
          established for securely distributing the system to sites.  A
          system security administrator is supported.

----------

Subject: Section IV: Evaluations

  1. How do I get my product evaluated?

          Product developers who have a product that they wish to have
          evaluated need to request a proposal package from:

              V24, TRUSTED PRODUCT EVALUATION PROGRAM
              NATIONAL SECURITY AGENCY
              9800 SAVAGE ROAD STE 6740
              FT MEADE MD 20755-6740

          The ultimate proposal for product evaluation will include
          technical and marketing details for the product.  Because the
          Trusted Product Evaluation Program (TPEP) is legislatively
          prohibited from directly evaluating products that are not
          intended to protect classified information, the proposal
          marketing information should include details about the market
          potential within the United States Department of Defense and
          intelligence communities.  Additionally, the TPEP in general
          does not accept products targeting the C1 and below evaluation
          classes, as these are usually inappropriate for processing any
          classified information.  TPEP currently accepts for evaluation
          at the C2 and higher levels, networked systems which meet the
          market and technical criteria.  The product technical details
          will include descriptions of the product's documentation and how
          that documentation's structure compares to that required by the
          PGWG documents (see Section II, Question 11).  Finally, the
          proposed configuration of the product should be a configuration
          likely to be used by the described potential market.

  2. What is the evaluation process?

          The evaluation process is described in detail at
          <http://www.radium.ncsc.mil/tpep/process/procedures.html> In
          general terms, a successful evaluation proceeds through the
          following stages:

            Proposal Review

          A product proposal, submitted by a vendor for consideration of
          evaluation by TPEP is reviewed for two purposes.  The first is
          to determine the potential market benefits of accepting the
          product for evaluation (i.e., the DoD customer base).  The
          market analysis is performed based upon both the vendor's proposal
          and upon TPEP customer input, which is actively solicited on a
          regular basis.  The second part of the proposal review is to
          determine, at a very preliminary level, if the product appears
          to provide feasible security mechanisms such that the requirements
          of the TCSEC can be satisfied.  Once the review of the product
          proposal is completed, the vendor is notified in writing of the
          acceptance or rejection of the product for evaluation.

            Technical Assessment

          Products whose proposals were recommended as "accept" are
          considered candidates for evaluation and proceed to the next
          step in pre-evaluation, the Technical Assessment (TA), where
          a vendor must demonstrate that the product design and the
          associated evaluation evidence are complete.  A TA is often
          the first examination of the product and the evidence by a
          technical evaluation team.  Vendors may have excellent and
          complete documentation, indicating a readiness to undergo an
          Intensive Preliminary Technical Review (IPTR) which is the
          gateway to evaluation when successfully completed.  Advice may
          be recommended based on readiness.

            Advice

          The purpose of advice is to aid the vendor in producing a product
          and supporting documentation that is capable of being evaluated
          against the TCSEC and its interpretations.  Advice can be provided
          by contractors outside of TPEP or TPEP evaluators may be assigned
          to advise the vendor.  TPEP-provided advice begins after a vendor
          has submitted a proposal and a technical assessment has been
          performed that deemed the product suitable for evaluation, but
          not yet ready for an IPTR.

            Intensive Preliminary Technical Review (IPTR)

          The IPTR is an independent assessment by the TPEP evaluators to
          determine a product's readiness for evaluation.  An IPTR lasts
          for approximately 7-10 days and is performed by a team of
          approximately 5 TPEP evaluators.  During the IPTR, which is
          usually held at the vendor's site, the team becomes familiar with
          the product (through vendor presentations); reviews documentation,
          test plans, and procedures; and documents its findings in a report.
          The IPTR report is provided to the vendor and TPEP management and
          documents the team's assessment of the product's readiness for
          evaluation.  Completion of a successful IPTR results in the
          product moving into evaluation (pending availability of TPEP
          evaluation resources).

            Evaluation

          Evaluation is the comprehensive technical analysis of a product's
          security functionality.  At the beginning of evaluation, the
          vendor provides the evaluation team with system level, developer-
          oriented training for the product.  Training is followed by
          analysis of the product design, focusing specifically on security
          features.  This analysis includes both hardware and software
          components of the product and associated documentation.  Testing
          of the product involves running the vendor's test suite, as well
          as tests formulated by the evaluation team.  Upon successful
          completion of testing and rigorous technical reviews by senior
          members of the evaluation community, the product is awarded an
          Evaluated Products List (EPL) entry.

            Rating Maintenance Phase (RAMP)

          RAMP provides a mechanism for a vendor to maintain the TCSEC
          rating of a product throughout its life cycle.  During RAMP,
          the vendor works with the TPEP assigned Technical Point of
          Contact (TPOC) to analyze the security impact of proposed changes
          to the evaluated product.  The Vendor Security Analyst (VSA)
          actually performs the security analysis of the product changes
          as they occur.  The changes and associated analysis results are
          presented to a TPEP Technical Review Board (TRB) which recommends
          approval (or disapproval) of the rating for the "new" product.

  3. How long does an evaluation take?

          The length of time a developer needs to prepare for an
          Intensive Preliminary Technical Review (IPTR) varies
          considerably.  The IPTR is a short (one to two week) assessment
          of the state of the product documentation and testing.  A
          successfull IPTR ensures that the materials needed for
          evaluation are complete and usable.  Currently, we expect
          successful evaluations at the C2/B1 class to take approximately
          one year to complete from successful IPTR to final technical
          review.  IPTRs should ideally take place approximately eight
          months before product release for a typical C2/B1 product, and
          even earlier in the product cycle for products targeted at B2,
          B3 or A1.  We continue to explore ways to reduce the time
          required.  Higher class evaluations take longer, although this
          is somewhat mitigated by the fact that the TPEP is usually
          involved earlier in the design process for systems at
          relatively higher classes.  Problems during evaluation, changes
          in the configuration the vendor is planning to market, and
          system complexity can all add to the length of evaluation.
          Vendors participating in the RAMP (Rating Maintenance) process
          can perform analysis of changes to an already evaluated system
          to maintain the evaluated rating on subsequent versions and
          configurations.  The length of time to obtain a RAMP rating is
          largely dependent on the vendor and on the nature and
          complexity of the change.  However, it is reasonable to expect
          this RAMP to take far less time than an evaluation.

  4. How much does an evaluation cost?

          The Trusted Product Evaluation Program (TPEP) does not charge
          for evaluations.  It may be a significant expense for a product
          developer to prepare for and support evaluation.  There are
          often travel expenses for staff, training costs for the
          evaluation team, and the cost of having development personnel
          take time to respond to the evaluation team's questions.  In
          addition, if the product did not previously meet the
          requirements for a given class, the cost of improving the
          product (i.e., doing the testing, analysis and documentation)
          can be high.  Ultimately, this should result in an improved
          product that will be recognized as superior to competitors.

  5. How do I find out about the evaluation process?

          For an abstract view of the evaluation process you can read
          this list of Frequently Answered Questions (FAQ)!  For a more
          detailed view appropriate to those who wish to participate in
          the process, the process is described in some detail at
          <http://www.radium.ncsc.mil/tpep/process/procedures.html>.

  6. Who actually performs the evaluations?

          Trusted product evaluators come from the Trusted Product
          Evaluation Program (TPEP) organization within the National
          Security Agency (NSA) as well as from a small group of federal
          contract research organizations.  Some evaluations have also
          benefitted from the participation of evaluators from the
          security evaluation organizations of other cooperating
          governments.  In cooperation with the National Institute of
          Standards and Technology (NIST), a program is being developed to
          evaluate products in the lower Trusted Computer System
          Evaluation Criteria (TCSEC) classes (i.e., C2/B1) using
          approved commercial evaluation facilities.  However, many
          details remain to be finalized for that program.

  7. What information is released about an evaluated product?

          As we begin working with a product, the vendor and target
          rating are made available.  When that product is accepted into
          evaluation, information such as the vendor, target rating, and
          target completion date are announced in a product announcement
          on the Evaluated Products List (EPL) (see Section V, Question
          6).  When the evaluation is completed the general evaluated
          product configuration, general product information, and rating
          are announced in an entry on the EPL.  In addition at the
          completion of evaluation a report is published (see Section V,
          Question 7).  This report contains the analysis of the
          evaluation team, a complete description of the evaluated
          product, and often comments about the usability of the product
          in its evaluated configuration by the evaluation team.  Recent
          EPL entries and a few Final Evaluation Reports are available at
          <http://www.radium.ncsc.mil/tpep/epl/>.


  8. What is RAMP?

          The Rating Maintenance Phase (RAMP) Program was established to
          provide a mechanism to extend the previous rating to a new
          version of a previously evaluated computer system product.
          RAMP seeks to reduce evaluation time and effort required to
          maintain a rating by using the personnel involved in the
          maintenance of the product to manage the change process and
          perform Security Analysis.  Thus, the burden of proof for RAMP
          efforts lies with those responsible for system maintenance
          (i.e., the vendor) instead of with an evaluation team.

----------

Subject: Section V: Evaluated Products

  1. Should I buy an evaluated product?

          An evaluated product has the benefit of providing an
          independent assessment that the product meets the criteria for
          the rating it achieved.  When considering a specific
          installation the value of the data and the threat to that data
          both need to be considered.  These are often related, in that
          more valuable data has a higher threat.  If some of the threats
          to the data can be countered by the features or assurance of a
          trusted product, then it is certainly worthwhile to consider
          that in your purchase decision.  All other things being equal
          (which is rarely the case) the independent assessment of an
          evaluated product adds value.

  2. Does NSA buy/use evaluated products?

          NSA endevours to be an exemplary customer of the products it
          recommends for use by its customers and expects NSA-evaluated
          products to comprise the foundation of its own secure information
          systems architecture and is developing policy towards that end.

  3. How do I know if a product is evaluated?

          The simplest way to find out if a product is not evaluated is
          to ask the product vendor.  If the vendor has an evaluated
          product, it is a pretty good bet that the company marketing
          people are aware of it.  Many products that have NOT been
          evaluated have names containing a rating or have declared
          themselves as "designed to meet" a specific rating.  These products
          have not withstood the same scrutiny as products listed on the EPL.

          If a vendor claims to have an evaluated product, you should
          independently verify the details of the evaluation (e.g.,
          product version, configuration, rating.) All evaluated products
          are placed on the Evaluated Products List (EPL) (see Section V,
          Question 6).  That is the first place to look.  The EPL entries
          that have been awarded within the last three years are available
          at <http://www.radium.ncsc.mil/tpep/epl/>.  To verify a specific
          detail (e.g., the rating) of an evaluation, you may call the Trusted
          Product Evaluation Program (TPEP) directly at (410) 859-4458 This
          will often result in less complete information since generally we
          don't read entire EPL entries over the phone.

          For the most complete information about a specific evaluated
          product, you should request a copy of the evaluation report.
          (see Section V, Question 7)  Unfortunately, the publication of
          the report sometimes postdates the evaluation significantly.
          An increasing number of final evaluation reports are available
          via links from the product's electronic EPL entry or from
          <http://www.radium.ncsc.mil/tpep/library/fers/> by report number.

  4. What does it mean for a product to be "in evaluation"?

          In the past it has been the case that Trusted Product
          Evaluation Program (TPEP) evaluations where conducted over
          longer periods of time and included time for a developer to
          work out problems with their documentation and testing that a
          current Intensive Preliminary Architecture Review (IPTR) is
          designed to limit.  Currently a product is not announced to be
          in evaluation until it has successfully passed an IPTR.  Even
          so, a product may go through several releases, incorporate
          fixes during the course of evaluation, or even potentially drop
          out of evaluation or fail evaluation.  Because of this a
          product in evaluation is not equivalent to an evaluated
          product.  While it does show some intent to have an evaluated
          product, and a consideration of security criteria in the
          product development, it does not necessarily imply any security
          features or assurances.  Buyers of products in evaluation
          should consider what options will be available to them should
          the evaluated configuration differ significantly from the
          purchased configuration, or if the product does not ultimately
          complete evaluation.
          
  5. What does it mean for a product to be "compliant" with the TCSEC?

          If a product has been evaluated by the Trusted Product
          Evaluation Program (TPEP) to comply with the requirements of a
          rated class, then it means that an independent assessment
          showed the product to have the features and assurances of that
          class.  It does not mean that the product is impenetrable.  It
          is even possible that the independent assessment overlooked
          some failure to meet the criteria, although we expend a lot of
          energy attempting to prevent that.  A vendor claim to be
          "compliant" without an evaluation often doesn't mean very much
          since the vendor's interpretation of the requirement may not be
          the same as an independent assessor's would be.

  6. What and where is the Evaluated Products List (EPL)?

          The Evaluated Products List (EPL) officially is published
          quarterly in the INFOSEC Products and Services Catalog (as a
          chapter).  The INFOSEC Products and Services Catalog is
          available from the Government Printing Office.  The EPL is also
          maintained electronically on Dockmaster and updated as new
          products are announced. (see Section I, Question 7) There is no
          anonymous access to Dockmaster so this is available only to
          Dockmaster users.  EPL entries issued within the last three years
          are available at <http://www.radium.ncsc.mil/tpep/epl/>.

  7. How do I get a copy of an evaluation report?

          Single copies of evaluation reports are available without charge
          by writing:
          
              INFOSEC AWARENESS, ATTN: Y13/IAOC
              DEPARTMENT OF DEFENSE
              9800 SAVAGE ROAD
              FT MEADE MD 20755-6000
          
          Multiple copies are available from the Government Printing
          Office.  In either case you will need the report number
          (CSC-EPL-xx/xxx or CSC-FER-xx/xxx) which is given in the
          Evaluated Products List (EPL) entry for the product. (see
          Section V, Question 6)
          
  8. Is an evaluated product "hacker proof?"
  
          No product can be guaranteed to be "hacker proof" or
          "impenetrable."  An evaluated product has demonstrated certain
          features and assurances, as specified by the rating criteria.
          Those features and assurances counter certain threats.  Thus an
          evaluated product is usually vulnerable to fewer threats than
          an unevaluated product.  Products with higher ratings are
          vulnerable to fewer threats than products with low ratings.
          Vulnerabilities to threats that remain in products can often be
          addressed through other means.  No rating class used by the
          Trusted Product Evaluation Program (TPEP), for example,
          counters the threat of directly tampering with the hardware.
          That threat would need to be addressed physically or
          procedurally if it was realistic for the particular system
          environment.

          Finally, it seems many "hackers" today prefer to use "social
          engineering" to accomplish their goals.  As with other
          insider-related threats, education is necessary in preventing
          naive users from disclosing sensitive information.  However,
          technical measures can also help.  They can enforce the the
          principle of least privilege, check the reasonableness of
          administrative inputs, and provide timely on-line cautions.

  9. What is the rating of DOS?

          MS-DOS, PC-DOS, and DR-DOS have not been evaluated.  Without
          modification, it is apparent from the most cursory examination
          that they do not implement many of the features required by the
          C1 class of the Trusted Computer System Evaluation Criteria
          (TCSEC).  Several vendors support a DOS application interface
          in products designed to achieve higher class ratings.

 10. What is the rating of UNIX?

          There are a number of evaluated products conforming to one or
          another of the UNIX interface standards (see Section V,
          Question 3).  These products range from class C2 to class B3.
          In general, unevaluated UNIX products lack several features,
          including sufficient auditing, to achieve anything other than a
          D class rating without some modification.

 11. What should I do if evaluated Product X appears to fail a requirement?

          If an evaluated product does not seem to meet the requirements,
          the first thing to do is carefully look at the Final Evaluation
          Report (FER) and the product's Trusted Facility Manual (TFM).
          The product was evaluated with specific configuration options and
          on specific hardware.  These should be stated in the TFM and FER
          respectively.  If the evaluated configuration still seems to not
          meet some requirement for its rated class, then it is possible that
          there was an oversight during the evaluation.  You can send that
          information to tpep@dockmaster.ncsc.mil and we may investigate the
          issue.

 12. Why should I buy a B2/B3/A1 product over a C2/B1 product?

          While the features and assurances of each class increase, the
          increase is not linear.  B1 and below rated products provide a
          basic set of security features and an independent assesment that
          those features are implemented correctly.  At B2 and above there
          is significantly more effort and analysis both in development and
          in evaluation that the features are correctly implemented.  The
          additional development effort often translates into increased cost
          for the product.  For applications involving sensitive data, the
          added cost may be well worth the added protection.  

 13. Is there an approved program to declassify my hard drive?
 
          In summary, no; in general, overwriting may be sufficient to have
          media released for other use, but it must retain its original
          classification.

          You should contact your security officer or contracts manager for
          official guidance.  Often, your contract will determine how to
          declassify disks.  This is usually indirect, by referencing a
          DOD-STD or other document.  Be prepared to submit the disk drive
          (or at least the little metal thingy with the iron oxide) for total
          destruction.

          If you need to retrieve unclassified data that reside on a
          classified disk, there are often detailed procedures to accomplish
          this.


User Contributions:

Comment about this article, ask questions, or add new information about this topic:

CAPTCHA


[ Usenet FAQs | Web FAQs | Documents | RFC Index ]

Send corrections/additions to the FAQ Maintainer:
TPEP@dockmaster.ncsc.mil





Last Update March 27 2014 @ 02:11 PM