Skip to content

Requirements Direction for Base PP

Jump to bottom
Bob Clemons edited this page Mar 11, 2024 · 7 revisions

Updated 11 March 2024

PP-Modules must declare at least one Base PP for them to be in a configuration with. For some reason, this is called a "Security Functional Requirements Direction." The structure in XML is as follows:

  • Base-PP Declaration and Reference (<base-pp>, <git>, <url>, and <branch>)
    • SFR Direction (<sec-func-req-dir>)
    • Modified SFRs (<modified-sfrs>)
    • Additional SFRs (<additional-sfrs>)
    • Consistency of TOE Type (<con-toe>)
    • Consistency of Security Problem Definition (<con-sec-prob>)
    • Consistency of Objectives (<con-obj>)
    • Consistency of Operational Environment Objectives (<con-op-en>)
    • Consistency of Requirements (<con-mod>)

Base-Specific Requirements

Base PP Declaration and Reference

Base PPs are declared using the <base-pp> element. The published documents are referenced using the <url> and <branch> tags as follows:

    <base-pp id="bpp-mdf"                                                # unique ID within this document
             name="Protection Profile for Mobile Device Fundamentals"    # Full name of Base PP
             short="mdf"                                                 # short name of Base PP
             product="Mobile Device"                                     # Base PP Product
             version="3.3">                                              # Base PP version

      # Reference to Github repo of Base PP. 
      # If there is none, then this is omitted
      <git>
	<url>https://github.com/commoncriteria/mobile-device</url>       # URL of base PP github repo 
	<branch>release-3.3</branch>                                     # Github branch of release version 
      </git>

      # URL of Base PP on the NIAP website
      <url>https://www.niap-ccevs.org/Profile/Info.cfm?PPID=417&amp;id=417</url>

Security Functional Requirements Direction

The contents of the <sec-func-req-dir> tag appears under the "Direction" heading for the Base PP.

  <sec-func-req-dir>
      In a PP-Configuration that includes the MDF PP, the VPN client is expected to rely on some of the
      security functions implemented by the OS as a whole and evaluated against the Base-PP.
      In this case, the following sections describe any modifications that the ST author must make to the SFRs
      defined in the Base-PP in addition to what is mandated by section 5.5.
  </sec-func-req-dir>

Modified SFRs

The Modified SFRs section contains SFRs that appear in the Base PP, but are modified when the Base PP is in a configuration with the PP-Module. Ideally, each SFR should be fully reproduced in this section. It is, however, possible to write abbreviated SFRs that discuss only the differences.

Unlike in PPs, Sections are not automatically generated for Families for Modified SFRs. So these must be manually generated:

    <modified-sfrs>
       <section title="Identification and Authentication (FIA)" id="md-m-fia">    
          # Modified SFRs from the FIA Family
       </section>
       <section title="Security Management (FMT)" id="md-m-fmt">    
          # Modified SFRs from the FMT Family
       </section>
            .
            .
    </modified-sfrs>

It's particularly important to make sure the id attributes for these sections and SFRs are unique in the document, since there is likely to be more than one instance of each Family in the document.

Since these SFRs already appear in the Base PP, there is no need to provide ECD information for extended components.

Currently, the Modified SFRs section does not support audit events. You can attach audit events to the SFRs, but they will not be displayed anywhere.

If there are no Modified SFRs for a Base PP, use an empty <modified-sfrs/> tag.

See also, Components

Additional SFRs

An SFR should be classified as "additional" if the requirement applies when the Base PP is in a configuration with the PP-Module, yet that exact requirement does not apply all Base PPs that the PP-Module may be in a configuration with. If the same requirement applies to all Base PPs, then it should be in the TOE Requirements section.

By default, all SFRs in the "Additional SFRs" section are considered mandatory. But if a requirement should be "optional" or something else, simply set the status attribute of the <f-component> to the appropriate value. In the published document, the SFR will still appear in the Additional SFRs section, but it will have a heading indicating that it is optional, selection-based, or whatever.

For additional guidance on classifying SFRs, see here and here

The Additional SFRs section is constructed the same as the Modified SFRs section, with a couple of exceptions. First, this section supports having an Audit Table, but it must be manually included in the XML. Second, Additional SFRs can be extended components, so the appropriate Family Behaviors and ECD information should be included with the Families and Components.

    <additional-sfrs>
	<!-- Audit table for Additional SFRs -->
        <section id="sec-at-os-addnl" title="Auditable Events for GPOS Additional SFRs">
        	<audit-table id="at-os-addnl" table="tab-at-os-addnl" title="Auditable Events for GPOS Additional SFRs"/>
        </section>	

        <section title="Cryptographic Support (FCS)" id="os-a-fcs">
          <ext-comp-def title="Cryptographic Key Management" fam-id="FCS_CKM_EXT">
            <fam-behavior>Components in this family describe requirements for key management functionality such as key
		storage and destruction.</fam-behavior>
            </ext-comp-def>
          # Additional SFRs from the FCS Family
        </section>

        <section title="Security Management (FMT)" id="os-m-fmt">    
          # Additional SFRs from the FMT Family
        </section>
            .
            .
    </additional-sfrs>

If there are no Additional SFRs for a Base PP, use an empty <additional-sfrs/> tag.

See Components and Classes and Familiies

Consistency Rationale

CC:2022 Part 1 C.2.2.3 describes a Consistency Rationale that is required for each Base PP supported by the PP-Module.

The consistency analysis for each PP-Module Base shall be performed on the TOE type, the SPD, the objectives, and the SFRs. At the end, the goal is to demonstrate that a TOE can meet the TOE type descriptions provided in the PP-Module Base and in the PP-Module and satisfy all the SFRs specified in the PP-Module and its PP-Module Base. The consistency rationale shall demonstrate that the unions of SPDs, objectives, and SFRs defined in the PP-Module and in its PP-Module Base do not lead to a contradiction.

In NIAP PP-Modules, the Consistency Rationale is a separate section that appears after all the SFRs and SARs. It is auto-generated from information provided in the <base-pp> element under the following tags:

Consistency of TOE Type: <con-toe>

The contents of this tag appear in the "Consistency of TOE Type" section. For example:

      <con-toe>If this PP-Module is used to extend the MDF PP, the TOE type for the overall TOE is still a mobile device.
		The TOE boundary is simply extended to include VPN client functionality that is built in to the device’s
		software so that additional security functionality is claimed within the scope of the TOE.  
      </con-toe>

Consistency of Security Problem Definition: <con-sec-prob>

The contents of this tag appear at the introduction to "Consistency of Security Problem Definition" table for the Base PP. The table is auto-generated from information pertaining to Threats, Assumptions, and Operational Security Policies in the <con-mod> tags below.

      <con-sec-prob>The threats and assumptions defined by this PP-Module (see sections 3.1 and 3.2) supplement those
		defined in the MDF PP as follows: 
      </con-sec-prob>

Consistency of Objectives: <con-obj>

The contents of this tag serve to introduce the "Consistency of Objectives" table for this Base PP. The Table is auto-generated from the Objectives in the <con-mod> tags below.

      <con-obj>The security objectives defined by this PP-Module (see sections 4.1 and 4.2) supplement those defined
		in the MDF PP as follows:
      </con-obj>

This section may be omitted for Direct Rationale documents. If it is not omitted, it is ignored.

Consistency of Operational Environment Objectives: <con-op-en>

The contents of this tag serve to introduce the "Consistency of OE Objectives" table for this Base PP. The Table is auto-generated from the Operational Objectives in the <con-mod> tags below. This table appears in the same subsection as the above "Consistency of Objectives," so it is not necessary to provide introductory text and the tag can be left empty.

      <con-op-en></con-op-en>

The <con-mod> tag

The <con-mod> tag references the id of a Threat, Assumption, OE Assumption, Objective, OE Objective, or SFR; and associates text with the _id. This information is presented in auto-generated tables in the Consistency Rationale section for each Base PP of the PP-module, as described above.

  • Threats and Assumptions are presented in the "Consistency of Security Problem Definition" table.
  • Security Objectives are presented in the "Consistency of Objectives" table. Except Direct Rationale PPs and PP-Modules.
  • Operational Environment Objectives are presented in the "Consistency of OE Objectives" table.
  • SFRs are presented in the "Consistency of Requirements" table.

Some examples:

     <!-- Consistency of Security Problem Description -->
      <con-mod ref="T.UNAUTHORIZED_ACCESS">The threat of an attacker gaining access to a network interface or data
		that is transmitted over it is consistent with the T.NETWORK and T.EAVESDROP threats in the MDF PP.</con-mod>
      <con-mod ref="A.TRUSTED_CONFIG">This assumption is consistent with the MDF PP because the MDF PP
		includes the A.CONFIG assumption which assumes that all security functions are appropriately configured.
      </con-mod>
	
      <!-- Consistency of Objectives -->
      <con-mod ref="O.KNOWN_STATE">This objective is consistent with the O.INTEGRITY objective of the
		MDF PP, which expects a conformant TOE to implement measures to maintain its own integrity.</con-mod>
      <con-mod ref="OE.NO_TOE_BYPASS">This objective addresses behavior that is out of scope of the MDF PP
		and does not define an environment that an MDF TOE is incapable of existing in.</con-mod>

Direct Rationale PPs and PP-Modules do not have Security Objectives, so obviously there would be no <con-mod> entries for Security Objectives. Operational Environment Objectives (if any) are included in this section.

Consistency of Requirements

The "Consistency of Requirements" table presents the contents of the <con-mod> tags that reference SFRs. The table is grouped into several sections:

  • Modified SFRs
  • Additional SFRs
  • Mandatory SFRs
  • Optional SFRs
  • Objective SFRs
  • Implementation-dependent SFRs
  • Selection-based SFRs

As you can see, there should be a <con-mod> tag for not only the SFRs modified and added to the Base PP by the PP-Module, but all of the SFRs in the PP-Module that apply to the Base PP. Some examples:

     <!-- Consistency of Requirements -->
      <con-mod ref="md-fcs-ckm-1">The ST author is instructed to make specific selections at minimum to
		address VPN client requirements; the SFR behavior itself is unmodified.</con-mod>
      <con-mod ref="fcs-ipsec-ext-1">This SFR defines the VPN client’s IPsec implementation, which is added
		functionality that does not interfere with the MDF functions.</con-mod>
      <con-mod ref="fdp-rip-2">The requirement to protect against re-use of residual data is a property of
		the VPN client behavior and does not impact the MDF functionality.</con-mod>
Clone this wiki locally