Answer to 1. The table gives an overview of which security assurance components (SARs) are included (must be included) to meet a certain EAL level. Suppose you are writing a security target or protection profile targeting EAL4. Then you take a look at the column for EAL4 and screen each row. The first row is for ALC_TAT, and the entry in the EAL4 column is 1. This means that for EAL4, the assurance component ALC_TAT.1 will be included in the evaluation process. If you want to know what that means for the product developer and the evaluator, you can scroll down to page 151.
Among other actions, the developer has to ensure this for example:
ALC_TAT.1.1D The developer shall provide the documentation identifying each development tool being used for the TOE (target of evaluation, i.e. product).
The evaluator has to also do things, like for example:
ALC_TAT.1.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
Including ALC_TAT.1 means that also all dependencies must be included as well. ALC_TAT.1 has a dependency on ADV_IMP.1, for example. An EAL level makes sure that all dependencies are met and everything is consistent including all potential circular dependencies. For example if you take a look back in the row ADV_IMP and column EAL4 you see a 1, i.e. ADV_IMP.1 must be included as well. Thus the dependency is met.
Note that SARs are stacked hierarchically, where each hierarchy level adds some more requirements. One can also "overachieve" the EAL level. For example including ALC_TAT.2 instead of ALC_TAT.1 would mean for the developer:
ALC_TAT.2.3D The developer shall describe and provide the implementation standards that are being applied by the developer.
When you include SARs that are not needed/higher than a predefined EAL level, one usually adds a + at the end. For example EAL4+ could be EAL4 but ALC_TAT.2 instead of .1, as well as all dependencies that are introduced by ALC_TAT.2 but are not required for ALC_TAT.1. In this case, the depencies for ALC_TAT.2 and ALC_TAT.1 are exactly the same, namely only ADV_IMP.1.
Answer to 2. The PP includes the security functional requirement component (SFR) FCS_CKM.1 . This component is defined in part 2 in CC in the chapter Class FCS: Cryptographic support. FCS_CKM is the family, then the component is leveled into 1, 2, 3, and 4. If you include FCS_CKM.1, then the only subcomponent is FCS_CKM.1.1, and hence this is included in the PP. This leveling and subdividing components is similar to the approach for security assurance components (SARs), defined in part 3. But don't mix
- SFRs (describing requirements on what is subject to evaluation in the product) with
- SARs (describing the depth/extent of the evaluation of the security functionality described by the SFRs).
Answer to 3. A protection profile is a description of the target of evaluation together with a fixed combination of SARs and SFRs, where all dependencies among these are met. The set of SARs could be
- implicitly defined by just choosing one EAL level - then the set of SARs is defined by the table you mentioned in your first question.
- The set of SARs could also be different, for example choosing an EAL level and augmenting the EAL level with additional SARs, or
- simply directly choosing a set of SARs which are consistent.
Approach 3 is used in the protection profile you refer to. If you take a look at the table you mentioned in your first question and the list of SARs in the referred protection profile, you can see that not all SARs that are needed for EAL1 are included. So looking at this from a EAL level, this PP is EAL0+, where the + is ADV_FSP.1, AGD_OPE.1, AGD_PRE.1, ATE_IND.1, AVA_VAN.1, ALC_CMC.1, ALC_CMS.1.
This is the general approach with PPs. As mentioned, collaborative PPs don't adhere to the predefined sets of EALs and usually define their own sets/combinations of SARs in one PP with ignoring the preset EAL levels. This has advantages and disadvantages: The cPP approach allows to leave out SARs that are not relevant for the specific product type/industry segement, or are difficult to meet due to involved costs. From an end-users perspective the disadvantage is that you have to know the underlying cPP and involved SARs to assess whether the product is actually secure. Whereas in the standard approach you know that for say, EAL level 4 you will always have a thorough vulnerability assessment (AVA_VAN.3 or higher).
The result is that in practice the cPP approach is usually used mostly for low-security products (some kind of "network device") where the product-development cycles are short, whereas high-security products with a longer development cycle often still fix an EAL level (i.e. typical smartcard chips are usually EAL5 or higher).
