Notes on Security and Common Criteria

(modified from the July 23 2004 original).

I’m considering making a translation of the Common Criteria into English.

Native CC Dialect. The PP describes implementation-independent sets of security requirements for categories of TOEs, and contains a statement of the security problem that a compliant product is intended to solve. It specifies CC functional and assurance requirements components (including an EAL), and provides a rationale for the selected functional and assurance components.

Here’s the translation.

AFL – Acronym Free Language.

A Protection Profile is a security specification for a class of programs doing the same type of work. Profiles must:

• Clearly describe the security problem that compliant programs are supposed to solve;
• Specify security functions that must be provided by compliant programs (such as trace and encryption);
• Specify the level of rigor required to certify a program as compliant;
• Include an explanation of why those particular security functions and no others were selected, and why the selected level of rigor is good enough

Developers are asked to answer four questions. The first one is “what must be secured”? That’s generally not an easy question to answer. The second question covers the mechanisms that the software must provide for assuring the required security. The obvious temptation and most common error is to confuse the first and second questions: to muddle up what with how.  For example, the fundamental problem with MILS is that it specifies “hardware memory protection” as the answer to both questions. The third question is “how do you validate that your security mechanisms actually provide the required security.” This is a much overlooked question and even trying to answer it can reveal serious problems. The standard answer is something like “use such and such a process for development and provide documents that show you have used this process”. Since there is absolutely no data showing that process implies anything about quality, that’s a weak support. Let’s move on to the final question (easier than providing a good answer to the third question). The final question is also great: “why are these methods of assuring security both necessary and sufficient and why do you need this level of validation?”

Stripped of nonsensical jargon, the Common Criteria is demanding a clear analysis. Are there any working examples of such an analysis?