Peanuts NeXT Software Archives

home *** CD-ROM | disk | FTP | other *** search

/ Peanuts NeXT Software Archives / Peanuts-1.iso / CDROM / FAQs / Security / evaluations < prev next >

Wrap

Internet Message Format | 1996-10-17 | 61.0 KB

Path: informatik.tu-muenchen.de!lrz-muenchen.de!uni-erlangen.de!cs.tu-berlin.de!newscaster-1.mcast.net!news.mathworks.com!bloom-beacon.mit.edu!senator-bedfellow.mit.edu!faqserv From: Trusted Product Evaluation Program <TPEP@dockmaster.ncsc.mil> Newsgroups: comp.security.misc,comp.security.unix,comp.answers,news.answers Subject: Computer Security Evaluation FAQ, Version 2.1 Supersedes: <computer-security/evaluations_842859583@rtfm.mit.edu> Followup-To: poster Date: 16 Oct 1996 16:38:11 GMT Organization: Trusted Product Evaluation Program Lines: 1148 Approved: news-answers-request@MIT.EDU Expires: 29 Nov 1996 16:25:18 GMT Message-ID: <computer-security/evaluations_845483118@rtfm.mit.edu> Reply-To: TPEP@dockmaster.ncsc.mil NNTP-Posting-Host: bloom-picayune.mit.edu X-Last-Updated: 1996/08/13 Originator: faqserv@bloom-picayune.MIT.EDU Xref: informatik.tu-muenchen.de comp.security.misc:34243 comp.security.unix:33232 comp.answers:21736 news.answers:84323 Posting-Frequency: monthly Archive-name: computer-security/evaluations 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.