Collaborative Protection Profiles and the Oracle of Delphi

We have heard a lot about this idea of “Collaborative Protection Profiles” from the CCDB/MC in the last months. They are mentioned as the most important part of the vision statement recently issued by the CCMC. This vision statement focuses on the management of those Protection Profiles and their use within the CCRA rather than on the development of such Protection Profiles.

The development of such Collaborative Protection Profiles is left to Technical Communities, but very little guidance on the objectives for the development of Protection Profiles, their content, their harmonization, and the process to analyze them has been provided so far by the CCDB/MC.

So I decided to look for ancient wisdom on the subject and went to Delphi to consult the mysterious oracle about the objectives and principles of PP development, as well as the general structure of PPs and how they should be analyzed. I got answers to my questions that I found very useful, and therefore I want to share them with you. May be the oracle should be used more extensively in the cPP development?

Here are my questions and the answers I got:

Q: Oracle, my first question is: what is a Protection Profile?

A: A protection profile is an abstract specification of the security aspects of a needed IT product. It is product independent, describing a range of products that could meet this same need. Required protection functions and assurances must be bound together in a protection profile, with a rationale describing the anticipated threats and intended method of use.

Q: When shall we develop a Protection Profile and who shall be involved in the development of Protection Profiles?

A: Consumers or producers within the Government or the private sector develop protection profiles in response to a specific need for information protection. Profile developers, or sponsors, with a unique security need could propose a protection profile for that need or, more typically, groups of sponsors having similar needs could combine to propose one profile that meets their common need. Multiple sponsors supporting a single profile is an effective way to demonstrate a larger market to potential IT product producers.

The protection profile is intended to respond to both the pull of consumer needs and to the push of advancing technology. Ultimately, the protection profile is a common reference among consumers, producers, and evaluators.

Q: In general, what should a Protection Profile contain?

A: The requirements for protection functions, development assurance, and evaluation assurance must be incorporated into a protection profile. These requirements, specified by the rated functional and assurance components, provide the basic building blocks for the definition of a protection profile. The components must be assembled into a consistent and coherent set that satisfies specific security goals of the anticipated environments of product use. The assembled components should counter expected threats, eliminate vulnerabilities, support security policies, and satisfy regulatory requirements defined in the anticipated environments of use.

Q: Can you be more specific about the evaluation assurance requirements?

A: The Evaluation Assurance Requirements section specifies the type and intensity of evaluation to be performed on an IT product developed in response to a particular protection profile. In general, for an IT product, the scope and intensity of evaluation vary with the expected threat, intended method of use, and assumed environment as defined by the profile developer in the rationale section.

Q: What are the criteria for vetting a Protection Profile and how shall a Protection Profile be validated?

A: After a protection profile has been developed by a sponsor, it must be analyzed.

The goals of protection profile analysis are to ensure the following characteristics:

1. Technical soundness. The elements of a protection profile are technically sound and reasonably balanced, considering the profile rationale (threat, usage, and environment assumptions), and the functional and assurance requirements.
2. Usefulness. IT products built to meet the requirements of a protection profile will serve a useful purpose.
3. Evaluation capability. Implementation of a protection profile’s requirements can be evaluated. Consumers, evaluators, and producers will understand how to determine that the profile requirements have been met by a specific IT product.
4. Distinctness. The protection profile is distinct, in that it does not duplicate a need adequately described by another profile.
5. Consistency. The protection profile is consistent with other profiles in form and level of detail.

Therefore, achieving profile acceptance will often require iteration as the initial profile is refined. Profile revision and analysis continues until an acceptable profile results.

Q: Can you elaborate more on “Usefulness”?

A: Consumers and producers may determine the usefulness of a profile based on different criteria. Determining the profitability of a market is clearly a producer’s responsibility. The protection profile analysis is not intended to interfere with the producer’s business decisions. Usefulness analysis relies primarily on the rationale section of the profile to express the need with respect to threat, usage and environment assumptions.

The analysis also includes an assessment of development feasibility. Protection profiles requiring research and development efforts should be identified so that the profiles will not raise expectations for near-term implementations.

Questions to be answered during the usefulness analysis might include the following: Does this protection profile address a real problem? Does this protection profile differ significantly from existing profiles, or could the needs described in this profile be met adequately by another existing profile? If the demand is too small to support commercial off-the-shelf products, what factors could induce producers to develop products for a niche market? Approximately how large is the demand for these products? Is the protection profile readily implementable? Is the state of technology sufficiently developed or is basic or applied research and development necessary?

Q: Can you be more specific on “Evaluation Capability”?

A: The protection profile requirements must be reviewed to ensure that IT products intended to satisfy the requirements in the protection profile are capable of being evaluated. A protection profile may be used as the basis for product development. The evaluation capability analysis of the profile can pay off by clearly defining what is expected during the evaluation process. As far as possible, requirements in the protection profile should be stated in objective terms so the producer and the evaluator will be more likely to agree on their interpretation of the requirements. If certain requirements must be stated in subjective terms, clear and explicit guidelines should be presented to explain what factors should be considered to determine whether the requirements have been met. Requirements should be simple, declarative statements and for ease of reference, requirements should be numbered or otherwise indexed. These features will help to ensure that requirements will not be overlooked, either during product design and development or during evaluation.

The oracle also indicated that beside those general principles it could provide significantly more detailed information about the functional and assurance building blocks that can be used to develop Protection Profiles. It seems that the idea of Protection Profiles developed by Technical Communities (or “groups of sponsors” as the oracle defines them) existed already in ancient times.

My mysterious ancient Delphi oracle is actually a single document. Not really from ancient Greek time, but still quite old when it comes to Information Technology and evaluations. It was published before the Common Criteria even existed!

This shows that the idea of Protection Profiles developed in a collaborative way that combine functionality and assurance requirements for specific product types has been around since quite a while – and the document most likely provides a better basis for developing Protection Profiles than any guidance the CCDB has provided so far on this subject.

Now the question to the reader: what is this “ancient” document that contains the text passages I have cited above and when was it published? 

I will send a copy of the document to the first one that provides the correct answer.

By Helmut Kurth, Chief Scientist and US Lab Director