collaborative PP-Module for Agent Applications

Acknowledgements

This collaborative Protection Profile Module (PP-Module) was developed by the iTC for Application Software international Technical Community (iTC) also known as AppSW-iTC with representatives from industry, Government agencies, Common Criteria Test Laboratories, and members of academia.

Revision History

Table 1. Revision history
Version	Date	Description
1.0	2022-04-06	Initial Release
1.0e	2023-02-15	Incorporated feedback received following initial release.
2.0	2026-07-21	Draft-review updates.

Table of Contents

Acknowledgements
- Revision History
Preface
1. PP-Module Introduction
2. CC Conformance Claims
- 2.1. Components allowed with this cPP in a PP-Configuration
3. Security Problem Definition
4. Security Objectives
- 4.1. Security Objectives for the TOE
- 4.2. Security Objectives for the Operational Environment
5. Security Functional Requirements
6. Security Assurance Requirements
Appendix A: Selection-Based Requirements
Appendix B: Optional Requirements
Appendix C: Extended Component Definitions
- C.1. Communication Partner Control (FCO_CPC_EXT)
  - C.1.1. Family Behaviour
  - C.1.2. Component Levelling
Appendix D: Consistency Rationale
- D.1. Consistency of TOE Type
- D.2. SFR Dependencies Analysis

Preface

This module is part of a Collaborative Protection Profile (cPP) whose Target of Evaluation (TOE) is software applications. Under this cPP software applications can be categorized under the following broad categories:

Agent Applications

This cPP-Module is to be used against which all of the above categories of software applications may be evaluated. In addition there are PP-Modules that may be applicable based on the category of application.

In addition to the above categories there are large number of applications (Desktop and Mobile) that fall under “Consumer-grade” category. While such applications could be evaluated under the Application Software cPP, it is not the intention of this iTC to specifically address this category. The iTC doesn’t believe the consumer grade app ecosystem would support the historical cost and timelines associated with a Common Criteria evaluation.

Objectives of Document

This document presents the Common Criteria (CC) collaborative Protection Profile Module (PP-Module) to express the security functional requirements (SFRs) and security assurance requirements (SARs) for Agent Applications. The Evaluation activities that specify the actions the evaluator performs to determine if a product satisfies the SFRs captured within this PP-Module, are described in [SD].

Scope of Document

The scope of the PP-Module within the development and evaluation process is described in the Common Criteria for Information Technology Security Evaluation. In particular, a PP-Module defines the IT security requirements of a generic type of TOE and specifies the functional security measures to be offered by that TOE to meet stated requirements [[CC1], Section B.14].

Intended Readership

The target audiences of this PP-Module are developers, CC consumers, system integrators, evaluators and schemes.

Although the PP-Module and SD may contain minor editorial errors, the PP-Module is recognized as living document and the iTC is dedicated to ongoing updates and revisions. Please report any issues to the AppSW-iTC.

1. PP-Module Introduction

1.1. PP-Module Reference Identification

PP-Module Reference: collaborative PP-Module for Agent Applications
PP-Module Version: 2.0
PP-Module Date: 2026-07-21

1.2. TOE Overview

1.2.1. Compliant Targets of Evaluation

This is a Collaborative Protection Profile (cPP) Module whose Target of Evaluation (TOE) is Agent Applications. This PP-Module is compatible with the cPP for Application Software and collaborative PP-Module for Server Applications.

For purposes of a PP-Configuration, an Agent Application is any TOE Component whose deployed TOE Component Instances communicate with instances of another TOE Component under the control, coordination, policy, enrollment, or trust relationship established by the TOE. This may include endpoint agents, worker services, peer services, microservice payloads, subordinate application services, or other application components that are identified as TOE Components in the ST.

The terms Server Application and Agent Application describe TOE Component roles for purposes of a PP-Configuration. They do not imply network client/server directionality, hosting relationship, privilege model, deployment topology, or that communication is initiated by one role rather than the other. A TOE Component may perform one or both roles if identified in the ST.

For containerized or microservices TOEs, the TOE consists of the application payload components identified in the ST. The container orchestration platform, container runtime, host operating-system kernel, platform-provided operating-system services or userland not delivered as part of a TOE image, service mesh infrastructure, ingress infrastructure, cluster networking, platform-provided secret or configuration stores, managed runtimes, and application frameworks are part of the operational environment unless explicitly included in the TOE boundary. Vendor-delivered executable content in a TOE image remains subject to the base cPP’s TOE-boundary and composition rules.

1.3. TOE Use Cases

All use cases of Agent applications defined in the Collaborative Protection Profile for Application Software are applicable to this PP-Module.

1.4. Distributed and Microservices TOE Configurations

This PP-Module may be used in a PP-Configuration with the PP-Module for Server Applications to evaluate distributed application software. Distributed application software includes server-agent deployments, clustered server deployments, and microservices architectures composed of multiple application payload components.

The ST shall identify each Agent Application TOE Component, describe the role of each TOE Component, identify which claimed SFRs are implemented by each TOE Component, and describe all distinct Communication Relationship Types involving Agent Application TOE Components, including a relationship between instances of the same TOE Component where applicable. Repeated relationships may be represented using an unambiguous topology pattern rather than by enumerating every TOE Component Instance pair. The ST shall also distinguish TOE Components and their instances from operational environment components. If the TOE relies on operational environment components for execution, scheduling, networking, isolation, credential storage, configuration storage, time services, or protection of intra-TOE communications, the ST shall identify the dependency and the guidance shall describe the required environmental configuration.

For a TOE application payload executing in a Linux container, an EA whose subject is behavior of the running payload shall use the Linux-specific method defined by the base cPP and Supporting Document. This does not satisfy or make inapplicable an activity whose subject is the container image or update artifact, installation or update workflow, runtime or orchestrator configuration or dependency, or an externally exposed interface or channel; each such activity shall be performed at the artifact, platform, lifecycle, interface, or channel layer stated by the activity. An operational-environment service may satisfy a claimed SFR only where that SFR expressly permits platform-provided functionality.

The ST need not iterate an SFR solely because it is allocated to more than one TOE Component. A single completion of the SFR, including one iteration when needed, and a common TSS description may be mapped to multiple TOE Components or Communication Relationship Types when the operations and claimed security-relevant behavior are the same. The ST shall identify all mapped TOE Components and Communication Relationship Types and shall use separate iterations when different operations are needed to express the claims.

For evaluation, named SFR Implementation Instances used by mapped TOE Components and identified security-relevant configurations, where applicable, may be placed in Component Implementation-Equivalence Classes as specified in the Supporting Document. A class may list multiple SFR iterations and implementation-specific portions of Evaluation Activities when its member SFR Implementation Instances and equivalence basis are identical for the listed scope. Interfaces and communication relationships remain separate coverage targets. Class membership does not change SFR applicability: every TOE Component to which an SFR applies shall satisfy it, and every TOE Component Instance shall exhibit the claimed behavior of its TOE Component in its identified configuration. Component implementation equivalence within one distributed TOE is distinct from Product Equivalence and Platform Equivalence under the base-PP equivalency guidance.

2. CC Conformance Claims

As defined by the references [CC1], [CC2] and [CC3], this PP-Module:

conforms to the requirements of Common Criteria CC:2022, Revision 1,
is Part 2 extended,
does not claim conformance to any other security functional requirement packages.

In order to be conformant to this PP-Module, a ST shall demonstrate Exact Conformance. Exact Conformance, as a subset of Strict Conformance as defined by the CC, is defined as the ST containing all of the SFRs in Security Functional Requirements (these are the mandatory SFRs) of this PP-Module, and potentially SFRs from Consistency Rationale (these are selection-based SFRs) and Selection-Based Requirements (these are optional SFRs) of this PP-Module. While iteration is allowed, no additional requirements (from the CC parts 2 or 3, or definitions of extended components not already included in this PP-Module) are allowed to be included in the ST. Further, no SFRs in Security Functional Requirements of this PP-Module are allowed to be omitted.

2.1. Components allowed with this cPP in a PP-Configuration

The list of packages, PP-Modules and cPPs that may be used in conjunction with this Module can be found at: https://appswcpp.github.io/cPP/AppSW_cPP_allowed-with-list.pdf

3. Security Problem Definition

The security problem is described in terms of the threats that the TOE is expected to address, assumptions about its operational environment, and any organizational security policies that the TOE is expected to enforce.

3.1. Threats

3.1.1. T.UNTRUSTED_COMMUNICATION_CHANNELS_AGENT

Attackers may take advantage of poorly designed or non-secure protocols or poor key management to successfully perform man-in-the middle attacks, replay attacks, etc. Successful attacks will result in loss of confidentiality and integrity of the critical network traffic, and potentially could lead to a compromise of the application itself. Attackers may attempt to target applications that do not use standardized secure tunneling protocols to protect the critical network traffic. This threat is of particular concern when an application uses protocols that have not been subject to extensive peer review. Additionally attackers may attempt to connect via untrusted entities and use that connectivity to perform various attacks.

SFR Rationale:

FCO_CPC_EXT.1 SFR ensures that only trusted entities connect with each other.
FTP_DIT_EXT.1 in the Collaborative Protection Profile for Application Software ensures that communication between TOE Component Instances is protected using well known protocols.

3.2. Assumptions

All Assumptions of the Collaborative Protection Profile for Application Software apply also to this PP-Module.

3.3. Organizational Security Policies

There are no OSPs for applications.

4. Security Objectives

4.1. Security Objectives for the TOE

All Objectives of the Collaborative Protection Profile for Application Software apply also to this PP-Module.

4.2. Security Objectives for the Operational Environment

All objectives for the Operational Environment of the Collaborative Protection Profile for Application Software apply also to this PP-Module.

5. Security Functional Requirements

5.1. Conventions

The individual security functional requirements are specified in the sections below. The following conventions are used for the completion of operations:

[Italicized text within square brackets] indicates an operation to be completed by the ST author.
Bold text indicates additional text provided as a refinement.
[Bold text within square brackets] indicates the completion of an assignment.
[text within square brackets] indicates the completion of a selection.
Number in parentheses after SFR name, e.g. (1) indicates the completion of an iteration.
'/Agent' has been added to every SFR in this module, except FCO_CPC_EXT.1, to distinguish SFRs added from Server modules.

Extended SFRs are identified by having a label “EXT” at the end of the SFR name.

5.2. Communication (FCO)

5.2.1. FCO_CPC_EXT.1

Administrative pairing enablement, registration, permitted communication, and disablement

Figure 1. Illustrative FCO_CPC_EXT.1 communication-pairing lifecycle

FCO_CPC_EXT.1.1 The TSF shall require a Security Administrator to enable a permitted communication pairing before communication governed by that pairing can take place. Each endpoint identity shall represent either an unambiguous set of one or more TOE Component Instances of one TOE Component that share a TOE Component identity, including any Runtime Replicas, or one separately managed TOE Component Instance.

FCO_CPC_EXT.1.2 The TSF shall implement a registration process in which TOE Component Instances represented by an enabled communication pairing establish and use a communications channel that uses [selection:

a channel protected according to FTP_DIT_EXT.1,
no channel

].

Application Note 1: A communication pairing is the administrative control object for a permitted relationship, while communication is realized between the TOE Component Instances represented by its endpoint identities. Either endpoint identity may represent an unambiguous set of one or more TOE Component Instances of one TOE Component that share a TOE Component identity, including any Runtime Replicas, or one separately managed TOE Component Instance, so a pairing may use either model at each endpoint. A control applied to a shared TOE Component identity applies to every instance represented by that identity and permitted topology; it need not enumerate each Runtime Replica. The TSF may disable a pairing directly or by disabling an endpoint identity, provided the result prevents all communication authorized solely by that pairing. The ST shall describe the administrative-identity model, the set of TOE Component Instances represented by each endpoint identity, and the effect of disabling a pairing or endpoint identity. It shall map each pairing to its Communication Relationship Type or Types and every applicable identity model. In a microservices architecture, a pairing may govern communication between application payload services having Server Application, Agent Application, or other roles identified in the ST. Protection of data transmitted between TOE Component Instances is addressed by FTP_DIT_EXT.1 in the base cPP. "No channel" is selected if the registration is performed via out-of-band manual means.

Application Note 2: A registration channel protected according to FTP_DIT_EXT.1 may be used over any untrusted network. This PP-Module makes no assumption that the registration network is trusted.

FCO_CPC_EXT.1.3 The TSF shall enable a Security Administrator to disable any enabled communication pairing.

5.3. Protection of the TSF (FPT)

This PP-Module does not define separate FPT_ITT requirements. Protection of data transmitted between TOE Component Instances is addressed by FTP_DIT_EXT.1 in the base cPP.

6. Security Assurance Requirements

This PP-Module does not define any additional assurance requirements above and beyond what is defined in the Collaborative Protection Profile for Application Software that it extends. Application of the SARs to the TOE boundary described by both the claimed base and this PP-Module is sufficient to demonstrate that the claimed SFRs have been implemented correctly by the TOE.

Appendix A: Selection-Based Requirements

There are currently no Selection-Based requirements. This section may be applicable in later revisions.

Appendix B: Optional Requirements

There are currently no Optional requirements. Following section may be applicable in later revisions.

Appendix C: Extended Component Definitions

This appendix contains the definitions for the extended requirements that are used in the PP-Module, including those used in Consistency Rationale and Selection-Based Requirements .

C.1. Communication Partner Control (FCO_CPC_EXT)

C.1.1. Family Behaviour

This is a new component within the FCO class used to define high-level constraints on the ways that partner IT entities communicate. For example, there may be constraints on when communication channels can be used, how they are established, and links to SFRs expressing lower-level security properties of the channels.

C.1.2. Component Levelling

Figure 2. Component leveling

FCO_CPC_EXT.1 Component Registration Channel Definition requires the TSF to support a registration channel for TOE Component Instances represented by an administrator-enabled communication pairing and to ensure that each pairing can be disabled by an Administrator. It also requires a statement of whether the channel is protected according to FTP_DIT_EXT.1 or established through an out-of-band manual process.

Management: FCO_CPC_EXT.1

The following actions could be considered for the management functions in FPT:

There are no management activities foreseen

Audit: FCO_CPC_EXT.1

The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST:

Enabling a communication pairing as in FCO_CPC_EXT.1.1, including each endpoint identity and whether it represents a set of one or more TOE Component Instances sharing a TOE Component identity or one separately managed TOE Component Instance.
Disabling a communication pairing as in FCO_CPC_EXT.1.3, including the endpoint identities and whether the pairing or an endpoint identity was disabled.

FCO_CPC_EXT.1

Hierarchical to: No other components

Dependencies: No other components