INFORMATION TECHNOLOGY SECURITY WORKSHOP PROCEEDINGS

FEDERAL CRITERIA FOR INFORMATION TECHNOLOGY SECURITY WORKSHOP PROCEEDINGS

NIST NSA United States Department of Commerce Department of Defense National Institute of Standards and Technology National Security Agency

Turf Valley Hotel and Country Club Ellicott City, Maryland June 2-3. 1993

Issue 1.0

July 30 1993

CHAPTER 1 Introduction

The first draft of the Federal Criteria was made public in January 1993. Several thou-sand copies of the Federal Criteria were distributed and comments on this first draft were received between January and April of 1993. Over 20,000 comments were obtained from approximately 120 organizations. These organizations represented defense and civil government, producer and procurer, and North American and Euro-pean concerns. The purpose of the Federal Criteria Workshop that was sponsored by the National Security Agency (NSA) and the National Institute of Standards and Technology (NIST) on June 2nd and 3rd of 1993 was to address these comments. All those who commented on the first draft were invited to attend. The workshop consisted of approximately 128 participants.

In the opening remarks by Stuart Katzke of NIST and Robert Scalzi of the NSA, the participants were informed of NIST's and NSA's decision to work with the Canadians and Europeans in creating a Common Criteria (see Chapter 12). The members of the Common Criteria Editorial Board (CCEB) are Gene Troy (NIST), Mario Tinto (NSA) Yvon Klein (France), Chris Ketley (United Kingdom), Hartwig Kreutz (Germany), and Paul Cormier (Canada). The plans for the CCEB call for aligning the various criteria (Trusted Product Evaluation Criteria (TCSEC), draft Federal Criteria, the Information Technology Security Evaluation Criteria (ITSEC), and the Canadian Trusted Computer Product Evaluation Criteria (CTCPEC)) from the participating countries. All the CCEB members attended the workshop and were available for any questions that the other participants may have had.

The workshop focused on specific problems that were identified in the comments but did not focus on a line-by-line review of the text. First, global issues that transcended the various areas were identified in a plenary session. Then, the global issues, as well as issues from each of the separate areas (functional requirements, protection profiles, protection profile creation, development assurance, evaluation assurance, CS protection profiles, LP protection profiles, and issues on international harmonization), were discussed in separate breakout sessions.

The purpose of this proceeding is to inform the Federal Criteria commentators and the workshop attendees of the outcome of the workshop. Also, this proceeding will be used as a blueprint for updating the Federal Criteria. This proceeding, and the revised portions of the draft Federal Criteria contents, will be the two principal NIST/NSA inputs to the CCEB. Priliminary plans for dealing with the Federal Criteria comments are included in this document, and all revisions will be performed under the direction of NIST and the NSA.

The plans for revising portions of the draft Federal Criteria are still being determined. Note, however, that all the topics listed in the Executive Summary in the next section are considered to be important and will be input to the CCEB. After specific plans for the revision are finalized, these plans will be made available to all those who commented on and attended the workshop for the draft Federal Criteria.

The next section of this proceeding gives the Executive Summary. This is followed by the moderator reports for each of the individual breakout sessions. Then the plan for future work on the Federal Criteria, which is a direct outcome of the comments and the workshop, is described. The appendix gives the text of the public announcement on the Common Criteria effort.

CHAPTER 2 Executive Summary

The one issue that dominated the vast majority of the comments and workshop partici-pants was the need for the next criteria to address distributed systems, networks, encryp-tion, and PC security. These areas were discussed extensively in the workshop but were not specifically addressed since there was no text in the present draft of the Federal Criteria to discuss, and since a working group had already been established to look at these issues. However, there was clearly a mandate from the commentators and from the participants that the document is severely deficient without these requirements and that any future criteria would not be fully useful unless these issues were addressed.

Also, the majority of the participants felt that there were several elements of the Federal Criteria that should be retained in the progression to the Common Criteria, especially the notion of a protection profile. The participants liked the idea of creating protection profiles by assembling them from pre-defined components. However, the participants also felt that the make-up of the components themselves should be revisited. They felt that the ordering and the grouping of component requirements should be re-examined, and that the interdependencies among the various components and of particular require-ments in a single component should be made more clear.

The participants also felt that there was a problem with TCSEC compatibility. One of the main goals of the Federal Criteria work was the incorporation of the TCSEC requirements. This was not only in recognition of TCSEC technology but also for back-wards compatibility for those products that were created against the TCSEC. The measure of this incorporation was the creation of protection profiles that reflected the TCSEC classes (with CS1 addressing the TCSEC's C2 class, and LP1, 2, 3, and 4 addressing B1, B2, B3, and A1, respectively). However, the participants felt that this goal was not met. They felt that neither the draft Federal Criteria nor the LP protection profiles that were created properly represent the TCSEC classes. They felt that the LP protection profiles and the components used to create them should be rewritten.

The commentators and participants also felt that there was a need for the Federal Criteria to go beyond the scope of stand-alone products. They also felt that the relation-ship of protection profiles to security targets was not made clear. Although not specifi-cally addressed in the Federal Criteria, many commentators and participants also took the opportunity to express their concerns about the present evaluation process and the issue of mutual recognition of international evaluations and certificates, especially in light of the Common Criteria effort. There were also concerns expressed on how protec-tion profiles should be standardized, registered, and vetted, and on the international vetting of protection profiles.

CHAPTER 3 Global Issues

Overview

As reflected in the comments, there were several global issues that transcended discus-sion in a single area. The global issues session was created to reflect these comments. Four global issues were identified: Federal Criteria benefits, the concept of Protection Profile, the concept of components, and products vs. systems. All of these topics were introduced in a plenary session, and then discussed individually in break out sessions for the rest of the morning. Then, these (and other topics) were discussed in a global issue session that continued through the afternoon. It should be noted that different concerns were expressed in the morning and afternoon groups, and that for one of the global issues there was a divergence of opinion. Where this divergence occurred will be indi-cated in the following text.

Each of these areas are discussed below. Note that no differentiation is made between what the morning and afternoon groups discussed except in the area where there was a divergence of views.

It should also be noted that there were several global issues in the comments that were not addressed in this session even though most reviewers expressed concern about these areas. These are: networks, distributed systems, low end PC security, and encryption. There was an agreement that these issues not be discussed during the workshop since there was no intent to address these areas in this particular draft and since there was no text in the Federal Criteria on which to base this discussion. However, these issues were brought up in the plenary question and answer session and many in the audience expressed the opinion that these areas should be addressed.

Federal Criteria Benefits

This session focused on a variety of subjects and these topics will be important as we move to the Common Criteria. It also focused on several flaws of the Federal Criteria, and these will also be reflected in this report.

In general, the group agreed that the following were Federal Criteria benefits:

	· The unbundling of functional requirements from each other and from assurances.
	· The creation of protection profiles by assembling pre-defined components and elabo-rating them to specific product targets.
	· The explicit separation of documentation, process, and evaluation assurance.
	· Recognition of Ease of Use, Physical Protection, and Flaw Remediation (this was thought to be especially important to retain) as requirements.

There was a lot of discussion on the notion of a protection profile. The consensus among both groups was that we need the notion of a protection profile, and that protection profiles describe what a consumer wants and what a vendor should build towards. Protection profiles go hand in hand with risk analysis. They were felt to be a useful consumer's tool to spell out requirements. Protection profiles provide the basis for market driven requirements, ease flexibility in presenting requirements, and improve the credibility of the ITSEC's notion of "effectiveness." [The ITSEC defines "effective-ness" in security evaluations as being an aspect of assurance that assesses how well the applied security functions and mechanisms working together to actually satisfy the security requirements.] Documenting the environmental assumptions in protection profiles were felt to be a beneficial feature.

However, several concerns were expressed about protection profiles. One of the ques-tions asked was, What is the value of a protection profile as an evaluation entity? It was felt that consumer needs do not have to be evaluated, but that the notion of how the product satisfies those needs do. It was felt that the definition/purpose of what is a protection profile is not clear in the Federal Criteria. The group came to the conclusion that protection profiles are a "what" definition, i.e., that protection profiles state what the functional and assurance requirements are, and a security target is a "what" and "how" definition, i.e., that security targets state what the requirements are and how they are being met for a particular product. The group also felt that in some cases products should be able to be developed without a protection profile when, for example, a unique product is being built, or when a generalized statement of requirements is not needed.

The group also expressed the opinion that protection profiles facilitate governments and other agencies in getting their security requirements in front of vendors. To be useful, protection profile creation needs to be market driven. The user groups that will have an interest in creating profiles include not only end-user groups, but integration contractors and value-added resellers as well. Vendor market-research groups may also be in a good position to know both what is needed and what is feasible. Thus, even though profiles are designed to express user needs, vendors may also become actively involved. If similar security targets continue to be produced and used, someone will realize the value of extracting a common protection profile from them. It was felt that in the long run, security targets will be a source of protection profiles.

The global issues group felt that the creation of protection profiles may be too hard for consumers to vet even though consumers have needs that don't map to the TCSEC. The group felt that protection profiles are really application profiles for various commercial industries, e.g., financial, telecommunications, etc., but did not feel that the market will create these protection profiles without some government intervention. The group felt that it was unrealistic to assume that consumers will "get together" to create protection profiles, and they felt that the government (e.g., NIST, Information System Security Association (ISSA)) should take a leading role in sponsoring the creation of protection profiles, and should assemble people from these various industries for the purpose of putting these profiles together.

There were also many concerns with how many protection profiles there was going to be and what mechanisms or controls would be in place to limit the number of protection profiles. The global issues group felt that the proliferation of protection profiles may be self constraining because of the number of resources that are needed to create the protection profile. Several participants expressed concern that too many profiles will produce market fragmentation, thereby undermining a primary motivation for distin-guishing between profiles and security targets in the first place. The protection profile group expressed much pessimism on actually accomplishing control. The problem of controlling the proliferation is related to the question of who will produce profiles: if their creation is privately funded, they may be registered only with their funding organi-zation. It was felt that vendors will probably aggregate profiles to cover more than one market and that products may be designed to simultaneously satisfy several different profiles. This already happens for products that are simultaneously evaluated against the C2 and B1 TCSEC classes. Because of this, it may be appropriate to consider profile composability so that vendors, evaluators, and consumers can better appreciate the implications of such products.

The protection profile group also felt that acceptance vetting could be performed in a decentralized or local mode. That is, there could be local registries of protection profiles, and also a centralized registry of profiles that can be used to coordinate consis-tency or to allow a vendor to gain information on the "largest common intersection of protection profiles."

The International Standards Organization (ISO) was discussed as a possible answer to the registration of protection profiles. Unfortunately, ISO has a reputation for being slow and unoriginal. This implies that for profile registration to be effective, other stan-dards bodies must be involved. The NIST FIPS publications could provide a more timely U.S. mechanism for registering profiles, at the expense of not being international. Registration issues differ for government and nongovernment profiles: national profiles presenting government security needs make more sense than national profiles presenting the security needs of a multinational industry or consumer group. The primary purpose of protection profile registries should be to create a sensible market-place for security ideas and products, as opposed to enforcing control over this market. Also, as past evaluations against the TCSEC classes have shown, the TCSEC require-ments change continuously under interpretation by evaluators. Consequently, a regis-tered profile needs to include points of contact that can explain the needs of the user group that produced the profile, in order to facilitate useful profile interpretation. Simi-larly, the profile registry needs to include, for each profile, a legislative history of how its (unintended) ambiguities have been resolved.

As to the registration of functional and assurance packages, one participant noted that functional requirements are more marketable than assurance requirements, and consumers tend to buy assurance only under duress. This suggests that there might be many functionality packages but relatively few assurance packages, with most assur-ance packages emphasizing straightforward third-party validation of vendor claims.

It was felt that the vetting process will help to establish the ITSEC's notion of "correct-ness." [The ITSEC defines "correctness" in security evaluations as being the preserva-tion of relevant properties between successive levels of representations. Examples of representations could be top-level functional specifications, detailed design specifica-tions, or an actual implementation.] It was also felt that vetters need to have enough authority to constrain originators, and that international vetting will indirectly alleviate concerns about export licenses. However, the Federal Criteria was not clear about the vetting process and who will pay for the vetting. It was also thought that a well-designed centralized registration process could provide cost-effective, high standards for the evaluation of protection profiles. Without protection profiles, this evaluation activity, much of which is needed for the evaluation of any conforming product, would be performed by many independent laboratories in multiple countries. This multiplicity could result in both a lack of uniform quality and duplication of effort from one evalua-tion to the next.

It was also felt that the vetting of profiles is inherently difficult. During the creation of the TCSEC, vetting of the evaluation classes involved lots of arguing. The challenge is to provide procedures which will make vetting routine, predictable, and well-under-stood.

As to the issue of whether there will be too many protection profiles, the group felt that this will not happen since it will take too much time and money to produce one. Market driven is an important concept - the government should only dictate what the security requirements should be for government agencies, not dictate to vendors what the secu-rity requirements should be for those outside of the government. The protection profile subgroup felt strongly that the market should do that. They also felt that profiles that were responded to frequently (as evidenced by having products created against them and by having them referenced in end-user procurements) would be the ones that would last. Thus, having a large number of profiles was deemed not too important. This concept reduces the need for government participation except as a local registry and as a provider of coordination services.

As to the question of whether the ITSEC notion of a security target is necessary or suffi-cient, it was felt that both profiles and security targets are needed because they serve different, complementary purposes. According to the participants, the most significant difference between protection profiles and security targets, by far, is the fact that consumer groups produce profiles whereas vendors produce security targets. As noted in the session on evaluation assurance, a security target includes not only protection profile information but additional design information and justification that the design is correct. Security targets allow flexibility by providing a vehicle for a producer to specify security objectives, services, and/or mechanisms that exceed those found an existing profile. For example, many C2 systems meet the B3 Discretionary Access Control (DAC) mechanism requirements. Both groups felt that having a security target without having a protection profile may be sufficient in cases where there is no need to have a general set of requirements that several vendors can built to, or when specifying the security aspects of a "one shot" system or product prototype. If a single unique product is being built, a security target is all that is needed and can be evaluated against. The Federal Criteria needs to be designed in such a way as to not shut out good security solutions. Allowing products to be evaluated solely against security targets provides a means of addressing this concern. Such an evaluation can encourage a vendor to find a solution to a user's problem, even if it doesn't meet an existing profile.

The participants felt that the existence of a security target is always necessary in that it shows how a vendor meets a protection profile (when one exists), shows claims of what a vendor provides in absence of a profile, and shows claims of what a vendor provides beyond a profile. It was also felt that the relationship of a security target and an imple-mented product with respect to the evaluation process needs further clarification, and that the structural differences between protection profiles and security targets also needs further clarification. The participants concluded that when a security target can meet a variety of protection profiles, we may have the best marketing value.

The Federal Criteria allows but does not require the creation of linear profile hierarchies (as in the LP1 - LP4 series). One participant observed that since different environments have different risks, a linear profile hierarchy suggests that all risks in one environment at a lower profile hierarchy are included in some uniformly more risky environment in a higher profile hierarchy. In general, it was felt that there should be no requirement that protection profiles be hierarchical since this would be too rigid, but a number of protec-tion profiles could be considered as a family or hierarchy to give the industry some lati-tude for improvement. It was also felt that vendors will probably aggregate profiles to cover more than one market.

Components

There were a lot of issues regarding how the components were created that transcended what type of components (functional, development assurance, or evaluation assurance) they are, and the component group (morning) and global issues session (afternoon) were asked if the components ("building blocks") as created were a useful notion. There was a slight divergence in opinion between the two groups. The component group was unhappy with the existing components even though they liked the concept of a common language for building protection profiles. They felt that the Federal Criteria components as they are now stated do not help protection profile writers since few were happy with the Federal Criteria profiles and two-thirds of the existing components were not used in these profiles. However, the global session group liked the component approach. However, the divergence of opinion here is not that large since the global issues group also agreed that all the components should be re-examined.

The component subgroup was not sure a "common" component language was possible since there is no "algebra of building blocks", that is, it was unclear how one specifies component requirements at a uniform low level as the Federal Criteria attempts and how one should put these levels back together as a coherent set of requirements. Most (but not all) in that group felt that many functional requirements could be stated by utilizing an algebra, but that this would be more difficult for assurance requirements. The group generally felt that we as a community do not understand the ways in which components can be merged and therefore were very concerned that meaningless (and even harmful) requirements could be derived from what seem like valid components. The group was not convinced that just listing the dependencies would suffice to address this concern.

The component group also felt that the authors should state the basic principles behind the components that were built. They felt that if these criteria were not based on accepted scientific or engineering principles, they would not be valid. There was a strong consensus in the component group on this point. The most conservative members in the component group felt that the only basic principle that was stated in the Federal Criteria was that of the reference monitor, and that this was not satisfactory. The global issues group could not identify any basic principle beyond the reference monitor that could be a justification for why the components were built and therefore thought the "basic principle" notion would not help in building the components.

Both groups agreed that the ordering and grouping of requirements in the components themselves should be re-examined, however, the component group was more critical about the component content and felt that the components should be recast. The compo-nent group felt that value added "features" should not be ordered (the global issues group could not see an alternative to this), but that other requirements should be strongly ordered and grouped (mostly the assurance components). The component group also felt that some components should have been further unbundled (these being mostly the functionality components). Also, both groups thought that components need not be of like ordering or granularity. The afternoon group thought that the present hier-archy with increasing levels may not necessarily create a product that is more secure, and agreed with the morning group that the separation of requirements into different functional levels were arbitrary (e.g., the auditing component). The global issues group stated that component requirements should not restrain implementations. The global session group also pointed out that there is a problem with the meaning of the word "level" in and of itself. For example, it was pointed out that if level 3 were chosen across the board for a protection profile, you would not come out with something reasonable. However, as opposed to the component group, the global issues group thought that the ordering and grouping should be re-examined and not done away with.

One suggestion was made in the component group for re-doing the component organi-zation. First, the basic principles should be documented. Then, the currently accepted industry "bundles", that is, all the criteria that is know as accepted (e.g., the TCSEC, ITSEC, CTCPEC, Minimum Security Functionality Requirements (MSFR), Trusted Database Interpretation (TDI)) should be used as a starting point and then value added features should be added unbundled and unordered. Then, the authors should carefully examined the "new" components that were created. However, the global issues session strongly disagreed with this suggestion. They felt that the components should not be re-done, and were unsure as to what basic principles can be identified. They felt very strongly that the TCSEC "bundles" should not be used as a starting point because the TCSEC "bundles" did not address commercial concerns. They also felt that the TCSEC did not represent all basic principles.

Both groups thought that the inter-dependency analysis between and among the various requirements in the components should be better spelled out since it will be difficult for profile writers to figure them out for themselves. It was felt that for each "shall" in the Federal Criteria the dependencies should be identified and listed with each component. It was also felt that the Canadians did this in a more straightforward fashion in that all their dependencies were highlighted in boxes with each component, and that we may not be able to map out all the dependencies.

The component group felt that new or modified requirements were introduced in too great a volume, but the global issues group thought that this could be only a document organization problems. The component group also felt that the document organization should be re-examined and the Federal Criteria should be minimized. They also would have liked to have seen the functional packages. The component group also felt that the Federal Criteria should limit the requirement statements to accepted engineering prac-tices rather than research ideas (but not exclude adding new accepted ideas), but the global issues group didn't see how this statement applied to the Federal Criteria - the only research idea that they could remember was real time audit alarms. The component group identified several items that they felt were not well accepted. These included the requirements for both functional and penetration testing as defined in the Federal Criteria since they are significantly different from the ITSEC and TCSEC, the require-ment for using "high-level synchronization," the allowance for layering violation, and the use of multi-threaded tasks for Trusted Computing Base (TCB) structuring.

Products vs. Systems

The first discussion focused on the different approaches to "products" and "systems" in the ITSEC and FC. Someone from the audience stated that the Federal Criteria is only applicable to a "product," while the ITSEC was applicable to both "products" and "systems." [The ITSEC defines a "product" as being a package of IT software and/or hardware that provides functionality designed for use or incorporation within a multi- plicity of systems. It defines an IT "system" as being a specific IT installation with a particular purpose and operational environment.]

Part of the problem is semantic. The definitions appear to be overloaded. "Systems" appears to refer to both actual environments of use as well as assemblies of products. The definitions also seem to be dependent on the observers viewpoint. A supplier may be a "system integrator" who employs "products" to produce a "system." But to the integrator's customers, the resultant integration may be a "product" offered for sale.

Some people thought that additional concepts existed between "products" and "systems." Others thought that the problems were all in the semantics.

Next, the group addressed the re-use of "product" evaluations when the "products" are integrated into "systems" or larger products. The consensus was that the "product" eval-uation produced by the existing Trusted Product Evaluation Process (TPEP) are not re-usable. The published evaluation reports appear to be designed as final reports, not as intermediary vehicles for conveying information for subsequent re-use. For example, detail and proprietary information are excluded. Limited re-use might be possible with respect to correctiveness, but only with many caveats. A need was expressed for a rigorous methodology, referred to as an algebra, for combining various evaluation results.

On a positive note, they felt that the knowledge gained from looking at previous evalua-tion results were useful from a social point of view in that it gave the reader some knowledge as to who performed the evaluation and how much they could be relied upon.

The combination of several products was referred to as composition. It was the group consensus that composition depends on architecture, design, and interface specifica-tions. Without specifications for interfacing security-relevant parameters between prod-ucts, composability will be difficult and re-use of evaluation results next to impossible. Security interface specifications are probably the key to evaluation re-use.

The majority of this group thought that it is practical to specify generic criteria that could be used for either products or systems.

Miscellaneous Issues

Several other points were brought up in the global issues session. These are listed below.

Other Federal Criteria Benefits

Other Federal Criteria Concerns

Objective measures: There was a great deal of discussion by the commercial vendors that objective measures may not be necessarily useful to the customer and that the Federal Criteria has to strike a balance between sticking to measurable requirements vs. making value judgements (which can be product differentiators).

Flaw Remediation: In general, the global issues group liked the Flaw Remediation component, but some commercial vendors where concerned that how flaw remediation was addressed may depend on the severity of the flaw and that the issue may be "who do you tell what to when." They also felt that they wanted the freedom to tell a customer to apply the fix without revealing what the particular problem is (for security reasons) and that this was not spelled out in the Federal Criteria. Also, how one prevents the intro-duction of flaws during flaw remediation should be addressed.

Development and Evaluation Assurance: The group felt that the separation of evalua-tion and development assurance requirements as now found in the Federal Criteria may not be useful.

Evaluation process: The group was not happy with the evaluation process as it now exists and felt that the evaluation process is a ten year experiment that has failed. It was pointed out that in Europe the evaluations of products only occur when the customer demands it, and the Federal Criteria in and of itself has value even if no evaluations are ever done against it. Some commercial vendors stated that "designed to meet" has some relevance to the consumer, although others stated that this phrase could just as easily be used to mislead the consumer. However, the protection profile group also felt that there needs to be some way of encouraging truth in advertising; vendors too often have prod-ucts evaluated in unusable configurations, thereby defeating the whole purpose of the evaluation process. This might be done via constraints on the vetting of profiles and the evaluation of security targets. One light hearted suggestion was for the government to copyright profile names, requiring that they not be misused, just as the Ada Joint Program Office copyrighted the use of "Ada."

Rating Maintenance Phase (RAMP): There was a concern that the RAMP process was not addressed in the Federal Criteria.

CHAPTER 4 Functional Requirements

Initial Topic Issues

Martha Branstad of Trusted Information Systems presented issues concerning precision in terminology. She emphasized that the Federal Criteria must be meaningful and under-standable. Her focus was on arriving at a definition of security. She quoted Dan Sterne's definition of a security policy objective as "A statement of intent to protect an identified resource from unauthorized use" and emphasized that security is not synonymous with correctness.

The ensuing discussion surfaced several incompatible positions concerning definitions of information security. The pragmatic position was that information security encom-passes whatever activities are conducted by people whose function is to support infor-mation security. The theoretical position was that information security consisted of those objectives and controls that could be supported by a single technological mecha-nism, namely the reference monitor. It was also observed that just because a concern is important, or even critical, doesn't make it part of security. It was suggested that combining too many concerns under the rubric of information security dilutes the focus.

Identification and Authentication

Presentations on Identification and Authentication were made by Russell Davis of PRC and Robert Bosen of Enigma Logic. Both their presentations and the discussion focused on passwords. Overall, they felt that the FC should not specify implementation mecha-nisms. "The Federal Criteria should lead but not mandate the way."

Although networking issues had been declared out of bounds during the opening plenary session, there was general consensus that plain text transmission of passwords was too important a vulnerability to ignore. Network monitoring hardware and software makes it very easy for passwords to be compromised. Users without private offices were identified as being vulnerable to password compromise.

In light of these well-known vulnerabilities of passwords, there was considerable senti-ment that too much emphasis was placed on password selection and generalization. Lack of human engineering was also cited as a problem, especially when more than one password must be memorized by a user with multiple computer systems and accounts. Removal of password guidance to a separate document was strongly advocated.

The absence of any material addressing authentication by means other than memorized passwords was considered a gross oversight. Various technologies were mentioned, including smart cards, trusted path, and encryption. Biometrics were not mentioned during the session.

Access Control

Joe Sirrianni of the Air Force Cryptologic Support Center and Ravi Sandhu of George Mason University presented their views on Access Control. They felt that Access Control is the single most important issue, perhaps after Identification and Authentica-tion. They admonished the working group to start afresh and write clearly. In particular, they pointed out that Access Control is a mechanism and that it was unwise to force a policy legacy from the TCSEC onto the new criteria, suggesting that the TCSEC should be preserved as a protection profile and not as Access Control Functional components. See the discussion on policy neutrality for more on this point. They suggested that the granularity of the Access Control component is too coarse; it should be subdivided. Questions were raised about the validity of comparing Access Control ratings between two products or profiles. For example, CS2 and CS3 contain dissimilar extensions to the AC-2 component. Separate rating of Access Control components according to the policy enforced was suggested.

Availability & Fault Tolerance

Presentations on Availability & Fault Tolerance were made by Vic Marshall of Booz, Allen & Hamilton and Holly Hosmer of Data Security. They pointed out the need for worked general-purpose examples to aid in assessing these attributes. There is no agree-ment on what any of this means. It is an application-dependent issue; for example, prevention of denial of service in one application inappropriately denies service in another.

Availability covers much more than security; availability is not a security service, according to GOSIP. Denial of service is only one type of threat. Resource allocation is a duty of the system administrator. Fault management is not security management. The TCB should be expanded to provide these services. The components of availability are containment, fault tolerance, robustness, and recovery. Customers take a holistic view; so should the FC.

Policy Neutral Criteria

There were several comments that the FC failed to meet the stated goal of policy neutrality. Policy is implied in many places. There is no technical rationale and justifica-tions for the statements about policy neutrality. We know how to build things that enforce some confidentiality policies; we do not know how to build things to enforce availability and integrity policies. The fundamental mechanisms that work for one policy do not work for the others. When one starts requiring policy, one restricts innova-tion in design of policy. The requirement to define a policy was not stated clearly or obviously.

The components are replete with policy. For example, System Entry is a policy issue. "The TCB shall appear to perform the entire user authentication procedure even if the user identification entered is invalid" is an I&A policy issue. Policy is ANYTHING which restricts the methods by which the vendor can meet the requirements stipulated in a given functionality or assurance component.

Discretionary Access Control (DAC) assumes that the individual user is the funda-mental policy attribute on which the controls are based. This does not have to be so; for many commercial uses, it should not be so. A requirement for fail-safe default parame-ters is logically impossible because definition of "safe" is policy dependent in a very complex way. The FC appears to prevent a policy which preserves the anonymity of users.

TCB & Reference Monitor Focus

A presentation concerning focus on the TCB and Reference Monitor was made by Sven Larsson of the Swedish Defense. Considerable polarization focused on TCB & Refer-ence Monitor concepts. (At one extreme was the position that the FC exhibits a lack of underlying principles from "basic science." This was understood to refer to the Refer-ence Monitor concept as the principle basis for secrecy and integrity. Rigorous mathe-matics has been applied to the Reference Monitor.) The FC omits the partitioned TCB, balanced assurance, and TCB subsets. From this viewpoint, the FC fails to protect against deliberate acts of a hostile opponent; rather it relies on "penetrate and patch."

The contrasting position holds that the TCB and Reference Monitor are merely a design concept. They represent one way to design an operating system and that design concepts should be covered under assurance, NOT functionality. A question was raised as to whether the Reference Monitor concept is still suitable when information flows from one computer system to another in a network. In this instance there is no single state or single domain and security information needed by the Reference Monitor is not strictly under its own control. Software that implements any functional security requirement is part of the TCB.

Somewhat between the extremes are observations that a TCB should really protect against malicious software. The TCB sometimes is not distinct software within a product. The TCB may not be identifiable or minimal; it is often the entire product. Appendix B in the Federal Criteria, "The Reference Monitor Concept," does not accu-rately reflect the notion of the Reference Monitor.

Integrity

Gary Grossman of Cordant made a presentation on integrity, introducing the concept of integrity problems which do not involve a subject or access control. Examples include hardware noise and component failure, software bugs and viruses, and errors by privi-leged users.

Considerable discussion focused on the question as to whether the TCB concept applies to integrity. The FC does not provide for the notion of an integrity TCB. One position is that an integrity TCB is significantly different from a traditional confidentiality TCB. It necessarily includes application- specific components and well-formed transactions. Access control solves a very small (albeit important) aspect of the integrity problem.

There is no mention in the FC of how security management affects integrity.

Open-ended Criteria

The FC and all the components are stated to be extensible, but most of the comments appear to assume that the components presented in the FC constitute the entire set. Why is the message not getting across?

Structure of Requirements

Sentiment was expressed that many of the components in Chapter 4 of the Federal Criteria have been randomly put into a hierarchy. The structure may be related to the policy that a particular system implements and/or the type of threat addressed. Since the relative importance of threats will vary among environments, a hierarchy is not appro-priate.

Summary of Functional Requirements Discussions

Even after many years of work, there is no agreement on definition. Perhaps the FC should focus on specific protection policies, such as protection against unauthorized or undesirable modification, without trying to achieve a comprehensive definition of "integrity." That is, get on with the work and stop arguing on what name to call it. There appears to be insufficient recognition that protection against unauthorized or undesirable modification is considerably different in malicious and non-malicious environments.

The implications of applying the TCB and Reference Monitor concepts to "integrity" need to be studied. It is unclear whether an integrity TCB is a valid concept compatible with the concept of a confidentiality TCB. In many cases the integrity policy is in the application. Extending the TCB and Reference Monitor to encompass applications needs further study. In many cases the application is specific to a system; in these cases, integrity cannot be addressed in a product, only in a system.

Further understanding of the interaction of multiple policies in operating systems and applications is needed. New models may help. The terms "mandatory" and "discre-tionary" do not appear to be rich enough to characterize the integrity concerns.

Policy Independence

Protection profiles should include polices, but components should not have a policy bias. In many cases there may be a one-to-one relationship between a policy and a component. This relationship should be explained. Alternative components should be provided for other policies. In some cases the policies, and the corresponding compo-nents, may be diametrically opposed. The set of available components should be as inclusive as possible.

There are many policy assumptions and biases throughout the FC. For example, Identi-fication and Authentication, System Entry, and Accountability are all policies. Many people appear to find it difficult to acknowledge an unfamiliar policy; they tend to think that the policy they are familiar with is "right" and the unfamiliar is "wrong."

Identification and Authentication

Identification and authentication must be strengthened. There is too much emphasis on passwords, especially when privacy is not assured by physical means. Passwords alone are insufficient in many cases; provision should be explicit for alternative technology.

A common authentication approach is needed. The FC should not specify mechanisms.

The FC should lead, not mandate, the way.

TCSEC Compatibility

The TCSEC should be preserved as protection profiles, not as functional components. An open question remains concerning incorporation of knowledge gained, and require-ments changes made, since publication of the TCSEC.

Access Control

Access control is a mechanism that can enforce many different policies. The tendency to embed policy in access control should be resisted. Role-based access control is not well understood. The interaction between role policy and mechanisms is hard to unravel.

CHAPTER 5 Evaluation Assurance

Introduction

This session addresses those comments pertaining to evaluation assurance and evalua-tion processes. In general, this pertains to Chapter 6 of the Federal Criteria (FC) but some issues will overlap with those of other chapters, and with general issues to be considered by the drafters of the FC.

Session Preparation

Role of Evaluation Assurance Requirements

In response to the question, "Do we need evaluation assurance requirements?," the general opinion of the participants was "globalized" to state that evaluation criteria should be the central aspect of the FC. That is, the document should be product and/or system infosec evaluation criteria. It does not quite achieve that now. It should provide appropriate product and/or system evaluation perspectives. The essential themes of such an evaluation criteria not only should be telling the vendors what to build into their products (the FC does this), but telling them what counts for success. This means detailing what evaluators must do to assure that the product actually meets the success criterion and telling vendors and evaluators both what and how they should document and report the achievement of a successful evaluation in a meaningful way. If the Protec-tion Profile concept is to prove adequate, it must provide such criteria. The components in Chapter 6 do not now support this "global" set of evaluation requirements.

In arriving at guidance, the discussion evolved around three audiences for evaluation criteria: accreditors & certifiers, who must use the output of product evaluations; evalu-ators, who must assess both the product and the processes that produced it; and vendors, who must be responsive both in terms of their product and their (development assur-ance) processes to the criteria requirements. It was proposed that the FC should start with the requirements of the system accreditors & certifiers to derive what is necessary with respect to reporting product information and conveying the assurance gained by product evaluation and vendor product development. The FC authors should then back into what must be done to produce that information and assurance. Additionally, to avoid non-useful products, the criteria must take a system's view with respect to product use and secure extensibility. Finally, to ensure that appropriate products can be acquired for systems, there needs to be an explicit tie-in with government acquisition regulations. Evaluation requirements should be written in such a way that they can be used in procurements, so that a statement of work (SOW) can make use of them (i.e., the Data Item Descriptions (DID) should be visible in, or capable of being assembled from, the product criteria). Current criteria cannot be so used because it is too vague-thus, many of the requirements are not contractually enforceable.

Perhaps most importantly, the discussion of the issue of who are the intended recipients of product evaluation information raised the issue of the proper specification of product evaluation output (e.g., the Final Evaluation Report) which in turn could lead to changes in the evaluation process or to changes in trusted product criteria. Here the discussion indicated that expression of a trusted product must contain some system implications (e.g., the proper way to securely interface the product to communications products which are also trusted; the way to extend the product's TCB). The FC must ensure that interface and extension issues are properly dealt with in evaluations.

For example, accreditors are typically asked to accept modifications of evaluated prod-ucts, and are often faced with unevaluated products built on evaluated platforms. They need help with questions such as the following: Was a given DBMS built on a B1 plat-form in such a way as to destroy its B1-ness? What is the impact of adding Ethernet cards and/or X-windows? Can I&A be done with smart cards or biometric devices instead of with passwords?

>From an accreditor's point of view, the issue of composition of secure products is a real concern. TCSEC evaluations typically have not dealt with this issue. The Trusted Network Interpretation (TNI) and TDI interpretations take some initial strides by articu-lating partitioned and subsetted TCB architectures. However, what is to be provided in evaluation reports with respect to allowable "trusted composition" alternatives (e.g., the methods for interfacing an application on the product when one or both have been eval-uated, or when the evaluated product is connected to another with a different trust rating) should be included in the criteria. Further, if one is connecting products together for performance reasons, what are the limitations with respect to preserving the TCB-ness of the evaluated products?

Another issue that was discussed was missing material that was needed by the accredi-tors. For example, the FC contains no specific support for downgraders and other filters. Accreditors routinely use this kind of functionality and would greatly appreciate evalua-tion support for it.

Almost as an aside, but still very important, a comment was made regarding main-taining a history and rationale for key decisions regarding the system architecture and design. Such information, if made available to accreditors, certifiers, and integrators could be very instructive. It would also be extremely useful for any product evaluation.

The need for evaluation assurance requirements was recognized by everyone present. It was strongly felt that evaluations must be useful to those who would make use of them. This general point came across much more forcefully in the working session than in the various written comments. It was felt that one of the major shortcomings of the TCSEC was that it failed to appropriately articulate and constrain what evaluators do. The rationale expressed for needing evaluation assurance requirements included: (1) ensuring that vendors and evaluators know "what they are getting into,"(2) ensuring uniformity of evaluation, "what counts for success," across organizations and nations, and especially (3) improving the utility of the evaluation output.

The discussion included global perspectives on the expression of requirements. Since we don't want to be too general or too prescriptive, the requirement for expressing what to build and what counts for success remains an issue. From the discussion, we still seem to have bi-polar views endorsing on the one hand, increased generalization to allow vendor flexibility, and on the other hand, increased detailed specifications to constrain evaluator interpretations. Since the criteria written to date, including the FC, provide mostly generalized expression of requirements, the criteria themselves mandate both vendor and evaluator interpretation. This is a natural process, but it has led to adversarial relationships and some "religious" conflicts between vendors and evalua-tors.

It was noted that dependency linkages between and among functional, developmental, and evaluation requirements should be explicitly noted at appropriate points in conjunc-tion with a requirement statement.

One thing that did seem important to the discussion was the need to express the func-tional and development requirements in measurable (qualitative and/or quantitative) terms and directly link both vendor and evaluator actions to these requirements. This action linkage is important whenever the requirements are qualitative, and subjective judgement must be applied.

Additionally, the issue of proprietary information contained in evaluator criteria inter-pretations was discussed. Since many, if not most, of these evaluator interpretations involve assessments of one or more vendor's solutions (expressed in proprietary terms) against a particular TCSEC requirement, these interpretations are not available to the vendors at large. Since the evaluators' interpretations provide a measure (in some cases an extremely significant measure) of what counts for success, a means to publicly express this measure, without compromising proprietary information, must be devised.

Evaluation Organizations and Processes

The discussion also included the issue of the evaluation process. The only security product evaluation organization with extensive experience is NSA. The European Commercially Licensed Evaluation Facilities (CLEFs) and the use of the ITSEC/ ITSEM (Information Technology Security Evaluation Manual) is only just beginning. The NIST TTAP proposal remains on the "drawing board" in a conceptual form awaiting additional details, approval, and resources. Thus, the discussion of process was only discussed at a very general level. However, some important issues did arise.

For example, since evaluation processes are not publicly articulated in detail, the "up front" understanding by both vendors and evaluators of what is involved in reaching an evaluation rating remains open-ended. It was acknowledged that the U.S. TPEP Management Handbook has important process details that need to be made more public in a fashion similar to the ITSEM.

Taking a different tack, a suggestion was to examine new models of evaluations. For example, many software vendors do internal evaluations to better their products. The FAA does assurance by requiring an airplane vendor to get senior employees to certify the plane according to FAA standards. Thus, the vendor does the evaluation at the vendor's expense, using senior staff. The FC could provide a model for doing evalua-tions. Standards for the evaluation process need not only apply to outside evaluations.

Still another tack was the concept of standardized conformance testing suites. The subjectivity behind testing requirements could be greatly reduced by supplementing a protection profile with a conformance test suite. POSIX conformance tests were given as an example.

Significant in the discussion was the recognition that process information, being more dynamic, should be published separately from the evaluation criteria. This would allow for independent process evolution. The content of the Evaluation Criteria itself should be (from the point of view of business management) largely "process-free." It should be results oriented to achieve "objective" repeatability. An exception to this is subjective requirements which clearly require evaluation guidance (e.g., in the form of amount of testing per 1000 lines of code).

It was suggested that to make the criteria process-free requires that evaluator activities be "normalized" and linked to the functional and developmental requirements. Then, separate evaluation process and organizational documents for each type of evaluation agency can be produced, based on these normalized activities. These documents would be companion documents to the FC. These separate documents would contain the more dynamic business processes associated with evaluations (e.g., types of products to be evaluated, length of an evaluation, specific procedural interactions between the vendor and the evaluation team, use of a vendor security analyst, how many resources, qualifi-cation levels). They would not be a "standard" per se, but rather a set of acceptable eval-uation business practices that in actual use would be conditioned by organizational evolution, organizational goals, budget, available skilled evaluator resources, vendor readiness, etc.

Another point raised in the discussions was repeatability of results. This does not mean that multiple evaluation agencies must all be run in the same way, but rather that the quality of the output remains equivalent across evaluations (i.e., a product evaluated by one agency would get the same rating from another agency). If it is perceived that a vendor can get an "easier" evaluation from one or more evaluation agencies, then "shopping around" will occur and the entire process will lose credibility. Thus, proce-dures for maintaining quality control across evaluation agencies must be devised.

In summarizing this portion of the discussion, it was a primary requirement (strongly held opinion) of the group that the FC (or the ensuing Common Criteria) have such companion process documents produced concurrently with the actual evaluation criteria. Having the evaluation processes articulated and resources in place is especially important if the resulting criteria are to undergo a trial use period in a timely fashion.

Need for Additional Material

Evaluator Output: As stated above, requirements are needed as to how evaluators report on their work. The ITSEM contains specific requirements that aim to provide useful information about products in an Evaluation Technical Report. The importance of such requirements is underscored by widespread criticisms of Final Evaluation Reports as being neither timely nor meaningful to potential users of products. Accreditors need to be asked what they need, and evaluators need to receive feedback as to whether their reports are serving a useful purpose.

Closely-Held Source Code: A software assurance technique that is in neither the TCSEC nor the FC is to develop software using cleared users and then to only distribute the object code. An example was given where ITSEC E3 assurance would be needed if source code was distributed and ITSEC E2 assurance if not.

Other Significant, Relevant Issues

A few ideas provided during the working session on protection profiles seem to be more relevant to Chapter 6 than to protection profiles and are thus presented here instead in order to improve readability of the summary reports.

Need for Clarity. Requirements must be clear and unambiguous. Unclear requirements inspire an adversarial relationship between vendors and evaluators and slow down the evaluation process.

Assurance Objectives. How does one market assurance? How does one arrive at a concrete figure as to the value of a given kind of assurance? Other industries face similar questions. How does the phone company decide on a level of protection for a cable vault? How does an airbag manufacturer decide on the thickness of airbags?

Relevant NCSC Literature. There seem to be many relevant documents that are in review or have just come out that are relevant to evaluation assurance. One document that could contribute to evaluation aspects is "A Guide to Procurement of Trusted Systems," Volumes 1-4, NCSC-TG-024, December 1992. Other relevant draft docu-ments are being developed on improving Final Evaluation Reports, on the form and content of vendor test documentation, and on the form and content of vendor design documentation.

Security Targets and Protection Profiles. How should evaluators note that a security target or product is "better" than a profile? If a particular security target realizes some protection profile but also provides some additional features, then profile-vetting requirements may apply to these additional features, so that evaluation teams become involved in the same kinds of activities as profile vetters.

CHAPTER 6 Development Assurance

Working Group Objectives

Prior to the workshop, the moderators reviewed the written comments on the draft FC. NSA/NIST received 111 sets of written comments. Fifty-seven of these contained comments specifically related to development assurance. To initiate technical discus-sions, the moderator presented a summary of these comments. The salient points from this summary presentation are captured in this section.

QUESTION 3: What are the Major Technical Problems with the FC's Development Assurance Components?

oo Design principles such as mandated use of "high-level synchronization constructs," multi-threaded tasks for TCB processes, and allowed layering viola-tions.

oo A variety of modelling concepts: "penetration models," "TCB isolation models," a "model of reference mediation," and a "model of access control."

Most of the working group deliberations consisted of "open, moderated debate." At the outset, the discussions were directed towards the three questions briefed by the moder-ator, plus any additional questions the working group thought were pertinent and that were within the DAWG's scope. One additional philosophical question was added to the moderator's list before debate begun:

QUESTION 4: Why does not the FC allow profiles to include the concept of "balanced assurance?"

As defined in the draft FC, a profile's assurance requirements are monolithic, i.e., they apply equally to all security policy features. The notion of balanced assurance would allow some security mechanisms (e.g., discretionary access control, virus detection techniques) to be implemented with less assurance than other security mechanisms (e.g., label-based protection, certain integrity constraints).

The DAWG did not have the opportunity to discuss this new question. No one objected to this question when it was first offered, and several participants noted their agreement. After further discussion, another question kept arising and merits recognition as an addi-tional philosophical concern:

QUESTION 5: What are the assurance objectives of the draft FC? What should they be?

As described below, several definitions for assurance were debated. A (rare) group consensus was that the FC should specifically motivate its assurance requirements with definitions and objective statements. It is possible for the FC to have multiple (different) assurance objectives.

The working group started by discussing the questions raised by the moderator, but the group dynamics quickly led to other related topics.

The remainder of this section captures the key points raised during the DAWG's discus-sion.

Definitions of Assurance

The DAWG had a long discussion on types of assurances; specifically "product assur-ance" and "process assurance." Roughly speaking product assurance is gained through the design, implementation, and analysis of a product, and process assurance is gained through the controls and procedures used to ensure the quality, safety, and security of the development process and development environment.

Though the DAWG discussed this topic at some length, no general consensus was reached. The way in which this view of assurance is addressed by the FC was also not significantly discussed. Some felt the FC (and other security standards) focused too much on product assurances. Others felt the FC focused too much on process assurance, and that these were of lesser importance. Others still thought both were important, but had to be balanced with the expected threats and expected level of assurance.

QUESTION 2: Does the expression of development assurance requirements as "components" have utility?

The DAWG discussed this question at length. The general consensus was that compo-nents give the profile developer flexibility, but they also carry some significant liabili-ties. Much of the debate centered around these liabilities, and whether they justified the flexibility gained.

Liabilities Associated with Components

After discussing the potential liabilities with requirements components, the working group discussed whether the benefits of components out-weighed their liabilities. Most of the DAWG were reluctant to drop the notion of components from the FC and thought that, at least in theory, it was a good idea. However, there was also a great deal of concern whether components and subsequent reconstruction into profiles was practical. Some DAWG members felt we do not have sufficient understanding of requirement components (the understanding we lack has been called the "algebra of components"), and the FC should not depend on what is essentially a research issue (i.e., the FC should address whole protection profiles or large sets of requirements like assurance "pack-ages" rather than requirement components). One person gave the analogy that "two arms, two legs, a torso, and a head does not necessarily make a person."

This discussion led to the issue of quality control over components. Repeatedly, the group heard that the "vetting" process will control the quality of profiles, but there seemed to be no similar control over components. When a participant asked how new components are included, the answer was that they are introduced via "vetted" profiles. The discussion then focused on whether any component should be included in the FC unless it has first been "vetted" in a profile, and then the requirement should be taken as a whole from the profile. The group observed that more than two-thirds of the compo-nents listed in the FC were not included in the FC's example profiles. Some felt that "unvetted" components should be strictly banned, since there will be the impression that if a component is listed in the FC, it must be technically sound. Others felt that the out-right ban of "unvetted" components may be too strong, but that there should be some control over their quality.

QUESTION 3: What are the Major Technical Problems with the FC's Development Assurance Components?

The DAWG briefly discussed the third question raised by the moderator. A couple of participants asked whether these were "nits" that were not important enough to discuss at this time. However, most of the DAWG felt that these comments were indeed funda-mental technical issues that should be addressed before the Common Criteria effort begins. Indeed, some felt the issues raised in the written comments and summarized by the moderator (see the QUESTION 3 summary in Section 4) are fundamental concerns that must be address prior to the Common Criteria effort. There was a general sense that the FC was introducing concepts that are not well-accepted, and sometimes introduced these concepts under names which had different meanings in the TCSEC, ITSEC, or CTCPEC.

Miscellaneous Topics

In this section, various related topics that were discussed by the DAWG are listed. These topics are listed in no particular order.

Some felt that the concept of effectiveness as defined in the ITSEC was inadequately addressed by the draft FC. This concern was still present even after it was explained that the FC intended to address effectiveness via the profile "vetting" process.

Many DAWG participants voiced strong concern about the manner in which the FC distributed the TCSEC and CTCPEC's notion of operational assurance, especially the system architecture requirements, throughout the development assurance and function-ality components. This structure resulted in reduced or even harmful redefinitions of the system architecture requirements. The principle example of this problem was the way in which the FC defined the least privilege requirements as solely a set of mechanisms (some felt that these mechanisms themselves encouraged poor least privilege designs) rather than defining least privilege as a global design concern, which may partially be satisfied in some cases by the mechanisms listed.

Some DAWG participants felt that evaluation requirements should be listed with the functional or development assurance requirements.

There was a general consensus that "reliability" does not necessarily imply "assurance" in a security sense. The example given was the phone system, which is exceptionally reliable (i.e., phones calls go through at rates of success) but has been widely and deeply penetrated over the years.

The DAWG generally agreed that the FC poorly uses the terms "trusted subject" and "privileged subject". In particular, the FC uses the term "privileged subject" where "trusted subject" should be used. A subject need not have privileges in order to be part of the TCB (e.g., an unprivileged audit collection utility). Likewise, possession of a privilege need not mean that a subject is part of the TCB (e.g., a privilege to increase or decrease a process' priority may be allocated to non-TCB subjects). Others noted that the FC should not discuss "trusted subjects" at all, since it is an implementation detail. In most cases, it should suffice to simply distinguish between TCB and non-TCB (and possibly Reference Monitor and the non-RM TCB).

Summary and Conclusions

This report represents a summary of the discussion held during the Protection Profile session. Most of the discussion points scheduled for this topic were included in the "global issues" sessions held during the first day of the workshop. Consequently, a new set of questions were posed by the moderators for consideration by the participants. This set is presented below.

Questions Posed by Moderators

Overview

The Commercial Security Requirements (CSRs) Technical Working Session included presentations from Michael Ressler from Bellcore, Kenneth Cutler from MIS Training Institute, and Ellen O'Conner from the Internal Revenue Service. Both Mr. Ressler and Mr. Cutler participated in the NIST/NSA working group that developed the Minimum Security Functionality Requirements (MSFR), from which the Commercial Security Protection Profiles (PPs) were derived. As a person responsible for ensuring that extremely sensitive but unclassified information is adequately protected while it is managed by an information system, Ms. O'Conner is representative of a potential typical user of the CSRs Protection Profiles.

In addition to the presentations, the session also provided an opportunity for participants to discuss issues related to CSRs with the intention being that these comments would provide input into the Common Criteria efforts. Participants were requested to focus on general comments (rather than detailed line-by-line comments) and also to focus on areas that were felt to represent "successes".

During the discussion portion of the session, two major themes developed. The first theme centered around concerns with certain information included in the CSRs, while the second theme related to requirements that participants felt should be included in one or more of the CSRs.

The remainder of this report describes the major concerns discussed by participants and their suggestions for additional requirements, and also summarizes the presentations presented by the three invited speakers.

Concerns

The consensus of the session attendees appeared to be that while the CSR profiles do not yet adequately address the needs of commercial and government users, they are a good first approximation (with the possible exception of CS1, which does not reflect the needs of the users and should not be used).

There were several recommendations for features that participants felt needed to be included in the CSRs. There seemed to be consensus that the major missing features related to networking and distributed systems, low-assurance PCs, and encryption. Other features were also mentioned. The discussion related to each of these features is described below.

Networks and Distributed Systems: Participants mentioned that excluding network connections resulted in an "unrealistic environment" since most environments have network connections. Consequently, networks and distributed systems should be addressed by the Federal Criteria. In a related comment, it was pointed out that other requirements should take the networking environment into consideration. For example, in developing authentication (e.g., passwords) requirements, there should be a recogni-tion of the fact that users log onto multiple systems via networks.

Low-Assurance PC Requirements: Attendees stressed that profiles with lower assur-ance and functionality are needed and that the CS profiles must address other environ-ments beyond multi-user operating systems. Profiles that provide for lower functionality and assurance would be very useful for both commercial and government users. A low functionality/basic assurance profile for PC's or workstations may be appropriate for some users.

Encryption: Another missing feature that was widely commented on was the lack of requirements related to encryption. However, someone mentioned that encryption cannot be mandated in a Protection Profile because of export restrictions. Someone else countered that although encryption algorithms are not exportable, the interfaces to the algorithms are exportable. There was some additional discussion as to whether this comment was correct.

Labels: The issue of the need for labels in the commercial environment generated a great deal of discussion with first one participant stating that they were definitely required, and another responding that they were not needed. It was also noted that mandatory access controls are needed, but that the term "label" (with its DOD connota-tion) is the problem. A suggestion was that the term "security tag" be used rather then the term "label". Other attendees pointed out that labels can be used to protect against viruses and may be useful in protecting against corporate espionage. The consensus among attendees seemed to be that there is a need within the CSRs to include require-ments related to mandatory access controls.

Role-Based Access Controls (RBAC): The concept of RBACs was another topic that generated a great deal of discussion. Several attendees felt that RBACs were needed in the commercial/civil section, and consequently, that requirements related to RBACs should be included in the CSRs. However, there were cautionary comments that "roles" are a new concept and not yet well-understood, and that perhaps for this reason they should not be included as requirements. In spite of these cautionary comments, the consensus of the group seemed to be that, because RBACs are needed they should be studied for possible inclusion as requirements in one or more of the CSRs. There were also suggestions that the Federal Criteria include the "primitives" from which RBAC requirements could be built.

MSFR: The attendees felt that "the MSFR was a more useful protection profile." The participants preferred the approaches used in the MSFR to those in the CS profiles. Terminology, level of granularity and clarity of requirements were all mentioned as superior in the MSFR.

The consensus of the participants was that the MSFR work should be preserved and included in the Federal Criteria as a Protection Profile.

Ratings Maintenance Phase (RAMP) and Official TCSEC Interpretations:

Someone commented that the CSRs appear to include neither RAMP nor the interpreta-tions. Another attendee stated that commercial users do not care about RAMP. Another attendee stated that some RAMP requirements, such as configuration management and trusted distribution, are needed by the commercial/civil sector.

Application Programming Interfaces (APIs): CSR's need to include requirements for APIs that can be used by application programs to access security-relevant information.

Malicious Users: The CSRs should include requirements that protect against malicious users.

User Education: There was some discussion as to whether the CSRs should include requirements related to user security awareness education since this acts as a threat reducer. However, the consensus of the participants seemed to be that it should be not included as a requirement in any of the CSRs.

Presentation One - Michael Ressler - Bellcore

Mr. Ressler presented an overview of Bellcore and its security requirements. He stated that Bellcore security requirements do not align with the TCSEC because the 'C' level does not provide enough security functionality nor assurance and the hierarchical access control model of the 'B' level is inappropriate for their environment.

He also provided an overview of general commercial security requirements, including the need for inclusion of confidentiality, integrity, and availability policies and the need for confidence, quality and robustness of security features. Mr Ressler also gave an overview of the Minimum Security Requirements and his critique of the Federal Criteria.

Finally, he provided his recommendation for a new Commercial Security Profile based on the CS3 Protection Profile which reflects the original Minimum Security Functional Requirements (MSFR) and Minimum Security Assurance Requirements (MSAR).

Presentation Two - Kenneth Cutler - Vice President, MIS Training Institute

Mr. Cutler provided general comments on the Commercial Requirements contained in the Federal Criteria. He also recommended the creation of additional profiles and the deletion of superfluous profiles.

He suggesting adding requirements for expert systems to be used for audit analysis purposes and real-time checks. He also suggested that the concept of "approval authori-ties" should be considered.

He felt that supporting availability is important.

Presentation Three - Ellen O'Conner of the Internal Revenue Service

Ms. O'Conner works for the Criminal Investigation Division (CID) of the IRS. Ms. O'Conner described CID applications that manage extremely sensitive (but unclassi-fied) information such as case- related information, informant, undercover, and agent information.

Ms. O'Conner explained that because of the sensitivity of the information that is being managed, both RBAC and row/record access controls are required. She would like the CS3 Protection Profile to include both RBAC and row/record access controls.

CHAPTER 9 Label-Based Protection Profiles

Introduction

The Federal Criteria Workshop session on Label Based Protection (LP) Profile Comments was attended by thirteen organizations ranging from government, such as DOE, Air Force, and DIA, to industrial, such as Grumman, Boeing, TIS, Sparta, CTA, and individual consultants.

Discussion

LP Profiles versus TCSEC Classes

There was considerable discussion on the relationship of components and profiles. It was felt that the separation of requirements into components with arbitrary relationships added to the differences with the TCSEC. The dividing of Operational Assurance may not have been necessary if a large component had been defined to maintain the relation-ship that exists in the TCSEC. The requirements in the LP Profiles are based on require-ments that have been inaccurately divided into components which when put back together do not equal the TCSEC classes.

It is not well understood whether components or profiles should be defined first. Since the vetting involves profiles, it was felt that components should be pulled from approved profiles to be used as building blocks. Artificial creation of components was viewed as a cause of the LP Profiles being different from the TCSEC classes.

Conclusion: The TCSEC requirements should not be divided into arbitrary components. After the profiles have been vetted to be equivalent to the TCSEC classes, the compo-nents could be identified for use in building other profiles. If other components are still required, then new profiles should be made based on those new components, as written and without extra verbiage or refinements. Words used in components should match the words in profiles and they must be correct. Note: There may need to be a vetting of new components from new profiles.

Reference for Including a Requirement

It was discussed that there needs to be a set of guidelines to define worked examples that qualify for inclusion as a new component or a new requirement in the criteria. The TCSEC claim was that there were three worked examples of each requirement; however, some of these examples were not readily available to industry. The inclusion of a worked example must have wide acceptance over multiple communities and in industry. Multiple examples of implementations by vendors must be provided to vali-date that the concept is reasonable and implementable. Research should not serve as the basis for inclusion; however, there may need to be an acceptance of a few basic research concepts.

Conclusion: For inclusion in the criteria, the requirement must exist in industry (not just academia), multiple examples must be provided, the requirement must reflect a reason-able view of the technology community wide, and there must be a balance of technical advancement and example implementations.

Need for Rationale in LP Profiles

This discussion focused on the different levels of detail in the rationale sections of the LP and CS Profiles. There is a great deal of rationale that should not be missed to support the requirements of the TCSEC. It was noted that due to time limits this ratio-nale could not be included, but that in the future there needs to be consistency in the rationale sections of the profiles.

Conclusion: Rationale is totally missing from the LP Profiles. Well-written rationale could provide effective input for procurement specifications. The rationale should iden-tify threats and Yellow Book English rationale types of things.

Naming Conventions

The current naming conventions imply a relationship between components and between profiles. The hierarchical nature of the TCSEC classes should be maintained, but that does not mean that there is a relationship among all components or profiles.

Conclusion: The naming convention should be changed such that there is not an implied relationship for profiles or components. One way to do this is to use the names of the TCSEC classes, such as Controlled Access Protection, which could be called "LP-CAP." The profile description should define any relationship or inclusion of other profile requirements.

Summary

The existing LP Profiles do not represent the same set of requirements that exist in the TCSEC classes B1 through A1. Because of time constraints, it may be necessary to use the exact TCSEC language in the profiles to allow for a vetting of the profile to update them with evaluation case law that has evolved over the past decade of experience. A multidiscipline group of vendors, evaluators, and users should update the profiles over time to enhance the requirements to the level of practice. This process would then produce new profiles that relate to the TCSEC as well as provide an exact copy of the TCSEC requirements.

The language and description of profiles need to be further refined to ensure that the relationship between components and profiles is precise and well understood. The process of profile development and vetting must be defined so that it is well understood by the vendor community. Until the vetting process is well defined, the language of the TCSEC should be maintained in the equivalent LP Profiles.

CHAPTER 10 International Harmonization

Introduction

This workshop session covered the steps for moving forward from the draft Federal Criteria (FC) to international harmonization. It was held in the context of the announce-ment that the governments of North America (NIST, NSA, and the Canadian CSE) have entered into an agreement with the European Community (United Kingdom, France, and Germany) to work over the next year towards a Common IT Security Criteria. A Common Criteria Editorial Board (CCEB) has been established, though at the time of the workshop it had not yet met. In this session, all six members of the Editorial Board were present as participants in the discussions. They are:

Paul Cormier, Canada (Communication Security Establishment)

Chris Ketley, UK (Communications Electronics Security Group)

Yvon Klein, France (Central Security Service for Information Systems)

Hartwig Kreutz, Germany (German Information Security Agency)

Mario Tinto, US (National Security Agency)

Eugene Troy, US (National Institute of Standards and Technology)

Approximately 25 other individuals were present, including representatives from various US government agencies, other European organizations, and several representa-tives of multinational computer product suppliers.

Initial Topic Issues

The FC states that international harmonization of criteria and mutual recognition of evaluations are objectives. The basic question that must be asked is whether the FC work has advanced or hindered international harmonization. A second and related ques-tion is what is the path to achieving harmonization from this point. It is generally agreed that we all want to be pointed toward international convergence in this area, yet how do we achieve that while saving those things in the individual criteria (e.g., TCSEC, ITSEC, FC) that the nations believe are important? Numerous comments were received that generally discussed issues related to harmonization. The topics below were derived from an analysis of those comments in the light of the impending Common Criteria project.

1. What are Potential Roadblocks to Harmonization?

The key issues about harmonization identified in the FC comments deal with:

a. Assurance Approaches

What are the elements of assurance, the process of gaining confidence about the security functions in the product? The Europeans have advanced the twin notions of effective-ness and correctness in the ITSEC, while the US has divided the assurance process into development and evaluation assurance. Is there a way of converging these two approaches, and do they even cover the same thing? It may be that the differences between them are more perceived than real. The issues may be more of form and style, rather than substance.

b. Protection Profiles in the FC versus Security Targets and Functionality Classes in the ITSEC

Some convergence in the area of security targets has already been seen in the workshop. There is no indication of this prospect for convergence in the comments because in the draft FC protection profiles were not clearly enough related to security targets and func-tionality classes. It seems to be becoming much clearer that in general, protection profiles can usefully be viewed as user requirements while security targets are to be seen as engineering specifications. It is also clearer that protection profiles may not always be needed for product evaluations.

c. International Profiles

A number of FC comments focused concern on the prospect of further fragmenting the international IT product market via free creation of a spate of protection profiles. There was also a significant amount of concern in the comments over the implication of export laws with respect to products built to protection profiles. The reviewers generally seemed to accept that it must be left to the national government agencies to decide the IT security requirements for their governments and state them to the suppliers. Several reviewers advanced the notion of going beyond national standardization (or vetting) of profiles to do so on the international level, although it was noted that it is difficult to see how that could work. There is clearly an expressed need to converge with other interna-tional standardization work, such as ISO SC27. Questions that arose in this connection are the following: How do you handle international development and vetting of protec-tion profiles? Who is a legitimate developer of profiles under such a system? Who will be entrusted with the duty of deciding whether profiles are proper? How can profiles evolve over time to keep pace with requirements and technology?

2. Phase-in to Harmonization

The key concerns about the process of achieving harmonization identified in the FC comments and in later informal comments received on the Common Criteria project deal with:

a. What Should be the Steps to Harmonization?

Some comments expressed concern about the inherent feasibility of achieving harmoni-zation. It was noted that there are four IT security criteria now in existence, in varying degrees of completion. The concern was how we can move from that posture to a single criteria that can be agreed upon by a large number of nations. A proposal has been made that the CCEB should focus its work on the common core, the toolset, and not on devel-oping or agreeing on profiles.

b. How Should Users & Suppliers Proceed during Convergence?

This is a concern that was expressed in the comments with respect to the phase-in of the FC which has even more applicability to the Common Criteria work. There is a concern whether there are some specific things that we can do to help users and suppliers in the interim. It was noted that the UK and Germany have experienced this problem of having their own criteria and then phasing into use of the ITSEC. There is a need to plan care-fully for the transition. One supplier noted that suppliers will tend to respond to these influx requirements by building their products more generally to encompass multiple sets of requirements.

c. How Should Backward Compatibility with National Criteria be Handled?

This question is closely related to the previous question. Comments in this area were expressed mostly as generalized concerns, not so much with protecting the criteria themselves but with the supplier and user investments in prior standards. In the interna-tional arena, it was noted that national laws or regulations, such as those of Germany, have an impact because they specify adherence to particular criteria.

d. How Does this Work on Common Criteria Relate to ISO SC27?

In the same context, other reviewers were concerned about how to handle the issue of achieving an ISO standard that incorporates the FC work. This question is now extended to the Common Criteria work. The question boils down to: How can ISO SC27 relate to the Common Criteria development process? How will the Editorial Board and its spon-soring nations make their work applicable and acceptable in ISO?

Presentation by Julian Straw, SISL (UK)

Mr. Straw, a senior evaluator for one of the UK commercially licensed evaluation facili-ties, made a cautiously optimistic presentation on the FC versus the ITSEC, which has specific application to the Common Criteria work. He viewed the FC work as providing many new ideas and material that are supportive of harmonization.

Mr. Straw identified the following main issues that need to be dealt with in achieving international harmonization. Several of these were also covered in his written comments. Accordingly they will not be gone into in detail here.

1. Common Criteria

The FC has helped sort out the differences among the current criteria by moving in the direction of rapport. He cited the separation of functionality and assurance, the use of the security target as a basis for the notion of a protection profile, and the acceptance of the notions of correctness and effectiveness as expressed in high-level requirements. He noted that there are indeed commonalities between the ITSEC's correctness/effective-ness and the FC's development/evaluation assurance approaches, but pointed out several specific differences in application of these requirements at various levels on each side. He was very concerned with the FC notion of dependencies, and felt they would become a big issue because there is no common agreement on what they are or how they are identified and expressed.

2. Evaluation Method

Mr. Straw noted there is some experience with using a multi-national criteria in Europe. However, he said there have already been instances where evaluators and certification bodies in Germany and the UK have interpreted parts of the ITSEC differently. This makes it clear that a single set of criteria among nations is not enough in itself. There is also a need for a common evaluation method as a basis for harmonization, to ensure that developers and evaluators do the same things.

3. Product Certification Process

Mr. Straw pointed out the central importance of evaluation results acceptable in one country also being acceptable in another country. He identified two levels of mutual acceptance: acceptance of the results of evaluation, and acceptance of certificates issued. These can be considered somewhat independently. For example, it is possible for a product evaluation report to be passed from one country to another, with the certifying body in the second independently deciding whether it wants to award the product a certificate based on acceptance of the evaluation report. However, he said that the second level of mutual acceptance, that of a second national certifying body accepting a certificate issued by the first, should be the objective. If we can trust one another in both the evaluation and certification processes, it will minimize the amount of duplicated effort.

4. Why Do We Want to Achieve Harmonization?

Mr. Chizmadia, a former evaluator, presented ideas on how to reconcile the ITSEC's effectiveness/correctness with the FC's development/evaluation assurance.

He provided two working definitions for discussion. Correctness asks, "Does the product do the thing (security function) right?" Effectiveness is oriented towards an assurance objective by asking, "Does the product do the right thing (security function)?" Effectiveness then becomes a judgment about the environment and the product.

Part of his work has been oriented towards finding some policy oriented motivation for assurance. In his view, policy is just about how the system makes information available. Security objective is a better term than security policy, because it helps avoid confusion. He states that effectiveness and correctness should be defined at the same level of abstraction as other kinds of "security policy-based objectives," including integrity, accountability, confidentiality, and availability. By doing so, you now have a way of tracing from high-level policy objectives to what specifically is being asking for. You may now identify assurance objectives based on policy, in the same way as you identify the objectives for the security policy-based requirements. These two can then be possibly independent. In this way, all of the requirements for a product must be reflected in the objectives and therefore must be soundly based on policy.

Following this proposed approach, the user has a much better ability to decide what is needed and can then map it down to specific requirements. Independent of security objectives, assurance objectives may also be stated. In this way, you can do assurance independent of security objectives.

General Discussion

A general discussion followed the two presentations, generally based on the set of topics given originally under "potential roadblocks" and "phase-in to harmonization."

1. What are Potential Roadblocks to Harmonization?

The key discussion points centered on the potential roadblock topic issues raised at the start of the session:

a. Assurance Approaches

Discussion continued about some of the incompatibilities between ITSEC and FC assur-ance approaches, particularly effectiveness/correctness vs. development/evaluation. As discussion proceeded, it appeared that incompatibilities remain to be worked out, but these are probably less a problem than initially thought. One of the key differences is that some of the effectiveness work, such as suitability of functionality, is done during profile construction and analysis. A European security expert noted that ease of use is actually handled better in the FC than in the ITSEC, that it is more well rounded. It is treated as part of functionality instead of assurance. He also noted that strength of mech-anism is becoming less important in the ITSEC as European evaluators gradually try to refine what they are trying to test the strength of. In his view, other effectiveness factors may be in the FC, but they are generally found only at the higher levels, while in the ITSEC they are applicable to some degree to all levels. He gave as one example penetra-tion analysis, where it is not used until LP2 while under the ITSEC it is done at the lowest levels.

The general argument about how and why assurance is gained about a product's security functions was raised. This was coupled with discussion about why overt assurance via evaluations should be sought. This issue is important to the harmonization work, because the European Community seems to be strongly vested in the notion of product and system security evaluations for both government and private enterprise. It was noted that assurance that a product works as advertised is commonly expected, but in the non-military world the notion of third-party evaluation as its source is seldom volun-tarily considered. One individual raised the notion that the intelligence community has national risk assessment documents that link risks/objectives of the organizations into TCSEC assurance levels. He noted that they tend not to publicize these documents-they are internal for accreditors use. The end result is that assurance tends to be a distress purchase-because users are told to, not because they want to.

It was agreed there is a range of ways by which people gain assurance about what they buy or use, whether it is cars, seatbelts or computers. The formalized evaluation process is one of these ways that the military and intelligence communities have found impor-tant to them. It is clear that as of this time, commercial users do not see the same kind of value in that process, and tend to do the assurance work themselves in various ways. It may be that work needs to go forward on finding suitable and possibly standardized ways for the private world to achieve assurance about security products short of lengthy and costly third-party formal evaluations. This whole area seems to be tractable as long as we continue to understand more and more on what each side is intending.

b. Protection Profiles in the FC versus Security Targets and Functionality Classes in the ITSEC

The discussion indicated that most people did not find inherent conflict between the notions of protection profile and security target, when each is properly understood. There was growing acceptance of the notion that the concepts tend to be mutually supportive. The discussion pointed up the need for a far better explanation of the joint roles of the protection profile and security target and how the two should be used together in connection with product development and evaluation.

One big remaining area of disconnection centered around the FC notion of dependen-cies. Interaction between product elements is treated in the ITSEC under binding of functionality. As such, it is left up to those preparing security targets and to the evalua-tors. This was noted by some participants as a possible weakness in the ITSEC. It remained clear that the treatment of dependencies in the FC was well below what many viewed as needed. The process of identifying dependencies still seemed overly complex to the participants, and it was unclear how this issue should be treated in the Common Criteria.

c. International Protection Profiles

Perhaps the largest single area of discussion in the session had to do with the notion of international protection profiles. The issues raised covered all the points initially identified.

There was deep concern over the potential proliferation of protection profiles interna-tionally. One speaker from the supplier community even suggested, with support from other speakers, that the success of the Common Criteria venture, from the point of view of actually getting products out in the marketplace, is going to be inversely proportional to the number of profiles available. He stated the reason for that is the market for secu-rity products is actually very weak. There are no security vendors that will claim there is anyone beating down their door. He expressed hope that with internationalization the world will become one marketplace. A number of different profiles will fragment the market again, and then there will be a bunch of little weak markets instead of one strong one.

Another supplier expressed support for the effort because there would be fewer basic requirements, and all of them generated from a Common Criteria which would be used as the basis. He was concerned about one possible scenario with multiple profiles. Say his company decided to build a product to a given profile and have it evaluated (based on a business decision) and then later perceived the incremental market going for another similar profile. He wanted to know whether an incremental evaluation could be done against the differences or would they have to do the whole evaluation all over again and double their costs.

The issue of international protection profiles, from the viewpoint of how to standardize them, who develops them, etc., was discussed. It was noted that this problem has begun to be looked at in the ISO SC27 context. An initiative was also started in the European Community to develop predefined functionality classes for vertical industry segments. A European Community (EC) research task was funded to identify a dozen functionality classes for the commercial sector. No results have yet been published from the study. There was no resolution as to the mechanics of the processes needed to arrive at interna-tional protection profiles. In general, suppliers want to see the advent of these profiles to make their life easier. One point that was brought up is that such profiles should not be highly specific in their requirements.

Another point that was raised is if we gently phase it in (taking into account what everyone wants) we never will achieve the goal-it will take too long. The process is so large and important that some groups/agencies/governments will have to step up and dictate what they want to see. One speaker noted that it will be up to governments to come up with the first set of international protection profiles for it to happen in our lifetime. Who standardizes/vets/registers profiles may be a consortium of interested government bodies. This is the only way to do it in a short time.

One evaluator pointed out the great degree of difficulty that has already begun over gaining consensus that LP-1 represents the same thing as B1. He felt that based on that experience it is not likely that international profiles will gain easy acceptance in the community-there are too many disparate viewpoints and vested interests for consensus. He stated that a set of international profiles is desirable but not likely.

Several participants noted that national laws may also have an effect on the develop-ment of international profiles and on the prospects for international harmonization. Two areas were pointed up, export restrictions and encryption mechanisms. It was noted that export licenses are possible for B3 and higher products, but that this restriction was still burdensome. Until these issues are clearly resolved among national governments, and especially the cryptologic authorities, there is little prospect for international trade in high-security computing devices.

The issue of including encryption technology in evaluatable products arose. It was observed by several that there is little prospect for network or distributed security without encryption. There was a discussion whether the criteria were to be expanded to include evaluation of encryption devices. One evaluator said that what one does to eval-uate encryption devices and algorithms is much different than what is described in any public criteria. It was pointed out that evaluation of products which contain an imple-mentation of encryption mechanisms was different from evaluating the mechanisms themselves, which must be considered separately by cryptologic authorities. The quality of the implementation or the need for it are properly subject to IT security evaluation, while the encryption techniques themselves are not. It was clear that this is still a fuzzy issue which needed to be tackled by the national authorities.

2. Phase-in to Harmonization

The key discussion points about the process of achieving harmonization were:

a. What Should be the Steps to Harmonization?

The Editorial Board members and others pointed out that the North American and Euro-pean governments' planned steps are already becoming somewhat clear, even though detailed planning work has not yet been done. (At the time of the workshop, the Edito-rial Board had not yet met.) The role of the Editorial Board to come into agreement on the structure of the aligned criteria and to orchestrate its creation was discussed.

Internationally representative technical groups of security experts will be used to support the work, although their specific roles in the project have not yet been estab-lished. Technical support groups will work alongside the Editorial Board and will be tasked to do specific things. This covers whatever needs to be done-writing, research, etc. This brings in an opportunity for broader representation. The technical support groups do not have to be exclusively composed of government employees or contractors of the various countries, some could be from the user community or supplier commu-nity. There are no ground rules yet.

One question arose as to whether technical groups could be used to capture and refine commonly seen protection profiles, security targets, or functionality classes that have been created under the ITSEC or FC. It was agreed this would be a valid use of tech-nical groups and an especially productive place for suppliers and users. However, some of the Editorial Board members pointed out that the Board has a very short time in which to operate, and that it would be better to concentrate on developing the tools for building the profiles rather than on developing the profiles themselves. There could be some parallel effort, but there is a work factor.

In discussing the role of the Editorial Board, the notion of a common core of tools arose. One observer stated that this workshop has already had an impact on the underlying assumptions and semantic differences-it is becoming ever more clear that the issues are semantic more than differences in what we are trying to do. We have six agencies from five countries represented on the Editorial Board, all who have the same problem to solve. They have all tried individually to solve the problem. It appears that we can draw the circle quite large around the requirements of the various IT security constitu-encies to include them all.

b. How Should Users & Suppliers Proceed during Convergence?

One supplier representative suggested that research on market segments found that most users needed essentially the same things. Therefore there should not be that many different protection profiles, regardless of harmonization. The governments want to buy Commercial Off-the-Shelf (COTS) products. He felt that no supplier is going to produce four different multi-level products for government use. Perhaps there will be a high one and a low one-two at the most. Therefore, suppliers will tend to proceed along paths they already know, to build to known requirements that have already come from govern-ments and user communities. They will, however, seek to generalize their products as much as possible, to include a wide range of security features.

Another participant stated that there still will be differences at the national level as to what is required. The coming to a set of international profiles will be a long and difficult one. Perhaps the suppliers will have to combine the more stringent requirements from the different countries to arrive at an international profile. The supplier will have to take the least upper bound. The criteria would then be in excess of requirements for each country in order to meet all requirements for each country. There would also be a problem if the requirements are in conflict with one another. He felt the cost for building to an envelope such as that would not be as great as that for going through several eval-uations.

c. How Should Backward Compatibility with National Criteria be Handled?

One point in this area that was brought up was the RAMP process. There was consensus that this process has fully demonstrated the value of the notion of development assur-ance and should be retained in future criteria. It does not yet exist in the ITSEC, although there have been discussions about including it.

d. How Does this Work on Common Criteria Relate to ISO SC27?

Several speakers noted that the long term objective of the Common Criteria project must be to fit its work into ISO and achieve an international criteria standard. In addi-tion, people noted that standardized requirements profiles for various products already are coming out of the ISO environment, witness ISO 7498-2 for security of open system interconnection. But a transition plan needs to be worked out, which may be a common criteria agreed to internationally. It was noted that ISO tends not to do original work, but to work on existing documents that have been tabled.

Other speakers identified several other related international standards activities in the IT security area in addition to ISO SC27. These include the European Computer Manufac-turers Association (ECMA) TC-36, Portable Operating System Interface for Computer Environments (POSIX), Open Software Foundation (OSF) and X/Open. There will be a difficulty converging all these with the Common Criteria effort, as the only common forum is ISO, which tends to operate slowly.

X/Open activities were described as especially germane to the Common Criteria project. X/Open is intending to define a common set of security functionality, and they intend to provide a branding scheme so that a vendor that claims compliance will be able to execute against a test suite and get a brand. There is the prospect that a large number of users may be happy with the X/Open brand as demonstration of needed security features and assurance, which will further reduce the market for evaluation. X/Open's publica-tion of security standards is temporarily on hold while they look at the implications of security services, APIs and distributed security.

Moderator Conclusions

Overview

As a result of the comments received on the first draft of the Federal Criteria, and the input of those at the Invitational Federal Criteria Workshop, it is clear that additional work needs to be done on this new criteria for information technology security. The Common Criteria Editorial Board (CCEB) has been formed to develop a common criteria based on the input from the TCSEC, ITSEC, CTCPEC, draft Federal Criteria, and the draft ISO standard on IT Security Criteria. The U.S. representatives need a complete technical proposal that represents the security needs of government agencies and industry. The purpose of the Federal Criteria project is to provide this proposal. The proposal initially will consist of the first draft of the Federal Criteria and the contents of these proceedings from the Federal Criteria Workshop. As time passes, drafts of the U.S. contribution to the Common Criteria incorporating the comments will be provided. The Common Criteria will undergo extensive external review allowing those involved in the original Federal Criteria project (both originators and reviewers) to continually provide valuable data to this process.

Major Areas of Work

The first draft Federal Criteria motivated over 20,000 comments. There were some central themes in these comments as to the needed direction to any new criteria, whether it be a U.S. Federal Criteria or an international Common Criteria. These general themes were confirmed at the invitational workshop. The result is the following list of concepts that should be addressed by NIST and NSA as they contribute to the CCEB effort to develop the Common Criteria, progressing rapidly toward a truly international informa-tion technology criteria standard.

1. Fundamental Security Principles

A section needs to be written which clarifies the security principles on which the docu-ment is based. The objectives and scope of the document need to be clarified as well.

2. Clarification of Security Components

The components presented must be recast in language that is easy to understand for the information technology expert assembling protection profiles and/or security targets. In addition, the dependencies must be clearly stated. Further, the components must be rewritten to be evaluatable and usable under procurement laws.

3. Completion of Underlying Vetting, Registration and Evaluation Concepts

The process by which a protection profile is reviewed, accepted and registered needs to be completed. Similarly, an evaluation process which uses the protection profiles must also be established, complementing the development of the Common Criteria. These two processes are essential so that both criteria and product developers know what requirements to build to and how the resulting product will be assessed in relation to those requirements.

4. Preservation of Information Technology Security Investment

Attendees clearly and strongly emphasized the importance of preserving industry investment in security based on the TCSEC, not necessarily the words of the TCSEC. This means adequately capturing the experience of the past ten years in the Trusted Product Evaluation Program (TPEP). The components, as well as the protection profiles, must allow for all current implementations of the trust principles contained in the TCSEC, its formal (and informal) interpretations, and its evolution through the TPEP process. This includes concepts such as Rating Maintenance, subsystems, appli-cations (TDI) and network components (TNI).

5. Distributed Security Issues

Information technology products of the 1990's are commonly designed to work in larger system architectures with distributed and networking services. The impact of security on these products is still under research. This research will provide both clarification of known concepts in light of distributed issues as well as new security concepts specific to distributed environments.

Specific Work Area Plans in Support of the CCEB

The immediate plans must focus on support for the Common Criteria Editorial Board. This means focusing resources on those portions of the Federal Criteria which can provide the most valuable initial contribution to the work of the CCEB along with the associated comments and recommendations on those portions. Although the preferred method would be to complete a version of the Federal Criteria based on the received comments and recommendations from the invitational workshop, it is understood that the CCEB cannot wait while that version is generated. Therefore, the Federal Criteria project plans to provide updates on appropriate sections when they are needed at the CCEB.

Application of and Response to Received Comments

The comments received on the first draft of the Federal Criteria will be an important source of information for the NIST/NSA contributions to the Common Criteria. Comments received will be used to make the necessary changes to the document. This includes both the general comments discussed here and the specific comments on the different chapters and sections of the Federal Criteria. It is planned to provide commen-tators with responses to comments provided once the resolution to them is known. In addition, commentators will be placed on the mailing list to receive the draft Common Criteria for public review and comment when it becomes available.

Resources to Complete the Work

The bulk of the work defined here will be completed by NSA and NIST personnel, with input from contracted information technology experts. However, review and input from the information technology industry as a whole will be necessary as the Common Criteria development process proceeds. It is understood that the user and vendor community will remain an important source of technical information as this project continues.

Summary

The draft Federal Criteria made a significant contribution to the field of information technology security. However, it was a first draft and substantial work would be required to complete the Federal Criteria. Instead of expending resources directly on this effort, NSA and NIST will focus on contributing the central material from the Federal Criteria, augmented by the incorporation of the many comments and recom-mendations made on it by the commentators of the draft,to the Common Criteria effort. The result will be an information technology security criteria with an international scope that will meet the needs of both U.S. government and industrial users.

APPENDIX North America and Europe Agree to Develop Common Criteria

Summary

The governments of North American and European nations have agreed to develop a "Common Information Technology Security Criteria" (CC). Participants include the European Community, Canada, and the United States.

Security criteria are needed to develop trusted information technology (IT) products that can be used to help protect important information of the government and private sectors. IT security criteria common to Europe and North America will help broaden the market for these products and further lead to economies of scale. In addition, common criteria will help achieve the goal of mutual recognition by North American and European nations of IT product security evaluations.

The effort, which is expected to begin in early Fall of 1993 and be completed in the Spring of 1994, will use the ISO Subcommittee 27, Working Group 3 draft criteria documents (Parts 1-3) as an initial framework. Specific inputs will include the Informa-tion Technology Security Evaluation Criteria (ITSEC), the Canadian Trusted Computer Product Evaluation Criteria (CTCPEC), the draft Federal Criteria for Information Tech-nology Security (FC), the experience gained to date with the ITSEC in the form of suggested improvements, the comments now being received on the draft FC document, and the results of the FC invitational workshop planned for 2-3 June 1993.

The resulting common criteria are expected to undergo extensive international review and testing by performing evaluations of "real" products against the criteria prior to being fully accepted for use within Europe and North America. When mature enough, the CC will be provided as a contribution towards an international standard to ISO Subcommittee 27, Working Group 3.

Background

The agreement grew out of a 4 February CEC-sponsored workshop in Brussels on the Federal Criteria that was attended by many European security professionals. The general European response to the workshop was that alignment of criteria between Europe and North America is now both feasible and opportune.

This idea was taken up and endorsed by the EC Senior Officials Group for the Security of Information Systems (SOG-IS) in their meeting on 11 February, clearing the way for EC participation in the work required to achieve common IT security criteria.

As a result of informal meetings held thereafter, a proposal was made to proceed with a joint project to develop common criteria. This proposal was then given preliminary approval by EC member nations and North American government senior officials.

Planned Development Procedure - The Editorial Board

Current plans call for the establishment of a six member Editorial Board (EB) consisting of three members from North America and three from Europe. The EB will be composed of senior IT security experts who have had experience designing IT security criteria and have the authority and autonomy to make decisions with regard to the contents of the CC. The EB will be requested to complete their work within a six month timeframe. The main tasks of the EB are to obtain a clear understanding of the similari-ties and differences between current criteria and to develop a first-draft CC for presenta-tion to the participating government bodies. The EB will be instructed to use the material identified above as the primary material from which to develop the CC. The CC is to represent a synthesis of the best concepts and components contained in the original material. The EB is to avoid inventing new criteria.

Technical Groups to Provide Support

The EB may establish and utilize special Technical Groups (TGs), as needed, to help develop specific technical areas of the CC. These TGs will operate under the direction of the EB for the time needed to perform their assigned tasks. They will be staffed in a representative way, in a pattern like that of the EB.

Public Review and Trial Use

Following completion of the first draft criteria, the governments involved will jointly review the CC. When they mutually determine that the CC is ready for further review by the IT security community at large, they will initiate an extensive review cycle to obtain comments from all interested parties. This cycle is expected to result in additional versions until convergence is achieved. The CC will then enter a trial period to allow the specification and evaluation of vendor offerings against the CC. Upon completion of the trial period, the CC will be revised if necessary to gain final adoption by the partici-pating governments.

Relationship to ISO International Standardization