Los Angeles ACM Chapter Meeting

Wednesday, October 4, 2000

The Common Criteria: A New Approach to Security Evaluation

By Daniel Faigin, The Aerospace Corporation

Since 1983, the Trusted Computer System Evaluation Criteria, also called the Orange Book, has been the standard for Computer Security evaluation in the United States. This standard has been replaced by the new Common Criteria for Information Technology Security Evaluation, usually just called the Common Criteria or CC. The contrast between the two is as broad as the behavior of IBM in the 1960s vs. today. The CC now provides the ability to flexibly specify the computer security requirements for a generic product class or a specific product; the CC infrastructure provides the ability to evaluate the product in a manner that will have international recognition. This talk will provide an overview of the CC: how it is structured, and how it is used. It will also provide some examples of how the CC approach can provide benefits even without formal evaluation. Lastly, it will discuss how the evaluation process has had a paradigm shift corresponding to the evaluation criteria paradigm shift.

Daniel Faigin has been working in the Computer Security field since 1985, when he joined SDC. At SDC, he was involved with the design of BLACKER (an A1 Multilevel Secure Network--what would now be called a VPN) and Trusted Databases. In 1988, Daniel moved to The Aerospace Corporation, where he became involved with computer security evaluations. He has been involved with evaluations at all ratings in the Orange Book, and has been involved in the writing of the Common Criteria. He is currently involved with providing senior level oversight to the evaluation process, primarily through his involvement with the Interpretations Working Group, a body originally charged with interpreting the Orange Book, and now charged with providing US-level interpretations of the Common Criteria. \par Daniel is a past chair of the Los Angeles Chapter of the ACM and of the ACM SIG on Security Audit and Control (SIGSAC). He is presently treasurer of ACM/SIGSAC. He is a senior fellow of the Applied Computer Security Associates, and is Tutorial Chair for the Annual Computer Security Applications Conference (www.acsac.org, December 11-15, New Orleans). He also organized and coordinated the recent Workshop on Innovations in Strong Access Control (Sept. 25-27, Monterey) sponsored by The Aerospace Corporation and the Naval Postgraduate School.

LA ACM Chapter October Meeting.
Held Wednesday October 4, 2000.

Dan described the new security common criteria model. The criteria provide a comparable standard where evaluations are consistent and repeatable and provide consumers with a known quantity for the comparisons. Previous criteria in commercial environments were often "ad hoc". Governments provided some earlier examples of formalized criteria with the US Trusted Computer System (TSEC) "Orange Book" developed back in 1985. Other countries developed their own criteria and there was a US draft Federal Criteria for IT Security published in 1993. There were a number of problems with the previous criteria. They had fixed groupings where it was difficult to separate functions from assurance and to tailor functions to products. The criteria were country specific and the US could not take advantage of other countries evaluations. Evaluations were costly and it was difficult to get current products evaluated. There was no incentive for timely processing.

The solution was to develop common criteria designed to meet the needs of multiple nations and using multinational development teams. The cooperating countries are the United States, Canada, Great Britain, France, Germany and the Netherlands. The Common Criteria(CC) focuses on flexibility but is based on previous criteria. The previous TSEC provided a fixed bundling of features and assurance with features selected based on DOD policy and needs. Requirements were fixed and applicable to everything so that changes also applied globally. In contrast, the Common Criteria use a sponsor-selected bundle of features and assurance and changes in requirements apply only to the specified criteria for a specific product. The Common Criteria in itself is not a requirements document. Each country determines its own evaluation scheme and the CC provides for cross-country acceptance of evaluation results. It provides requirements for evaluation facilities and certifying bodies.

The CC provides a model of how to express security requirements, a catalog of functional and assurance requirements and an evaluation methodology toe ensure that labs in different countries produce consistent results. Requirements are selected to meet specific security objectives that are based on threats, organization policies, and assumptions. Requirements are expressed in Protection Profiles(PPs) and Security Targets(STs). Protection Profiles provide generic requirements for a class of products and specify an environment of use. The goal is to address a common consumer need. CC requirements may be general and describe specific operations that can be filled in with details for the particular need. A Security Target is similar in structure to a Protection Profile but differs in that all operations must be completed and there is a specification that must be met. Security Targets are specific to a product or system and specify the claimed features and required assurance for it. The CC requires documentation of security environments, objectives and requirements. Documentation includes mappings to show that threats and requirements are matched. Protection Profiles are evaluated by a laboratory paid for by its sponsor and the results maintained in a multi-country registry. STs are developed against a PP and to be in compliance must have all of the PP requirements and objectives incorporated.

Dan presented a detailed description of the classes, families, components, and elements of the CC and described the Evaluation Assurance Levels that range from EAL1 to EAL7 with each larger number indicating a higher level of assurance. EAL1 will detect obvious errors at minimum cost, but is not likely to find deliberate subversion. It is used where the risk is not serious. EAL2 uses additional developer effort to provide low to moderate assurance. It is particularly useful for evaluating legacy systems. EAL3 provides a moderate level of assurance by accomplishing a thorough investigation of the product and its development without substantial alteration of the development environment. EAL4 methodically covers the design and test process and requires rigorous development practices. It is the highest level likely to be used for retrofit of an existing product and requires some additional engineering cost. EAL5 is semiformally designed and tested to provide high assurance and evaluate risk situations in a rigorous commercial development environment. It will use a moderate level of specialist engineering techniques but should incur no unreasonable development costs. EAL6 covers high value assets used in risk situations and applies security-engineering techniques at additional development cost. EAL7 is the highest assurance level and uses a formally verified design. It provides the maximum assurance for high value assets used in high-risk situations and is subjected to formal analysis. It has higher development and environmental costs.

The Common Evaluation Methodology (CEM) describes how assurance is assessed in order to insure the consistency of application and results. The schemes may have specific national requirements for particular nations. Dan described a large number of assurance classes and presented charts showing how the assurance classes mapped to the EALs. He described Protection Profiles and said that each country maintains a registry of them. They describe controlled access, labeled security protection, network firewalls, operating system protection and numerous other classes. There are commercial classes relating to payment guarantee systems, cash dispensers and accounting systems. Dan was asked: "How well are they working?". He responded that the system is new, but that now the organizations are trying to do things right and progress has been made.

Dan's presentation presented much more detail than is provided in this report and there is much more information available that could not be presented at one meeting. For more information go to:

http://www.commoncriteria.org
http://niap.nist.gov
http://www.iatf.net

You may contact Daniel Faigin at: faigin@pacificnet.net

This was second meeting of the LA Chapter year and was attended by about 22 persons. Dan's talk was excellent and there were a number of security experts in the audience for this very pertinent talk. Dan did a great job of making an explanation of security practices not only informative, but also interesting.

Mike Walsh, LA ACM Membership Chair