PP‐Module TOE Requirements - commoncriteria/pp-template GitHub Wiki

Updated 21 March 2024

This section contains Security Requirements that apply to all Base PPs of a PP-Module. For some reason, it is organized very differently than the same section in Protection Profiles.

It is organized into five or six sections by type of requirement:

  • Mandatory SFRs: <man-sfrs>
  • Mandatory SARs (optional): <mod-sars>
  • Optional SFRs and Optional SARs: <opt-sfrs>
  • Selection-based SFRs: <sel-sfrs>
  • Objective SFRs: <obj-sfrs>
  • Implementation-dependent SFRs: <impl-dep-sfrs>

The tags must appear in this order. If there are no SFRs for a section, use an empty tag (e.g. <opt-sfrs/>). If there are no SARs, the <mod-sars> tag can be omitted.

Because the requirements are organized by "status," there is generally no need to set the status attribute of the <f-component> or <a-component> tags. But a requirement can be, for example, both selection-based and optional. For guidance on where to place such requirement and how to indicate their status, see the following wiki entries:

In the unlikely event that a PP-Module includes an Optional SAR, this is indicated by including the Optional SAR in the Optional SFR section--not in the Mandatory SARs section. This is because of implementation decisions made long ago. It would be surprisingly difficult to specify optional SARs in the SAR section and display them in the Optional SFRs section. It's just not worth the effort for something that is unlikely to come up.

SFR Sections (<man-sfrs>, <opt-sfrs>, <obj-sfrs>, <sel-sfrs> <impl-dep-sfrs>)

Each SFR section should begin with an audit table. See Audit Tables. As it true for SFRs the world over, if they are Extended Components, then the ECD information must be included. For example:

   <impl-dep-sfrs>
     <section id="sib-audit-table" title="Auditable Events for Implementation-Dependent SFRs">
       <audit-table id="at-feat-based" table="feat-based">
         <h:br/><h:b><ctr ctr-type="Table" pre="Table " id="atref-implbased">
            : Auditable Events for Implementation-Dependent SFRs</ctr></h:b>
       </audit-table>
     </section>
	  
     <section title="User Data Protection (FDP)" id="ib-fdp">
	<ext-comp-def title="Subset Information Flow Control" fam-id="FDP_VPX_EXT">
	    <fam-behavior>Components in this family describe the requirements that pertain to IP traffic and information flow
	       through the VPN client.</fam-behavior>
	</ext-comp-def>
    
        <f-component cc-id="fdp_vpx_ext.1" id="fdp-vpx-ext-1" name="Split Tunnel Prevention">
	      <depends on="feat-one"/>
                    .
                    .
        </f-component>
                    .
                    .
     </section>
    </impl-dep-sfrs>

SAR Section

PP-Modules seldom add SARs, and the SARs of the Base PP are used in an evaluation. If the <mod-sars> tag is omitted, then the whole issue of SARs is ignored. If an empty <mod-sars/> tag is provided, then a "TOE Security Assurance Requirements" section is auto-generated containing the following text:

This PP-Module does not define any Security Assurance requirements. The SARs from the Base-PP must be satisfied.

If the <mod-sars> tag includes at least one <a-component> tag, then the section is generated and it is filled with the SARs. See Security Assurance Requirements.

Optional SARs are not specified in this section. They should appear in the <opt-sfrs> section. Don't ask.

⚠️ **GitHub.com Fallback** ⚠️