The scope of this PP-Module is to describe the security functionality of an Enterprise-Management product (EM) in terms of [CC]
and to define functional and assurance requirements for such products. This PP-Module is intended for use with the following Base PPs:
Protection Profile for Application Software Version 2.0
This Base PP is valid because an EM is deployed as a software application on a general-purpose operating system.
1.2 Terms
The following sections list Common Criteria and technology terms used in this document.
1.2.1 Common Criteria Terms
Assurance
Grounds for confidence that a TOE meets the SFRs [CC].
Base Protection Profile (Base-PP)
Protection Profile used as a basis to build a PP-Configuration.
Collaborative Protection Profile (cPP)
A Protection Profile developed by
international technical communities and approved by multiple schemes.
Common Criteria (CC)
Common Criteria for Information Technology Security Evaluation (International Standard ISO/IEC 15408).
Common Criteria Testing Laboratory
Within the context of the Common Criteria Evaluation and Validation Scheme (CCEVS), an IT security evaluation facility
accredited by the National Voluntary Laboratory Accreditation Program (NVLAP) and approved by the NIAP Validation Body to conduct Common Criteria-based evaluations.
Common Evaluation Methodology (CEM)
Common Evaluation Methodology for Information Technology Security Evaluation.
Direct Rationale
A type of Protection Profile, PP-Module, or Security Target in which the security
problem definition (SPD) elements are mapped directly to the SFRs and possibly to the
security objectives for the operational environment. There are no security objectives
for the TOE.
Distributed TOE
A TOE composed of multiple components operating as a logical whole.
Extended Package (EP)
A deprecated document form for collecting SFRs that implement a particular protocol, technology,
or functionality. See Functional Packages.
Functional Package (FP)
A document that collects SFRs for a particular protocol, technology,
or functionality.
Operational Environment (OE)
Hardware and software that are outside the TOE boundary that support the TOE functionality and security policy.
Protection Profile (PP)
An implementation-independent set of security requirements for a category of products.
A comprehensive set of security requirements for a product type that consists of at least one Base-PP and at least one PP-Module.
Protection Profile Module (PP-Module)
An implementation-independent statement of security needs for a TOE type complementary to one or more Base-PPs.
Security Assurance Requirement (SAR)
A requirement to assure the security of the TOE.
Security Functional Requirement (SFR)
A requirement for security enforcement by the TOE.
Security Target (ST)
A set of implementation-dependent security requirements for a specific product.
Target of Evaluation (TOE)
The product under evaluation.
TOE Security Functionality (TSF)
The security functionality of the product under evaluation.
TOE Summary Specification (TSS)
A description of how a TOE satisfies the SFRs in an ST.
1.2.2 Technical Terms
Endpoint
A computing device that runs a general purpose OS, mobile device OS, or network device OS. Endpoints can
include desktops, servers, and mobile devices.
Endpoint Detection and Response (EDR)
A system that analyzes collected EDR Host Agent data for detecting,
investigating, and remediating unauthorized activities on endpoints.
Enrolled State
The state in which an endpoint with a running Host Agent is managed by an EM.
Enrollment
The process of transitioning an endpoint from an unenrolled to an enrolled state.
Enterprise Security Management (ESM)
A type of application hosted on a server or cloud service that provides
support for security management, information flows, reporting, policy, and data analytics
in complex enterprise environments.
Host Agent
A logical piece of software that executes on endpoints to collect data about the endpoint and
executes commands sent to the endpoint from an EM server
or service. An example command sent to an endpoint could be to enforce a policy from an
EM, to collect some files, or to run an OS command.
Operating System (OS)
Software that manages physical and logical resources and provides services
for applications.
Unenrolled State
The state in which an endpoint, with or without a Host Agent, is not managed by an EM.
1.3 Compliant Targets of Evaluation
The PP-Module for Enterprise-Management (EM) is intended to support Enterprise Security Management (ESM) products that are used to manage the configuration and behavior of endpoint systems in an enterprise setting, and providing monitoring and reporting capabilities for managed endpoints. EM supports ESM by applying policies that control the security-relevant behavior of systems. An EM product is specifically a type of software application.
An EM product may control the behavior of a system directly, or it may accomplish this by interacting with an agent that resides on that system. A conformant TOE may use different protocols to communicate with external entities. If IPsec is implemented for remote communications, the TOE boundary also includes the PP-Module for VPN Client.
1.3.1 TOE Boundary
The boundary for EM includes
all processes, all modules, and libraries bundled with the product, to be run on a single server or multiple servers in a load balancing or failover configuration. This includes any local or remote management interface that is used to access the TOE for the purpose of configuration (whether of itself or of endpoints under the TOE's control), audit review, or any other supported administrative function. The TOE boundary includes communications channels with external entities. The platform operating system or execution environment
upon which the TOE is executing is outside the scope of an EM evaluation. The figure below shows a sample deployment of an EM product within its larger operational environment, including remote systems for which it is responsible for managing.
TBD.
A conformant TOE may include only EM functionality, or it may include agents within the logical boundary of the TOE. If agents are included in the logical boundary, the TOE also conforms to the PP-Module for Host Agent. Agents may also reside in the operational environment such that the TOE boundary only includes the EM functionality and its interface to remote agents is an external interface.
A conformant TOE may be isolated to a single system, or it may be distributed across multiple systems, either because the TOE's EM functionality is distributed across multiple servers, or because the TOE boundary includes agents that are remote to the server.
A conformant TOE will generally communicate with external systems (whether via agents or not) that are logically remote to the TOE. However, some use cases exist where an EM product only manages policy on a central server.
A conformant TOE may provide endpoint detection and response (EDR) capability in addition to its EM capability. If this is the case, the TOE may also claim conformance to the PP-Module for Endpoint Detection and Response.
1.3.2 TOE Platform
The TOE platform consists of a general purpose OS or an Execution Environment on top of which
the EM software executes.
1.4 Use Cases
Requirements in this PP-Module are designed to
address the security problem for the following use cases. These use cases are intentionally
very broad, as many different types of EM products may exist. As this PP-Module is revised to allow for more specific types of EM products, additional use cases
may be devised.
[USE CASE 1] Interfacing with Endpoints
The TOE communicates with an endpoint system and issues commands to this system to push, edit, or retrieve data. This could include deployment or updates to system software, applying configuration settings, executing custom scripts against the system, or establishing interactive remote access to the system.
[USE CASE 2] System Inventory
The TOE collects data about endpoint systems that can be queried or browsed. This could include data about the system's hardware, software, or configuration
[USE CASE 3] System Monitoring
The TOE has a persistent connection to endpoint systems to monitor those systems for anomalous activity, such as disk utilization, memory usage, configuration of system permissions, or the starting and stopping of executable services or processes on the system.
1.5 Implementation-Based Features
A conformant TOE may implement certain features that are not strictly necessary in order to achieve the desired level of security, but if these features are implemented, they are required to be included within the TOE boundary.
1.5.1 Agent Integration
A conformant TOE may implement policy by communicating configuration instructions to a software agent on a system rather than through direct interaction with the system itself. An agent may reside locally on the same system as the TOE or may be remote. If the product is integrated with agents, the agents must be included in the TOE boundary. It is possible that agents are a separate "product" and are in the TOE's operational environment. If this is the case, the reason for their exclusion from the TOE boundary must be clear.
If this feature is implemented by the TOE, the following requirements must be claimed in the ST:
The TOE is distributed across multiple server instances. These instances must have the ability to communicate securely with one another and exchange authentication data so that sensitive data in transit between them is protected and only sent to the appropriate destination.
If this feature is implemented by the TOE, the following requirements must be claimed in the ST:
The TOE uses networking functionality to transmit policy data, commands, or both. This data can be transmitted to logically remote entities that are in the operational environment, between separate components of a logically distributed TOE, or both. Specifically for this feature, if this is supported by the product, it must be claimed as part of the TSF.
If this feature is implemented by the TOE, the following requirements must be claimed in the ST:
A conformant TOE may implement policy by communicating configuration instructions to a software agent on a system rather than through direct interaction with the system itself. An agent may reside locally on the same system as the TOE or may be remote. If the product is integrated with agents, the agents must be included in the TOE boundary. It is possible that agents are a separate "product" and are in the TOE's operational environment. If this is the case, the reason for their exclusion from the TOE boundary must be clear.
If this feature is implemented by the TOE, the following requirements must be claimed in the ST:
The TOE is distributed across multiple server instances. These instances must have the ability to communicate securely with one another and exchange authentication data so that sensitive data in transit between them is protected and only sent to the appropriate destination.
If this feature is implemented by the TOE, the following requirements must be claimed in the ST:
The TOE uses networking functionality to transmit policy data, commands, or both. This data can be transmitted to logically remote entities that are in the operational environment, between separate components of a logically distributed TOE, or both. Specifically for this feature, if this is supported by the product, it must be claimed as part of the TSF.
If this feature is implemented by the TOE, the following requirements must be claimed in the ST:
A conformant TOE may implement policy by communicating configuration instructions to a software agent on a system rather than through direct interaction with the system itself. An agent may reside locally on the same system as the TOE or may be remote. If the product is integrated with agents, the agents must be included in the TOE boundary. It is possible that agents are a separate "product" and are in the TOE's operational environment. If this is the case, the reason for their exclusion from the TOE boundary must be clear.
If this feature is implemented by the TOE, the following requirements must be claimed in the ST:
The TOE is distributed across multiple server instances. These instances must have the ability to communicate securely with one another and exchange authentication data so that sensitive data in transit between them is protected and only sent to the appropriate destination.
If this feature is implemented by the TOE, the following requirements must be claimed in the ST:
The TOE uses networking functionality to transmit policy data, commands, or both. This data can be transmitted to logically remote entities that are in the operational environment, between separate components of a logically distributed TOE, or both. Specifically for this feature, if this is supported by the product, it must be claimed as part of the TSF.
If this feature is implemented by the TOE, the following requirements must be claimed in the ST:
An ST must claim exact conformance
to this PP-Module.
The evaluation methods used for evaluating the TOE are a combination of the workunits
defined in [CEM] as well as the Evaluation Activities for ensuring that individual SFRs
and SARs have a sufficient level of supporting evidence in the Security Target and guidance
documentation and have been sufficiently tested by the laboratory as part of completing
ATE_IND.1. Any functional packages this PP claims similarly contain their own Evaluation
Activities that are used in this same manner.
CC Conformance Claims
This PP-Module is conformant to
Part 2 (extended)
and Part 3 (extended)
of Common Criteria CC:2022, Revision 1.
PP Claim
This PP-Module does not claim conformance to
any Protection Profile.
This PP-Module is
Functional Package for Secure Shell Version 2.0 conformant.
This PP-Module is
Functional Package for Transport Layer Security Version 2.1 conformant.
This PP-Module is
Functional Package for X.509 Version 1.0 conformant.
This PP-Module does not conform to any
assurance packages.
The functional packages to which the PP conforms may include SFRs that are not mandatory
to claim for the sake of conformance. An ST that claims one or more of these functional
packages may include any non-mandatory SFRs that are appropriate to claim based on the
capabilities of the TSF and on any triggers for their inclusion based inherently on the SFR
selections made.
3 Security Problem Definition
The security problem is described in terms
of the threats that the TOE is expected to address, assumptions about the
Operational Environment, and any organizational security policies that the TOE
is expected to enforce. These extend any threats, assumptions, and organizational security policies defined by the Base PP.
Note that these threats are nearly duplicates of the App PP and the things that are inherited from that PP do not need to be redefined; suggest reviewing these once SFRs are fully defined to adjust specifically to the context of this TOE (versus a general App PPTOE).
3.1 Threats
Note that this PP-Module does not repeat the threats
identified in the Base PP, though they all apply given the conformance and hence
dependence of this PP-Module on the Base PP.
T.NETWORK_ATTACK
An attacker is positioned on a communications channel or elsewhere on the network infrastructure. Attackers may engage in communications with parts of the EM system with the intent of compromise. Engagement may consist of altering existing legitimate communications.
T.NETWORK_EAVESDROP
An attacker is positioned on a communications channel or elsewhere on the network infrastructure. Attackers may monitor and gain access to data exchanged between parts of the EM system.
T.LOCAL_ATTACK
An attacker may compromise applications running on the same computing platform on which part of the EM system executes. The compromised application may provide maliciously formatted input to the EM system through a variety of channels including unprivileged system calls and messaging via the file system.
T.LIMITED_PHYSICAL_ACCESS
An attacker may attempt to access EM system data at rest on the endpoint devices.
3.2 Assumptions
This PP defines no Assumptions beyond those defined in the claimed Base-PP(s).
3.3 Organizational Security Policies
This PP defines no Organizational Security Policies beyond those defined in the claimed Base-PP(s).
4 Security Objectives
4.1 Security Objectives for the Operational Environment
This PP-Module does not define any Security Objectives for the Operational Environment beyond those defined in the claimed Base-PP(s).
5 Security Requirements
This chapter describes the security requirements which have to be fulfilled by the product under evaluation.
Those requirements comprise functional components from Part 2 and assurance components from Part 3 of
[CC].
The following conventions are used for the completion of operations:
Refinement operation (denoted by bold text or strikethrough
text): Is used to add details to a requirement or to remove part of the requirement that is made irrelevant
through the completion of another operation, and thus further restricts a requirement.
Selection (denoted by italicized text): Is used to select one or more options
provided by the [CC] in stating a requirement.
Assignment operation (denoted by italicized text): Is used to assign a
specific value to an unspecified parameter, such as the length of a password. Showing the
value in square brackets indicates assignment.
Iteration operation: Is indicated by appending the SFR name with a slash and unique identifier
suggesting the purpose of the operation, e.g. "/EXAMPLE1."
5.1
Protection Profile for Application Software
Security Functional Requirements Direction
In a PP-Configuration that includes App PP, the TOE is expected to rely on some of the security functions implemented by the application
as a whole and evaluated against the Base PP.
The SFRs listed in this section are defined in the Base PP and relevant to the secure operation of the TOE.
This section describes any modifications that the ST author must make to the Base PPSFRs to satisfy the required Enterprise-Management functionality.
5.1.1 Modified SFRs
This PP-Module does not modify any SFRs defined by the App PP.
5.2 TOE Security Functional Requirements
The following section describes the SFRs that must be satisfied by any TOE that claims conformance to this PP-Module.
These SFRs must be claimed regardless of which PP-Configuration is used to define the TOE.
5.2.1 Auditable Events for Mandatory SFRs
Table 1: Auditable Events for Mandatory Requirements
ESR: configuration of EM system, auditing and compliance
Adapted from MDM PP requirement of the same name
Note that the specific events that trigger an alert may need to be updated depending on the intended minimum functionality of the EM TOE.
The TSF shall alert the administrators in the event of any of the following:
Change in management status (i.e., adding system or agent to management, removing system or agent from management)
Failure to respond to heartbeat or check in during designated reporting interval
[selection: [assignment:
other events], no other events]
Application
Note:
An alert can be defined as anything providing straightaway notice to the administrator. An alert is different from
an audit record, however the fact that an alert was sent should be audited per FAU_GEN.1. Email, pop-up notifications, or other methods
are acceptable forms of alerts.
The expectation of this requirement is that the TOE has a mechanism to configure the heartbeat or reporting interval of systems or agents that are under its management. The inability of the system or agent to maintain this mechanism should be flagged by the TSF as anomalous behavior requiring further examination and potential corrective action. This necessarily includes a mechanism to identify the assets under management and when they are added or removed.
ESR: auditing and compliance
Adapted from MDM PP requirement of the same name
Note that this is currently very generic because we will need TC/SME input on the minimum "compliance reporting" functionality of the EM TOE (i.e. is there a minimum set of things it needs to be able to check on, or potentially multiple such selectable sets depending on intended usage).
The way this is currently written it expects a remote agent to generate a report and then securely transmit that report to the EM. We probably only care about the data itself because the TSF can do its own reporting based on the data it receives. Also see comment in FTP_ITC.1 - it's possible that some of this data could be transmitted over a non-trusted channel based on the protocol used for transmission and the types of data that are being transmitted. So explicitly referencing FTP_ITC.1 may not be correct here.
The TSF shall provide the ability to generate compliance reports of the configuration status of managed
[selection: systems, agents] over a channel
that meets the secure channel requirements in FTP_ITC.1. The provided information for each enrolled
[selection: systems, agents]
includes:
TBD
List of configuration policies that are in place on the device (as defined in
FMT_SMF.1.1/MANAGED)
Application
Note:
The intent of this requirement is that the TOE be able to provide
compliance information about managed systems, whether that is obtained through querying the system itself or by interfacing with an agent running on the system for this purpose.
ESR: auditing and compliance
Adapted from MDM PP requirement of the same name (for management of MDM Agents)
Note that this is currently very generic because we will need TC/SME input on the minimum audit data generation functionality of the EM TOE (i.e. is there a minimum set of things it needs to be able to log, or potentially multiple such selectable sets depending on intended usage).
The TSF shall
[selection: invoke platform-provided functionality, implement functionality] to generate audit data of the following auditable events:
All administrative actions
Commands issued to managed [selection: system, agent]
Specifically defined auditable events listed in Table 1
[selection:
Startup and shutdown of the audit functions
Auditable events defined in Table 6 for Implementation-Based SFRs
Auditable events defined in Table 7 for Selection-Based SFRs
Auditable events defined in the audit table for the TLS Functional Package (see Table 2)
no other events
].
Application
Note:
This requirement outlines the events for which audit data must be generated by either the TOE or by its underlying platform. It is acceptable for this requirement to be met through a combination of platform-provided and TOE-provided audit functions, so long as the full set of required events are generated and include the required data.
Item a above requires all administrative actions to be auditable. Administrative actions refer to any management functions specified by
FMT_MOF.1. Thus no additional specification for the auditability of these actions is specified in Table 1 aside
from those that require additional record content.
Item b includes any commands that are performed against a managed system or agent. This need not go to the granularity of individual API calls, but it is expected that there is sufficient data to be clear to an administrator what actions the TOE may be performing against an external entity or what data it may be receiving from it.
Depending on the specific requirements selected by the ST author from SFR, optional requirements, selection-based
requirements, and objective requirements, the ST author should include the appropriate auditable
events from Table t-audit-optional, Table 7, and Table t-audit-objective in the
ST for the requirements selected.
In item d above, "startup and shutdown of the audit functions" may refer to the independent startup and shutdown of audit functionality specifically, or it may refer to startup and shutdown of the TOE itself, if auditing cannot be disabled separately from the operation of the TOE. It is outside the scope of the TOE boundary to consider the need to audit the startup and shutdown of auditing functionality used by the TOE platform, as this would be an inherent function of the host operating system.
The following table contains the events enumerated in the auditable events tables for the TLS Functional Package. Inclusion of these events
in the ST is subject to selection above, inclusion of the corresponding SFRs in the ST, and support in the FP as represented by a selection
in the FP audit table. This list is included here for reference.
additional information defined in Table 7 for Selection-Based SFRs
additional information defined in the audit table for the TLS Functional Package (see Table 2)
no other additional information
]
Application
Note:
This requirement outlines the information to be included in audit data. All audits must contain at least the
information mentioned in FAU_GEN.1.2, but may contain more information. The ST author
must identify what audit data is generated by the TOE in its own audit mechanism versus audit data generated by the TOE platform based on the TOE's operation.
ESR: auditing and compliance
Adapted from MDM PP requirement of the same name
The TSF shall be able to store generated audit data on [selection: the TOE itself, an external IT entity using a trusted channel according to
FTP_ITC.1, local platform storage].
Application
Note:
Per FAU_GEN.1.1, audit data may be generated by the TOE, the platform, or both. If audit data is generated by the TOE, the TSF must have the ability to securely transmit this data to a remote entity. It may additionally store this data within the TOE boundary, in which case "the TOE itself" is selected and FAU_STG.2 must be included in the ST. Regardless of whether the TSF stores the audit data it generates within the TOE boundary, the TOE must always be able to securely transmit the audit data it generates to a remote entity. If audit data is generated by the platform, any secure local storage or secure remote transmission of this data is the responsibility of the platform.
Although the audit server is outside of the TOE, the TSF should still be able to support
mutual authentication. There are no requirements levied on the audit server, but the TOE should be
able to support TLS client certificate authentication. This way if the non-TOE audit server does
support verifying client certs, the TSF is able to make use of that.
For distributed TOEs, each component must be able to export any audit data it generates across a
protected channel. This may involve individual components independently transmitting
audit data to the same environmental audit server via FTP_ITC.1, or it may involve
one component of a distributed TOE aggregating audit data generated by other
components prior to external transmission. In this case, the internal communication of audit data is protected via the mechanisms specified in FPT_ITT.1. The intent of this requirement in the context of a distributed TOE is that all audit data generated by all components of the TSF be transmitted to an environmental entity entirely through trusted channels, regardless of whether it is transmitted directly from the TSF to the operational environment or whether it is first transmitted to another part of the TOE.
5.2.3 Class FIA: Identification and Authentication
ESR: authentication and authorization
Adapted from MDM PP requirement of the same name
The TSF shall [selection: invoke platform-provided functionality, implement functionality] to allow [assignment:
list of TSF mediated actions]
on behalf of the user to be performed before the user is authenticated with the
server.
The TSF shall [selection: invoke platform-provided functionality, implement functionality] that requires each user to be successfully authenticated before allowing any other TSF-mediated actions on behalf of that user.
Application
Note:
This requirement ensures that any user attempting to access the TSF must be authenticated. The ST author is responsible for assigning
the list of actions that can take place (if any) before this authentication. The TSF or TOE platform may
use enterprise authentication to meet this
requirement (e.g., integration with enterprise directory services for single sign-on). An application that is installed in the context of a particular OS user such that the authentication context is inherited from logging in to the TOE platform as that user is also an example of authentication being facilitated through invocation of platform-provided functionality.
If "implement functionality" is selected in FIA_UAU.1.2, the ST must include the selection-based SFRsFIA_UIA_EXT.1 and FTA_SSL.3.
If "display of the warning banner in accordance with FTA_TAB.1" is selected, the ST must include the selection-based SFRFTA_TAB.1.
5.2.4 Class FMT: Management of the TSF
FMT_MOF.1 Management of Security Functions Behavior
ESR: Endpoint and Agent Management; Permission Segregation
Adapted from MDM PP requirement of the same name
The TSF shall restrict the ability to perform the functions
listed in FMT_SMF.1/Managed
listed in FMT_SMF.1/Internal
to [assignment:
authorized administrative roles for each function].
Application
Note:
This requirement defines the permissions necessary to execute
or manage the behavior of functions used for both management of external entities
(i.e., Enterprise-Management) as defined in FMT_SMF.1/Internal as well as the TOE itself.
The ST author will define, for each claimed administrative function, any roles that are
authorized to perform this function. Roles may be predefined by the TOE, inherited from
an organizational directory, or custom based on privileges assigned to a role that the
TOE has the ability to create.
Role assignment in and of itself may not be sufficient to authorize a function; it may
be the case that scoping rules also define the specific set of objects that the function
may be performed against. Examples could include a user having the ability to reset only
their own password while an administrator has the ability to reset any user's password,
or two different users being able to perform the same Enterprise-Management functions
against two groups of external entities.
FMT_SMF.1/MANAGED Specification of Management Functions (Server configuration of Managed Systems)
ESR: The EM server/agents shall have a mechanism to report patch levels and initiate the patching process
ESR: The EM server/agents shall have a mechanism to report patch levels and initiate the patching process
Adapted from MDM PP requirement of the same name
Incomplete/placeholder as more things will likely be needed (whether mandatory or selectable) based on desired EM functionality.
Monitoring capability probably needs to be defined in greater detail than a generic "query configuration". Incomplete/placeholder as more things will likely be needed (whether mandatory or selectable) based on desired EM functionality.
The TSF shall be capable of performing the following management functions against managed systems:
query configuration
apply configuration
and configuration settings including the following management functions: [selection:
agent functions:
query installed agent software version
update the agent software
query agent connectivity status
configure agent reporting interval
unenroll agent from management
password policy [selection:
minimum password length
minimum password complexity
maximum password lifetime
authentication factors
authentication failures, maximum before lockout
authentication failures, lockout duration
authentication failures, reset interval
]
audit policy [selection:
audit rules
name and address of audit or logging server to which to send audit or
logging records
local audit storage and retention policy
]
access banners policy
session locking policy [selection:
screen-lock enabled or disabled
screen lock timeout
display notifications
]
host-based firewall policy
removable media policy
software update policy
network time server policy
cryptographic policy
].
Application
Note:
This requirement captures all the configuration functionality that the TSF provides to interact with managed systems, whether that is through direct interaction with those systems or with agents running on those systems. Note that the "managed system" may also be the local system on which the TOE resides if the purpose of the TOE is to manage a centralized system.
If the TOE interacts with agents, the selection for "agent functions" must be claimed.
FMT_SMF.1/INTERNAL Specification of Management Functions (Server Configuration of Server)
ESR: Compliance
Adapted from MDM PP requirement of the same name (for management of the MDM Server itself)
Incomplete/placeholder as the management functionality necessary for the server must be defined (e.g. configuration of cryptographic channels, configuration of X.509 certs/trust anchors, configuration of user accounts). Note that some of this may be selectable as being implemented by the TOE or by the platform (or not at all, depending on what is claimed).
The TSF shall be capable of performing the following management functions for configuration of the TSF: [assignment:
list of management functions]
Application
Note:
This requirement addresses the management functions the TOE provides to manage its own behavior (as opposed to managing the behavior of external entities)
ESR: Endpoint and Agent Management; Permission Segregation
Adapted from MDM PP requirement of the same name
The TSF shall maintain the roles [assignment:
the authorized identified roles].
The TSF shall be able to associate users with roles.
Application
Note:
This PP-Module does not require a fixed set of arbitrarily-named roles. The purpose of this requirement is for the ST author to document how users are organized for the purpose of determining the authorizations they have to interact with the TSF, as specified in FMT_MOF.1.
5.3 TOE Security Functional Requirements Rationale
The following rationale provides justification for each SFR for the TOE,
showing that the SFRs are suitable to address the specified threats:
If this PP-Module is used to extend the Application Software PP, the TOE type for the overall TOE is still a
software-based application. The TOE boundary is simply extended to include the Enterprise-Management functionality
that is built into the application so that additional security functionality is claimed within the scope of the TOE.
6.1.2
Consistency of Security Problem Definition
Table 4: Consistency of Security Problem Definition (App PP base)
This PP-Module does not define any objectives for the TOE's Operational Environment.
6.1.4
Consistency of Requirements
This PP-Module identifies several SFRs from the
App PP that are needed to support
Enterprise-Management functionality.
This is considered to be consistent because the functionality provided by the
App PP is being used for its intended purpose.
The rationale for why this does not conflict with the claims
defined by the
App PP are as follows:
Table 5: Consistency of Requirements (App PP base)
ESR: configuration of EM system, auditing and compliance
Adapted from MDM PP requirement of the same name
The TSF shall provide authorized administrators with the capability to read the network connectivity status of an external entity.
Application
Note:
Depending on whether the external entity is a system or a specific agent residing on the system, the network connectivity status may be registered with an ICMP ping or other generic mechanism, or through an API or other function that is specific to the agent or interface the TOE interacts with to perform management functions.
ESR: Resiliency
Adapted from MDM PP requirement of the same name
The TSF shall [selection: invoke platform-provided functionality, implement functionality] to require an Administrator to enable communications between any pair of TOE components before such communication can take place.
The TSF shall [selection: invoke platform-provided functionality, implement functionality] to implement a registration process in which components establish and use a communications channel that uses
[selection: A channel that meets the secure channel requirements in FPT_ITT.1, A channel that meets the secure registration channel requirements in FTP_TRP.1/Join, No channel]
for at least TSF data.
The TSF shall [selection: invoke platform-provided functionality, implement functionality] to enable an administrator to disable communications between any pair of TOE components.
Application
Note:
This SFR is only applicable if the TOE is distributed and therefore has multiple components that need to communicate via an internal
TSF channel. When creating the TSF from the initial pair of components, either of these components may be identified as the
TSF for the purposes of satisfying the meaning of "TSF" in this SFR.
Registration of the distributed TOE components may be accomplished either using the same trusted channel that subsequent communications occur on (FPT_ITT.1), a separate channel that exists for the purpose of facilitating this registration, i.e. a joining channel (FTP_TRP.1/Join), or no channel. In the case of the latter, registration would be accomplished by independent administrative configuration of each component.
A.3.4 Class FIA: Identification and Authentication
FIA_ENR_EXT.1 Enrollment
This component must be included in the ST if the TOE implements any of the following features:
Three things to consider here:
1. Right now it just talks about "user" enrollment which is an MDM specific framing. Should think about other ways that enrollment could occur (e.g. based on individual device, group of devices) and what authentication is used for those (certificate on device? Key distributed by EM during the setup process?)
2. Right now this only applies to systems with agents but enrollment could potentially apply in an agentless scenario too. Might need a separate iteration for non-agent scenarios (but selection/feature-based, not mandatory)
3. FIA_ENR_EXT.1.2 talks about limitation on enrollment because it covers the MDM case where a user has to enroll a specific device that's associated with them. Not sure if we care about any such limitations in the context of EM and if we do what all those limitations would be. If we don't want any limitations we may need to define a new extended SFR because we probably can't have 1.2 say "The TSF shall do nothing related to this function".
The TSF shall authenticate the remote users over a trusted channel during the
enrollment of a Host Agent.
Application
Note:
The TSF may use its own directory or a directory server to perform the authentication decision for users performing
the remote enrollment of an endpoint.
The TSF shall limit the user's enrollment of devices to devices specified by
[assignment:
a unique device ID] and [assignment:
other
features].
Application
Note:
This requirement is designed to permit the enterprise to restrict users' enrollment of devices. A unique device ID is required
to limit the user's enrollment. The unique device ID could be an asset tag specified by the organization.
A.3.5 Class FMT: Security Management
FMT_MOF.1/MANAGEMENT_ENROLL Management of Security Functions Behavior (Enrollment)
This component must be included in the ST if the TOE implements any of the following features:
The TSF shall restrict the ability to [initiate the enrollment process]
to [authorized administrators].
Application
Note:
This requirement outlines the enrollment functions that both administrators and users may perform.
The enrollment actions are identified in the TSS as a part of FIA_ENR_EXT.1.
A.3.6 Class FPT: Protection of the TSF
FPT_ITT.1 Internal TOE TSF Data Transfer
This component must be included in the ST if the TOE implements any of the following features:
mutually authenticated TLS as defined in the Package for Transport Layer Security
mutually authenticated DTLS as defined in the Package for Transport Layer Security
HTTPS in accordance with FCS_HTTPS_EXT.1 as defined in the Base PP
SSH as defined in the Functional Package for Secure Shell
]
] to protect all data from [disclosure and modification] when it is transferred between
separate parts of the TOE.
Application
Note:
This requirement ensures all communications between components of a distributed TOE are protected through the use of an encrypted communications channel. The data passed in this trusted communication channel are encrypted as defined in the protocol chosen in the second selection.
If "IPsec as defined in the PP-Module for VPN Client" is selected, the TSF must claim conformance to a PP-Configuration that includes the VPN Client PP-Module.
If the ST author selects "SSH as defined in the Functional Package for Secure Shell," the TSF must be validated against the FP for Secure Shell. It should be noted that due to constraints imposed by this PP that SHA-1 cannot be used.
If the ST author selects "mutually authenticated TLS as defined in the Package for Transport Layer Security" or "mutually authenticated DTLS as defined in the Package for Transport Layer Security," the TSF must be validated against requirements from the Package for Transport Layer Security, with the following selections made:
FCS_TLS_EXT.1:
either TLS or DTLS is selected depending on the selection made in
FTP_ITC.1.1
either client or server is selected as appropriate
FCS_TLSC_EXT.1.1 or FCS_TLSS_EXT.1.1 (as appropriate):
The cipher suites selected must correspond with the algorithms and hash functions allowed in FCS_COP.1.
mutual authentication must be selected
Protocol, RBG, Certificate validation, algorithm, and similar services may be met with
platform-provided services.
A.3.7 Class FTP: Trusted Path/Channels
FTP_ITC.1 Inter-TSF Trusted Channel (Authorized IT Entities)
This component must be included in the ST if the TOE implements any of the following features:
ESR: confidentiality and integrity of data-at-rest and in-transit
Adapted from MDM PP requirement of the same name We also need to consider how to handle an untrusted channel for interfacing with systems (probably as a collection mechanism only; "management" should not go over an untrusted channel. Unless you were to do something like encrypt a blob with a pre-shared key and then send the encrypted blob in the clear but that's probably not typical. We also need to determine what untrusted channel mechanisms exist (e.g. is it just SNMP traps or are there others) and also what types of data we do or don't allow to be collected through an untrusted channel. FDP_ITC could be considered for this (CC part 1 doesn't define "user data" but suspect it can be used as anything that is not TSF data and could work here).
The TSF shall [selection:
invoke platform-provided functionality to use [selection:
SSH as defined in the Functional Package for Secure Shell
mutually authenticated TLS as defined in the Package for Transport Layer Security
mutually authenticated DTLS as defined in the Package for Transport Layer Security
HTTPS in accordance with FCS_HTTPS_EXT.1 as defined in the Base PP
]
] to provide a trusted
communication channel between itself and authorizedITentities supporting the following capabilities: connectivity to remote [selection: systems, agents], audit server,
[selection: authentication server, [assignment:
other capabilities]] that is logically distinct from other communication channels and provides assured identification of its endpoints
and protection of the channel data from modification or disclosure.
Application
Note:
The intent of the mandatory portion of the above requirement is to use the cryptographic
protocols identified in the requirement to establish and maintain a trusted channel with authorized IT entities
that the TOE interacts with to perform its functions.
Protection (by one of the listed protocols) is required at least for communications with the IT entities managed by the TOE (whether those are systems that are managed using APIs provided by those systems by default, specialized agents running on systems that are designed for the purpose of interacting with the TOE, or both) and with
the server that collects
the audit information. If it communicates with an authentication server (e.g., RADIUS), then the ST
author chooses "authentication server" in FTP_ITC.1.1 and this connection must be protected
by one of the listed protocols. If other authorized IT entities (e.g., NTP server) are protected, the
ST author makes the appropriate assignments (for those entities) and selections (for the protocols
that are used to protect those connections).
To summarize, all communications with external entities that require protection of data in transit must be defined and must use one of the protocols specified in the requirement. At minimum, the TSF must communicate with external entities for the purpose of performing Enterprise-Management functions against them, and with a remote audit server for external storage of audit data. Additional channels are not required in order for the TOE to achieve its minimum required functionality, but if any such channels are implemented, appropriate protections must be provided for them.
The trusted channel uses IPsec, TLS, DTLS, or HTTPS as the protocol that preserves the confidentiality and integrity of external communications. The ST
author chooses the mechanism or mechanisms supported by the TOE.
If "IPsec as defined in the PP-Module for VPN Client" is selected, the TSF must claim conformance to a PP-Configuration that includes the VPN Client
PP-Module.
If HTTPS is chosen, FCS_HTTPS_EXT.1 must be included in the ST.
If the ST author selects "SSH as defined in the Functional Package for Secure Shell," the TSF must be validated against the FP for Secure Shell. It should be noted that due to constraints imposed by this PP that SHA-1 cannot be used.
If the ST author selects "mutually authenticated TLS as defined in the Package for Transport Layer Security" or "mutually authenticated DTLS as
defined in the Package for Transport Layer Security," the TSF must be validated against requirements from the Package for Transport Layer Security,
with the following selections made:
FCS_TLS_EXT.1:
either TLS or DTLS is selected depending on the selection made in FTP_ITC.1.1
either client or server is selected as appropriate
FCS_TLSC_EXT.1.1 or FCS_TLSS_EXT.1.1 (as appropriate):
The cipher suites selected must correspond with the algorithms and hash functions allowed in FCS_COP.1.
mutual authentication must be selected
FCS_DTLSC_EXT.1.1 or FCS_DTLSS_EXT.1.1 (as appropriate):
The cipher suites selected must correspond with the algorithms and hash functions allowed in FCS_COP.1.
mutual authentication must be selected
Protocol, RBG, Certificate validation, algorithm, and similar services may be met with
platform-provided
services.
The requirement implies that not only are communications protected when they are initially established, but
also on resumption after an outage. It may be the case that some part of the TOE setup involves
manually setting up tunnels to protect other communication, and if after an outage the TOE attempts
to re-establish the communication automatically with (the necessary) manual intervention, there may be a window created
where an attacker might be able to gain critical information or compromise a connection.
The TSF shall [selection: invoke platform-provided functionality, implement functionality] to permit [selection: the TSF, another trusted IT product] to initiate communication via the trusted channel.
The TSF shall [selection: invoke platform-provided functionality, implement functionality] to initiate communication via the trusted channel for
[assignment:
list of functions for which a trusted channel is required].
Application
Note:
While there are no requirements on the party initiating the
communication, the ST author lists in the assignment for FTP_ITC.1.3
the services for which the TOE can initiate the communication with
the authorized IT entity.
FTP_TRP.1 Trusted Path
This component must be included in the ST if the TOE implements any of the following features:
TLS as defined in the Package for Transport Layer Security
HTTPS in accordance with FCS_HTTPS_EXT.1 as defined in the Base PP
SSH as defined in the Functional Package for Secure Shell
]
] to provide a trusted
communication path between itself as a [selection: server, peer] and [remote] administrators that is logically distinct from other communication paths and provides assured
identification of its endpoints and protection of the communicated data from [modification, disclosure].
The TSF shall [selection: invoke platform-provided functionality, implement functionality] to permit [remote administrators] to initiate communication via the trusted path.
The TSF shall require the use of the trusted path for [initial administrator authentication, [remote administration]].
Application
Note:
This requirement ensures that authorized remote administrators initiate all
communication with the TOE via a trusted path, and that all communications with
the TOE by remote administrators is performed over this path. The data passed in this trusted
communication channel are encrypted as defined in the protocol chosen in the first selection. The ST
author chooses the mechanism or mechanisms supported by the TOE.
If "IPsec as defined in the PP-Module for VPN Client" is selected, the TSF must claim conformance to a PP-Configuration that includes the VPN Client PP-Module.
If the ST author selects "SSH as defined in the Functional Package for Secure Shell," the TSF must be validated against the FP for Secure Shell.
If the ST author selects "TLS as defined in the Package for Transport Layer Security" the TSF must be validated against requirements from the Package for Transport Layer Security, with the following selections made:
FCS_TLS_EXT.1:
TLS must be selected
Server must be selected
FCS_TLSS_EXT.1.1:
The cipher suites selected must correspond with the algorithms and hash functions allowed in FCS_COP.1.
Protocol, RBG, Certificate validation, algorithm, and similar services may be met with
platform-provided services.
If HTTPS is chosen, FCS_HTTPS_EXT.1 must be included in the ST.
Appendix B - Selection-based Requirements
B.1 Auditable Events for Selection-Based SFRs
Table 7: Auditable Events for Selection-based Requirements
ESR: auditing and compliance
Adapted from MDM PP requirement of the same name
The TSF shall [selection: invoke platform-provided functionality, implement functionality] to provide [authorized administrators] with the
capability to read [all audit information] from the audit data.
The TSF shall [selection: invoke platform-provided functionality, implement functionality] to provide the audit data in a manner suitable for the
authorized administrators to interpret the information.
Application
Note:
The intent of this requirement is to ensure that the
administrator can view and interpret the audit data and to
prevent unauthorized users from accessing the logs.
FAU_STG.2 Audit Event Storage
The inclusion of this selection-based component depends upon selection in
FAU_STG.1.1.
ESR: auditing and compliance
Adapted from MDM PP requirement of the same name
The TSF shall [selection: invoke platform-provided functionality, implement functionality] to protect the stored audit data in the audit trail from unauthorized
deletion.
Application
Note:
If "store audit data locally" is selected in FAU_STG.1.1, this SFR must be included in the ST.
The purpose of this requirement is to ensure that audit data are stored securely. The ST author
is responsible for selecting whether audit data
are maintained when audit storage or failure occurs. The ST author must choose a means by which
audit data are saved and select the events during which
the data will be saved. The TSF may rely on the underlying operating system for this functionality, and the first selection should be made
appropriately.
The TSF shall detect when an administrator configurable positive integer within [assignment:
range of acceptable values] unsuccessful authentication
attempts occur related to [administrator login using passwords].
When the defined number of unsuccessful authentication attempts has been [selection: met, surpassed], the TSF shall [selection: prevent the offending administrator from successfully establishing a remote session using any authentication method that
involves a password until [assignment:
action to unlock] is taken by an administrator, prevent the offending Administrator from successfully establishing a remote session using any authentication method that
involves a password until an administrator defined time period has elapsed]
Application
Note:
This SFR is included in the ST if "Web GUI Password" or "SSH password" are selected in FIA_UIA_EXT.1.1.
FIA_PMG_EXT.1 Password Management
The inclusion of this selection-based component depends upon selection in
FIA_UIA_EXT.1.1.
The TSF shall provide the following password management
capabilities for administrative passwords:
Passwords shall be able to be composed of any combination of upper and lower
case letters, numbers, and the following special characters: [selection: “!”, “@”, “#”, “$”, “%”, “^”, “&”, “*”, “(“, “)”, [assignment:
other characters]]
Minimum password length shall be [configurable to between [assignment:
minimum number of characters supported by the TOE] and
[assignment:
number of characters greater than or equal to 15] characters].
.
Application
Note:
This SFR is included in the ST if "Web GUI Password" or "SSH password" are selected in FIA_UIA_EXT.1.1.
FIA_UIA_EXT.1 User Identification and Authentication
The inclusion of this selection-based component depends upon selection in
FIA_UAU.1.2.
The TSF shall provide the following authentication mechanisms: [selection: Web GUI password, SSH password, SSH public key, X.509 certificate, [assignment:
other authentication mechanism]]
Application
Note:
This SFR is included in the ST if "implement functionality" is selected in FIA_UAU.1.2.
If either "password" option is selected, or the assignment is used for any other password-based authentication mechanism, the ST must include the selection-based SFRsFIA_AFL.1 and FIA_PMG_EXT.1.
B.4 Class FTP: Trusted Path/Channels
FTP_TRP.1/Join Trusted Path (for Joining)
The inclusion of this selection-based component depends upon selection in
FCO_CPC_EXT.1.2.
ESR: Resiliency
Adapted from MDM PP requirement of the same name
The TSF shall [selection: invoke platform-provided functionality, implement functionality] to provide a communication path between itself and a joining
component that is logically distinct from other communication paths and provides assured identification of [selection: the TSF endpoint, both joining component and TSF endpoint] and protection of the communicated data from
[modification] and [selection: disclosure, none].
The TSF shall [selection: invoke platform-provided functionality, implement functionality] to permit [selection: the TSF, the joining component] to initiate communication via the trusted path.
The TSF shall [selection: invoke platform-provided functionality, implement functionality] to require the use of the trusted path for [joining components
to the TSF under environmental constraints identified in [assignment:
reference to operational guidance]].
Application
Note:
This SFR implements one of the types of channel identified in the main selection for FCO_CPC_EXT.1.2. The "joining component" in FTP_TRP.1/Join is the IT entity that is attempting to join the distributed TOE by using the registration process.
The effect of this SFR is to require the ability for components to communicate in a secure manner while the distributed TSF is being created (or when adding components to an existing distributed TSF). When creating the TSF from the initial pair of components, either of these components may be identified as the TSF for the purposes of satisfying the meaning of "TSF" in this SFR.
The selection at the end of FTP_TRP.1/Join recognises that in some cases confidentiality (i.e., protection of the data from disclosure) may not be provided by the channel. The ST author distinguishes in the TSS whether in this case the TOE relies on the environment to provide confidentiality (as part of the constraints referenced in FTP_TRP.1.3/Join) or whether the registration data exchanged does not require confidentiality (in which case this assertion must be justified). If "none" is selected, then this word may be omitted in the ST to improve readability.
The assignment in FTP_TRP.1.3/Join ensures that the ST highlights any specific details needed to protect the registration environment. Note that when the ST uses FTP_TRP.1/TRUSTPATH_JOIN for the registration channel then this channel cannot be reused as the normal inter-component communication channel defined in FPT_ITT.1.
B.5 Class FTA: TOE Access
FTA_SSL.3 TSF-initiated termination
The inclusion of this selection-based component depends upon selection in
FIA_UAU.1.2.
Before establishing a user session, the [selection: TSF, TOE platform] shall display an [administrator-specified advisory notice and consent warning] message.
Application
Note:
This SFR is included in the ST if "display of the warning banner in accordance with FTA_TAB.1" is selected in FIA_UAU.1.1.
Appendix C - Extended Component Definitions
This appendix contains the definitions for all extended requirements specified in the PP-Module.
C.1 Extended Components Table
All extended components specified in the PP-Module are listed in this table:
Table 8: Extended Component Definitions
Functional Class
Functional Components
Class FAU: Security Audit
FAU_ALT_EXT Server Alerts FAU_CRP_EXT Support for Compliance Reporting Configuration FAU_NET_EXT Network Reachability Review
FIA_PMG_EXT Password Management FIA_UIA_EXT User Identification and Authentication
C.2 Extended Component Definitions
C.2.1 Class FAU: Security Audit
This PP-Module defines the following extended components as part of the
class originally defined by CC Part 2:
C.2.1.1 FAU_ALT_EXT Server Alerts
Family Behavior
This family defines requirements for the TSF to alert administrators when a set of
specified events occurs.
Component Leveling
FAU_ALT_EXT.1,
Server Alerts,
defines requirements for alerting the administrator to events.
Management: FAU_ALT_EXT.1
The following actions could be considered for the management functions in FMT.
Install policies.
Audit: FAU_ALT_EXT.1
The following actions should be auditable if FAU_GEN security audit data generation
is included in the PP or ST.
Type of alert.
Identity of external entity that sent alert.
FAU_ALT_EXT.1 Server Alerts
Hierarchical to:
No other components.
Dependencies to:
No dependencies.
FAU_ALT_EXT.1.1
ESR: configuration of EM system, auditing and compliance
Adapted from MDM PP requirement of the same name
Note that the specific events that trigger an alert may need to be updated depending on the intended minimum functionality of the EM TOE.
The TSF shall alert the administrators in the event of any of the following:
Change in management status (i.e., adding system or agent to management, removing system or agent from management)
Failure to respond to heartbeat or check in during designated reporting interval
[selection: [assignment:
other events], no other events]
C.2.1.2 FAU_CRP_EXT Support for Compliance Reporting Configuration
Family Behavior
This family defines requirements for the TSF to generate compliance reports of the configuration of external entities.
Component Leveling
FAU_CRP_EXT.2,
Generation of Compliance Reports,
defines requirements for the contents and presentation of compliance reports.
Management: FAU_CRP_EXT.2
No specific management functions are identified.
Audit: FAU_CRP_EXT.2
There are no auditable events foreseen.
FAU_CRP_EXT.2 Generation of Compliance Reports
Hierarchical to:
No other components.
Dependencies to:
FTP_ITC.1 Inter-TSF Trusted Channel
FAU_CRP_EXT.2.1
ESR: auditing and compliance
Adapted from MDM PP requirement of the same name
Note that this is currently very generic because we will need TC/SME input on the minimum "compliance reporting" functionality of the EM TOE (i.e. is there a minimum set of things it needs to be able to check on, or potentially multiple such selectable sets depending on intended usage).
The way this is currently written it expects a remote agent to generate a report and then securely transmit that report to the EM. We probably only care about the data itself because the TSF can do its own reporting based on the data it receives. Also see comment in FTP_ITC.1 - it's possible that some of this data could be transmitted over a non-trusted channel based on the protocol used for transmission and the types of data that are being transmitted. So explicitly referencing FTP_ITC.1 may not be correct here.
The TSF shall provide the ability to generate compliance reports of the configuration status of managed
[selection: systems, agents] over a channel
that meets the secure channel requirements in FTP_ITC.1. The provided information for each enrolled
[selection: systems, agents]
includes:
TBD
List of configuration policies that are in place on the device (as defined in
FMT_SMF.1.1/MANAGED)
C.2.1.3 FAU_NET_EXT Network Reachability Review
Family Behavior
This family defines requirements for administrators to see network
connectivity status of external entities managed by the TOE.
Component Leveling
FAU_NET_EXT.1,
Network Reachability Review,
defines requirements for authorized administrators to read network connectivity
status.
Management: FAU_NET_EXT.1
The following actions could be considered for the management functions in FMT.
Query connectivity status.
Audit: FAU_NET_EXT.1
There are no auditable events foreseen.
FAU_NET_EXT.1 Network Reachability Review
Hierarchical to:
No other components.
Dependencies to:
No dependencies.
FAU_NET_EXT.1.1
ESR: configuration of EM system, auditing and compliance
Adapted from MDM PP requirement of the same name
The TSF shall provide authorized administrators with the capability to read the network connectivity status of an external entity.
C.2.2 Class FCO: Communications
This PP-Module defines the following extended components as part of the
class originally defined by CC Part 2:
This family describes the registration process, including the capability for
the administrator to enable or disable communications between a distributed TOE and other
components of the TOE.
Component Leveling
FCO_CPC_EXT.1,
Component Registration Channel Definition,
defines requirements for the registration process for distributed TOEs.
Management: FCO_CPC_EXT.1
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 or ST.
Enabling or disabling communications between a pair of components.
Identities of the endpoint's pairs enabled or disabled.
ESR: Resiliency
Adapted from MDM PP requirement of the same name
The TSF shall [selection: invoke platform-provided functionality, implement functionality] to require an Administrator to enable communications between any pair of TOE components before such communication can take place.
FCO_CPC_EXT.1.2
The TSF shall [selection: invoke platform-provided functionality, implement functionality] to implement a registration process in which components establish and use a communications channel that uses
[selection: A channel that meets the secure channel requirements in FPT_ITT.1, A channel that meets the secure registration channel requirements in FTP_TRP.1/Join, No channel]
for at least TSF data.
FCO_CPC_EXT.1.3
The TSF shall [selection: invoke platform-provided functionality, implement functionality] to enable an administrator to disable communications between any pair of TOE components.
C.2.3 Class FIA: Identification and Authentication
This PP-Module defines the following extended components as part of the
class originally defined by CC Part 2:
C.2.3.1 FIA_PMG_EXT Password Management
Family Behavior
The TOE defines the attributes of passwords used by administrative users to
ensure that strong passwords and passphrases can be chosen and maintained.
This is a new family defined for the FIA class.
Component Leveling
FIA_PMG_EXT.1,
Password Management,
requires the TSF to support passwords
with varying composition requirements, minimum lengths, maximum lifetime,
and similarity constraints.
Management: FIA_PMG_EXT.1
There are no management functions foreseen.
Audit: FIA_PMG_EXT.1
There are no auditable events foreseen.
FIA_PMG_EXT.1 Password Management
Hierarchical to:
No other components.
Dependencies to:
No dependencies.
FIA_PMG_EXT.1.1
The TSF shall provide the following password management
capabilities for administrative passwords:
Passwords shall be able to be composed of any combination of upper and lower
case letters, numbers, and the following special characters: [assignment:
allowable special characters]
Minimum password length shall be [assignment:
minimum password character length].
C.2.3.2 FIA_UIA_EXT User Identification and Authentication
Family Behavior
The TSF requires a non-TOE entity to be authenticated before any TSF-mediated actions may be taken.
This is a new family defined for the FIA class.
Component Leveling
FIA_UIA_EXT.1,
User Identification and Authentication,
requires Administrators to be identified and authenticated by the TOE before the TOE performs any
mediated functions.
Management: FIA_UIA_EXT.1
The following actions could be considered for the management functions in FIA_UIA_EXT.1.
Ability to configure the list of TOE services available before an entity is identified and authenticated.
Audit: FIA_UIA_EXT.1
The following actions should be auditable if FAU_GEN security audit data generation is
included in the PP or ST.
All use of the identification and authentication mechanism
Provided user identity, origin of the attempt (e.g., IP address)
FIA_UIA_EXT.1 User Identification and Authentication
Hierarchical to:
No other components.
Dependencies to:
No dependencies.
FIA_UIA_EXT.1.1
The TSF shall provide the following authentication mechanisms: [assignment:
allowable authentication mechanisms]
Appendix D - Inherently Satisfied Requirements
This
appendix lists requirements that should be considered satisfied by products
successfully evaluated against this Protection Profile.
However, these requirements are not featured explicitly as SFRs and should not be
included in the ST.
They are not included as standalone SFRs because it would
increase the time, cost, and complexity of evaluation. This approach is permitted
by [CC] Part 1, 8.2 Dependencies between components.
This information benefits systems engineering activities which call for inclusion of
particular security controls. Evaluation against the Protection Profile
provides evidence that these controls are present and have been evaluated.
