Deference Between EAL 1-7 in Common Criteria Standard?

Question

I have a question about ISO/IEC 15408 standard: I want know if the level of evaluation is higher we can conclude that a product is safer? i.e, if we have two products, is the one which has a higher EAL by definition safer?

Answer 1

The EAL levels are:

• EAL1 - functionally tested
• EAL2 - structurally tested
• EAL3 - methodically tested and checked
• EAL4 - methodically designed, tested, and reviewed
• EAL5 - semi-formally designed and tested
• EAL6 - semi-formally verified design and tested
• EAL7 - formally verified design and tested

You can see these are increasingly rigorous, from functionally tested to formal verification. The security or safety of something isn't an absolute value, it is subjective and contextual, i.e. it depends to a great degree on what you are testing, and what you are using it for.

A "+" suffix is used commonly to indicate an augmented EAL: this includes one or more assurances in addition to the indicated base level. e.g. EAL 4+ for an OS is often seen, the additional assurances usually include Flaw Remediation components (ALC_FLR, documented and formal security flaw reporting and management procedures).

A key part of an EAL is the Security Target document, put simply this comprises a rigorous definition of functions, features and intended use, tailored for the specific hardware or software component under test (the TOE, Target of Evaluation). The EAL rating determines the extent of the testing, and the confidence that security is as claimed. You cannot simply compare EALs numerically, the number can only be properly understood in the context of the Security Target; and most importantly, that can only be understood in the context of your security requirements.

Colloquially, EAL indicates the degree to which something does what it says on the tin, you have to make sure you have the right tin ;-)

Answer 2

To answer your question: Yes and no :-)

This is going to get lengthy, and criticism against Common Criteria is often targeted against that. But it's actually quite simply once you know a few terms.

Short version: The EAL level itself is only one indicator on the security of a product. Other important factors are:

1. What is the scope of evaluation?. I.e. does the security target actually actually cover all security related functionality of the real-world product? Note that protection profiles are a tool to ensure that.
2. If the product is EAL X+ then what does the + refer to? Is a security assurance component (SAR) augmented that just requires to write some more documentation, or is it an SAR that is crucial for product security, such as AVA_VAN?

Longer explanation: If you take a look at the EAL levels: Each EAL level introduces a set of security assurance components (SARs) that must be included in the evaluation such that the EAL level is met. If you take a look into the CC documents, you can see that most assurance components are structured hierarchically, and each hierarchy introduces some additional requirements. Take for example ADV_FSP, which is about the quality and extent of the functional specification of the evaluation target:

• EAL1 requires ADV_FSP.1
• EAL2 requires ADV_FSP.2
• ...
• EAL7 requires ADV_FSP.6

ADV_FSP.1 is an "Informal functional specification", whereas ADV_FSP.2 requires in addition "Fully defined external interfaces". And this goes on and the higher hierarchies include more and more requirements.

So in general a higher EAL level implies higher security. However there are two important issues that makes things more complex:

1. The scope of the evaluation. The EAL levels imply that certain assurance components (SARs) are included. You can roughly say that assurance components define how deep and thoroughly something is tested/evaluated. Then there are also the security functional requirements (SFRs), written down in a security target. The SFRs define what is tested - together with the other chapters of a security target they describe the scope of evaluation in a security target. A famous example for some strangeness here is the operating system evaluation for Microsoft Windows XP which is evaluated on EAL4 - however if you take a look at the security target, you will find that a lot of functionality is not described in terms of SFRs and simply taken out of the target of evaluation. Like network access. Which was a major weakness in Windows XP, and common sense dictates that the Windows XP certification really doesn't mean a lot in terms of security. On the other hand this is a perfectly valid approach: You simply focus on one area where the product must be secure, but other areas are out of scope. So you could have vendor A which is a bit more honest and ensures that his whole product is subject to evaluation but is only evaluated to say EAL2, and you could have vendor B which only evaluates a tiny fraction of his product but complies to EAL4. Then vendor Bs product is not necessarily better.

Protection profiles are targeting exactly this problem, as they describe a product in terms of a fixed set of SFRs and/or EAL level. If the security target of a product evaluation is than conformant to that protection profile, you know that the scope of the evaluation is at least as broad as described in the protection profile, and the above example of vendor A and B would simply be impossible if a suitable protection profile existed and both would ensure their products would be in conformance to that protection profile.

2. Augmenting Security Assurance Components (EAL X+). The other answer already mentioned ALC_FLR (documented and formal security flaw reporting and management procedures). This targets software, and basically means that you must have a process in place to ensure that vulnerabilities are fixed. Another very important assurance component is AVA_VAN - vulnerability assessment. This is precisely the part where the evaluation facility will take your product apart and test for vulnerabilities :-) CC defines these relationships

• EAL1: AVA_VAN.1
• EAL2/3: AVA_VAN.2
• EAL4: AVA_VAN.3
• EAL5: AVA_VAN.4
• EAL6/7: AVA_VAN.5

One issue here is that looking a these definitions, if you want to have a high AVA_VAN level, and based on that choose and EAL level that to get say AVA_VAN.5 you would choose EAL6. However EAL6 is suitable to semi-formally verified design and tested, and that might be a complete overkill, since the development process is simply to complex and the whole product development is too costly.

So what is often done in practice is taking a lower EAL level but augmenting it with a higher AVA_VAN level. For example, in the smartcard world you will often see EAL4+ where the + refers to AVA_VAN.5. You can then be sure that the product really can't be broken, hacked/cracked easily, but still the product wasn't necessarily semiformally designed and verified. Or in other words: A product which is EAL4+/AVA_VAN.5 might be practically more secure than a product which is (plain) EAL5, since EAL5 only requires AVA_VAN.4.