collaborative Protection Profile for Network Devices/collaborative
Protection Profile for Stateful Traffic Filter Firewalls
Extended Package (EP) for Intrusion Prevention Systems (IPS)
15 June 2017
Version 2.11
Page 2 of 47
Table of Contents
1 Introduction ..........................................................................................................................................4
1.1 Conformance Claims.....................................................................................................................4
1.2 How to Use This Extended Package..............................................................................................4
1.3 Compliant Targets of Evaluation...................................................................................................4
2 Security Problem Definition..................................................................................................................8
2.1 Unauthorized Disclosure of Information ......................................................................................8
2.2 Unauthorized Access.....................................................................................................................9
2.3 Inappropriate Access to Services..................................................................................................9
2.4 Disruption or Denial of Services....................................................................................................9
3 Security Objectives..............................................................................................................................10
3.1 System Monitoring......................................................................................................................10
3.2 Analysis of Network Traffic Policy Violations..............................................................................10
3.3 Reaction to Network Traffic Policy Violations ............................................................................10
3.4 TOE Administration.....................................................................................................................10
3.1 Trusted Communications............................................................................................................11
4 Security Requirements........................................................................................................................12
4.1 Conventions ................................................................................................................................12
4.2 TOE Security Functional Requirements ......................................................................................12
4.2.1 FAU: Security Audit .............................................................................................................13
4.2.2 FMT: Security Management................................................................................................15
4.2.3 IPS: Intrusion Prevention ....................................................................................................16
5 Test Environment................................................................................................................................28
6 Security Assurance Requirements ......................................................................................................30
Appendix A: Rationale.................................................................................................................................31
A.1 Security Problem Definition........................................................................................................31
A.1.1 Assumptions........................................................................................................................31
A.1.2 Threats ................................................................................................................................31
A.1.3 Organizational Security Policies..........................................................................................32
A.1.4 Security Problem Definition Correspondence ....................................................................32
A.2 Security Objectives......................................................................................................................32
A.2.1 Security Objectives for the TOE ..........................................................................................32
A.2.2 Security Objectives for the Operational Environment........................................................33
A.2.3 Security Objective Correspondence....................................................................................33
Page 3 of 47
A.3 Rationale for Security Functional Requirements........................................................................33
Appendix B: Optional Requirements ..........................................................................................................35
B.1 Requirements..............................................................................................................................35
B.1.1 FAU: Security Audit .............................................................................................................35
B.1.2 FMT: Security Management Requirements........................................................................36
B.1.3 FPT: Protection of the TSF...................................................................................................37
B.1.4 FRU: Resource Utilization....................................................................................................39
B.1.5 IPS: Intrusion Prevention ....................................................................................................40
Appendix C: Selection-Based Requirements...............................................................................................42
C.1 Requirements..............................................................................................................................42
C.1.1 FCS: Cryptographic Support................................................................................................42
Appendix D: Objective Requirements.........................................................................................................43
D.1 Requirements..............................................................................................................................43
D.1.1 FAU: Security Audit .............................................................................................................43
Appendix E: Definitions...............................................................................................................................46
E.1 Definitions of Attacks..................................................................................................................46
E.2 Definitions of Terms and Acronyms............................................................................................47
Tables
Table 4-1: Security Functional Requirements.............................................................................................12
Table 4-2: Auditable Events and Additional Audit Record Contents ..........................................................14
Table A-1: TOE Assumptions.......................................................................................................................31
Table A-2: Threats.......................................................................................................................................31
Table A-3: Policies.......................................................................................................................................32
Table A-4: Security Problem Definition Correspondence...........................................................................32
Table A-5: Security Objectives for the TOE.................................................................................................32
Table A-6: Security Objectives for the Operational Environment ..............................................................33
Table A-7: Rationale for Explicitly Stated Requirements............................................................................33
Table A-8: SFR Dependency Rationale........................................................................................................33
Table D-1: Table of Events (some examples inserted)................................................................................44
Figures
Figure 1: TOE Deployment Scenario Diagram...............................................................................................7
Figure 2: Sample Inline Mode Test Topology..............................................................................................28
Figure 3: Sample Promiscuous Mode Test Topology..................................................................................28
Page 4 of 47
1 Introduction
This Extended Package (EP) describes security requirements for a network-based Intrusion Prevention
System (IPS) (defined to be an intrusion prevention product located within or at the edge of a private
network that can collect, inspect, analyze, and react to network traffic in real-time) and is intended to
provide a minimal baseline set of requirements that are targeted at mitigating well defined and described
threats. This EP is not complete in itself, but rather extends either the collaborative Protection Profile for
Network Devices (NDcPP) or collaborative Protection Profile for Stateful Traffic Filter Firewalls (FWcPP).
This introduction will describe the features of a compliant Target of Evaluation (TOE), and will also discuss
how this EP is to be used in conjunction with the NDcPP and/or the FWcPP.
1.1 Conformance Claims
The collaborative Protection Profile for Network Devices (NDcPP) defines the baseline Security Functional
Requirements (SFRs) and Security Assurance Requirements (SARs) for network infrastructure devices in
general. The collaborative Protection Profile for Stateful Traffic Filter Firewalls (FWcPP) defines a similar
set of SFRs and SARs as the NDcPP but adds requirements that are specific to traffic filter firewalls. This
EP serves to extend the baseline set by either the NDcPP or FWcPP, with additional SFRs and associated
‘Assurance Activities’ specific to IPS devices. Assurance Activities are the actions that the evaluator
performs in order to determine a TOE’s compliance to the SFRs.
This EP conforms to Common Criteria for Information Technology Security Evaluation, Version 3.1,
Revision 4. It is CC Part 2 extended and CC Part 3 conformant.
1.2 How to Use This Extended Package
As an EP of either the NDcPP or FWcPP, it is expected that the content of both this EP and the base PP be
appropriately combined in the context of each product-specific Security Target. This EP has been
specifically defined such that there should be no difficulty or ambiguity in so doing. An ST must identify
the applicable versions of the NDcPP or FWcPP (see http://www.niap-ccevs.org/pp/ for the current
version) and this EP in its conformance claims.
When this EP is used to build on the NDcPP, conformant TOEs are obligated to implement the functionality
required in the NDcPP along with the additional functionality defined in this EP in response to the threat
environment discussed subsequently herein. Likewise, when this EP is used to build on the FWcPP,
conformant TOEs are expected to satisfy all requirements of that PP as well as those that are defined by
this EP. The PP that is extended by this EP is referred to as the “base PP”.
ST authors should consider whether it would be appropriate for the IPS TOE to also claim conformance to
the FWcPP instead of the NDcPP. In some ways the IPS EP may be incompatible with a TOE configured to
meet the FWcPP because the FWcPP requires that all interfaces block certain types of traffic at all times,
while that may not be appropriate for all IPS TOE deployments. However, if the ST author is willing to have
all the certified IPS TOE configurations conform to all SFRs of this IPS EP and the FWcPP, the authors of
this IPS EP have not intended to make the two EPs incompatible.
It is intended that the set of requirements in this EP is limited in scope in order to promote quicker, less
costly evaluations that provide some value to end users.
1.3 Compliant Targets of Evaluation
This EP specifically addresses network-based Intrusion Prevention Systems (IPS). A conformant IPS is a
product that is connected to one or more distinct networks and is managed as part of an overall enterprise
Page 5 of 47
security solution. In particular, a compliant IPS provides network security administrators with the ability
to monitor, collect, log, and react in real-time to potentially malicious network traffic. This EP is focused
on inspecting IP traffic (TCP, UDP, ICMP, etc.). This limited scope is intentional for a number of reasons
including: to define a reasonable boundary for the scope of testing (assurance measures) defined within
the EP and to allow future EPs to address other IPS and functionality that includes scanners, analyzers,
sensors, etc. The scope of the EP does not preclude support for inspection of other IP protocols (e.g. GRE,
ESP, AH), but the scope of this EP does not include the evaluation of non-IP protocols including layer 2
protocols, or Ethernet.
The baseline requirements of this EP are those determined necessary for an Intrusion Prevention product,
though conformant TOEs may provide IPS functionality entirely independently from other network
components, and/or be deployed to operate in conjunction with other components of a larger enterprise
security solution. For example, though all conformant IPS TOEs must have some capacity to monitor,
collect, analyze, and react to network traffic, a conformant TOE could:
 Monitor all network traffic passively detected by one or more its interfaces, and/or monitor only
specific traffic flows that are passed by or through the IPS for inspection.
 Transmit IPS data to an external audit storage host, and optionally store IPS data internally. IPS
audit data can be pushed (initiated by the TOE), or pulled (initiated by the remote host).
Regardless of whether IPS data is pushed or pulled, the transmission must be protected in a
manner consistent with protected communications required by FAU_STG_EXT.1 of the NDcPP and
FWcPP.
 Analyze network traffic based on rules that an administrator can configure directly on the TOE,
and optionally analyze network traffic based on rules imported/applied from another system.
 React independently to potentially malicious traffic (such as by blocking traffic flows, or by
transmitting session resets to the endpoints), and optionally react in collaboration with non-TOE
components of the overall enterprise security solution by initiating a connection to non-TOE
components to cause/configure the non-TOE component to obstruct the traffic flow.
Many similarities exist between a conformant IPS TOE and an Intrusion Detection System (IDS), but there
are some important distinctions. The conformant IPS TOE differs from an IDS in that the conformant TOE
must be capable of initiating a proactive response to terminate/interrupt an active potential threat, and
to initiate a response in real time that would cause interruption of the suspicious traffic flow. It’s not
sufficient for the TOE to only be able to generate an audit event or other alert when potentially malicious
traffic is detected. However, the IPS administrator may choose to configure the TOE such that such
proactive responses are not enabled, and such a configuration would be a valid configuration for the TOE.
Though a conformant TOE may be deployed with only its IDS functionalities enabled, the conformant TOE
must demonstrate that capability during the evaluation.
Conformant TOEs will detect potentially malicious network traffic using various approaches. Broadly
speaking, the traffic analysis could be based on identification of ‘known’ threats, or ‘unknown’ threats.
Identification of ‘known’ threats may be performed through pattern matching, e.g. by matching strings of
characters within an IP packet, or by matching traffic patterns common with reconnaissance or denial of
service (DoS) attacks. Identification of ‘unknown’ threats may be performed through use of various forms
of ‘anomaly’ detection whereby the IPS is provided with (or ‘learns’/creates) a definition of
‘expected/typical’ traffic patterns, such that it’s able to detect and react to ’anomalous’
(unexpected/atypical) traffic patterns.
Page 6 of 47
The TOE may be a distributed TOE in which some SFRs or elements of SFRs are enforced by separate TOE
components distributed across an IP network. In such cases, the TOE boundary must be drawn such that
the sum total of all components of the product can satisfy the requirements defined in this EP and each
individual component is capable of satisfying the base NDcPP or FWcPP on its own. Additionally, all
communications between these distributed components must be protected using one or more of the
trusted communication protocols that are defined in the NDcPP or FWcPP.
Deployment scenarios supported by the TOE would include those shown in Figure 1, which includes a
number of possible deployments of IPS functionality within a single network.
 IPS 1 is operating in promiscuous mode, capturing data from two separate networks outside the
perimeter firewall, and sending traffic filter updates as needed to the perimeter router and
perimeter firewall to block unwanted traffic in real-time.
 IPS 2 is operating in inline mode, analyzing traffic to and from a wireless network, and blocking in
real-time any traffic that violates the admin-defined IPS policies.
 IPS 3 is operating in a combination of promiscuous mode and inline mode. The IPS has at least
one pair of interfaces creating a bridge or routing across the TOE, and is analyzing and filtering
traffic in real-time as traffic traverses the TOE. The same IPS has one or more promiscuous
interfaces collecting and analyzing traffic traversing within each separate network, and reacting
to anomalous activity, worms, or otherwise unapproved activity.
Page 7 of 47
Figure 1: TOE Deployment Scenario Diagram
Page 8 of 47
2 Security Problem Definition
IPS devices address a range of security threats related to detection of and reaction to potentially malicious
traffic on monitored networks, to which the security policies will be enforced on applicable network
traffic. The malicious traffic may pose a threat to one or more endpoints on the monitored networks, or
to the network infrastructure, or to the TOE itself. The term “monitored networks” is used here to
represent any network to which the TOE is directly connected, as well as network segments/subnets that
have had their traffic forwarded (redirected or copied) to the IPS for analysis.
The term “IPS Data” will be used throughout this EP and includes any or all of: the data extracted from
network traffic and stored on the TOE; the results of analysis performed by the TOE; and messages that
indicate the TOE’s reaction to that analysis. This “IPS Data” described in this EP refers to the network
traffic collected by the IPS and the resulting audit records related to analysis of that network traffic, all of
which is separate from the “audit data” as defined in FAU_GEN from the base PP, such as audit records
related to authentication of administrators and establishment/termination of trusted channels.
A site is responsible for developing its security policy and configuring a rule set that the IPS will enforce
and provide an appropriate response to meet their needs, relative to their own risk analysis and their
perceived threats. Threats mitigated by the conformant TOE can include attempts to:
 Perform network-based reconnaissance (probing for information about a monitored network or
its endpoints), such as through use of various scanning or mapping techniques.
 Obstruct the normal function of monitored networks, endpoints, or services, such as through
denial of service attacks.
 Gain inappropriate access to one or more networks, endpoints, or services, such as through brute
force password guessing attacks, or by transmitting malicious executable code, scripts, or
commands.
 Disclose/transmit information in violation of policy, such as sending credit card numbers. Note,
relative to the data, it does not matter where the threat agent is located. Example: data
exfiltration means that data was removed without proper authorization to remove it. This may be
a pull or a push. It can result from intrusion from the outside or by the actions of the insider.
Note that this EP does not repeat the threats identified in the NDcPP and/or FWcPP, though they all apply
given the conformance and hence dependence of this EP on the NDcPP or FWcPP. Additionally, this EP
describes TOE functionality (such as security management functions) that are subject to the same threats
as those that are defined in the NDcPP and FWcPP. A full mapping between threats and objectives is
provided in Appendix A of this EP.
The NDcPP contains only threats to the ability of the TOE to provide its own functions. The FWcPP includes
all of the same threats as the NDcPP but adds threats to resources in the TOE’s operational environment.
This EP also focuses on threats to resources in the operational environment, some of which are similar to
those that are defined in the FWcPP but will be met from an IPS perspective rather than a traffic filtering
one. Together, the threats of the claimed base PP and those defined in this EP define the comprehensive
set of security threats addressed by an IPS TOE.
2.1 Unauthorized Disclosure of Information
Sensitive information on a protected network might be disclosed resulting from disclosure/transmitted
information in violation of policy, such as sending unencrypted credit card numbers. The IPS TOE will be
capable of inspecting packet payloads for data strings and patterns of characters.
Page 9 of 47
(T.NETWORK_DISCLOSURE)
2.2 Unauthorized Access
An attacker may attempt to gain inappropriate access to one or more networks, endpoints, or services,
such as through brute force password guessing attacks, or by transmitting malicious executable code,
scripts, or commands. If malicious external devices are able to communicate with devices on the protected
network, then those devices may be susceptible to the unauthorized disclosure of information.
(T.NETWORK _ACCESS)
2.3 Inappropriate Access to Services
Access to services made available by a protected network might be used counter to Operational
Environment policies. Devices located outside the protected network may attempt to conduct
inappropriate activities while communicating with allowed public services, (e.g. manipulation of resident
tools, SQL injection, phishing, forced resets, malicious zip files, disguised executables, privilege escalation
tools, and botnets).
(T.NETWORK_MISUSE)
2.4 Disruption or Denial of Services
Attacks against services inside a protected network, or indirectly by virtue of access to malicious agents
from within a protected network, might lead to denial of services otherwise available within a protected
network. Resource exhaustion may occur in the event of co-ordinate service request flooding from a small
number of sources. Though most IPS will provide some protection from DDoS (distributed denial of
service) attacks, providing protection against DDoS attacks is not a requirement for conformant TOEs, as
this is best counteracted by firewalls, cloud computing and design. Note however that DoS protection is
required.
(T.NETWORK_DOS)
Page 10 of 47
3 Security Objectives
The Security Problem described in Section 2 will be addressed by a combination of IPS capabilities, with
the understanding that the TOE is installed in manner to which it can effectively enforce its policies on the
network traffic of the monitored networks. Conformant TOEs will provide security functionality that
addresses threats to the TOE, applies analytical processes to network traffic data collected, and enforces
enterprise policies as applied to the IPS by the IPS administrator. The following subsections provide a
description of the security objectives required to meet the threats/policies previously discussed.
Note: in each subsection below particular security objectives are identified (highlighted by O.) and they
are matched with the associated security functional requirements (SFRs) that provide the mechanisms to
satisfy the objectives.
3.1 System Monitoring
To be able to analyze and react to potential network policy violations, the IPS must be able to collect and
store essential data elements of network traffic on monitored networks.
(O.SYSTEM_MONITORING -> FAU_ARP.1 (objective), FAU_GEN.1/IPS, FAU_SAR.1 (objective), FAU_SAR.2
(objective), FAU_SAR.3 (objective), FAU_STG.1 (optional), FAU_STG.4 (optional), FRU_RSA (optional))
3.2 Analysis of Network Traffic Policy Violations
Entities that reside on or communicate across monitored networks must have network activity effectively
analyzed for potential violations of approved network usage. The TOE must be able to effectively analyze
data collected from monitored networks to reduce the risk of unauthorized disclosure of information,
inappropriate access to services, and misuse of network resources.
(O.IPS_ANALYZE -> IPS_ABD_EXT.1, IPS_IPB_EXT.1, IPS_NTA_EXT.1, IPS_SBD_EXT.1, IPS_SBD_EXT.2
(optional))
3.3 Reaction to Network Traffic Policy Violations
The TOE must be able to react in real-time as configured by the IPS administrators to terminate and/or
block traffic flows that have been determined to violate administrator-defined IPS policies.
(O.IPS_REACT -> FAU_ARP.1 (objective), IPS_ABD_EXT.1)
3.4 TOE Administration
To address the threat of unauthorized administrator access that is defined in the base PP, conformant
TOEs will provide the functions necessary for an administrator to configure the IPS capabilities of the TOE.
(O.TOE_ADMINISTRATION -> FMT_MOF.1/IPS (optional), FMT_MTD.1/IPS (optional), FMT_SMF.1/IPS,
FMT_SMR.2/IPS (optional))
Page 11 of 47
3.1 Trusted Communications
To further address the threat of untrusted communications channels that is defined in the base PP,
conformant TOEs will provide trusted communications between distributed components if any exist.
(O.TRUSTED_COMMUNICATIONS (optional) -> FPT_ITT.1 (optional))
Page 12 of 47
4 Security Requirements
This section specifies a Security Functional Requirement for the TOE, as well as specifying the assurance
activities the evaluator performs.
4.1 Conventions
The CC defines operations on Security Functional Requirements: assignments, selections, assignments
within selections and refinements. This document uses the following font conventions to identify the
operations defined by the CC:
 Assignment: Indicated with italicized text;
 Refinement made by PP author: Indicated by the word “Refinement” in bold text after the
element number with additional text in bold text and deletions with strikethroughs, if
necessary;
 Selection: Indicated with underlined text;
 Assignment within a Selection: Indicated with italicized and underlined text;
 Iteration: Indicated by appending the SFR or element name with a slash and unique indicator for
what function the SFR or element supports, e.g. ‘/IPS’
In cases where CC Part 2 specifies an assignment or selection operation and the PP has already completed
the operation such that the ST author does not have the ability to perform this operation, the operation
is indicated using the conventions described above but without any prompt to the ST author indicating
“Selection:” or “Assignment:”.
Explicitly stated SFRs are identified by having a label ‘EXT’ after the requirement name for TOE SFRs.
4.2 TOE Security Functional Requirements
As an extended package of either the NDcPP or the FWcPP, this EP defines several SFRs related to IPS
functionality as well as related auditing and management functions. A TOE that conforms to this EP is also
expected to confirm with the NDcPP and/or the FWcPP. This EP does not mandate the inclusion or
exclusion of any optional SFRs in either of these PPs, nor does it complete any selection, assignment, or
refinement operations of SFRs that are defined in these PPs. The IPS capability of the TOE that is defined
by this EP is shown in the table below and defined in the following sections.
Table 4-1: Security Functional Requirements
Class Name Component
Identification
Component Name
FAU: Audit Generation FAU_GEN.1/IPS Audit Data Generation (IPS)
FMT: Security Management FMT_SMF.1/IPS Specification of Management Functions (IPS)
IPS: Intrusion Prevention System
IPS_ABD_EXT.1 Anomaly-Based IPS Functionality
IPS_IPB_EXT.1 IP Blocking
IPS_NTA_EXT.1 Network Traffic Analysis
IPS_SBD_EXT.1 Signature-Based IPS Functionality
Page 13 of 47
4.2.1 FAU: Security Audit
The IPS EP defines auditable events for IPS behavior which are similar to auditable events of TSF behavior
that are defined in the base PP but sufficiently distinct to justify existing as a separate iteration of
FAU_GEN.1.
4.2.1.1 FAU_GEN.1/IPS: Audit Data Generation (IPS)
FAU_GEN.1.1/IPS Refinement: The TSF shall be able to generate an IPS audit record of the following
auditable IPS events:
a) Start-up and shut-down of the IPS functions;
b) All IPS auditable events for the [not specified] level of audit; and
c) All administrative actions;
d) [All dissimilar IPS events;
e) All dissimilar IPS reactions;
f) Totals of similar events occurring within a specified time period; and
g) Totals of similar reactions occurring within a specified time period.]
Application Note: The ST author is not limited to the list presented and should update ‘Table of events’
below with any additional information generated. The EP Author should use FAU_GEN.1 as defined in the
base PP for standard (non-IPS data) audit functions.
With regards to ‘similar’ and ‘dissimilar’ type events, dissimilar events are those whose characteristics
differ from other events by something other than merely a timestamp, whereas ‘similar’ events are
multiple occurrences of the same auditable event within some time period where the only significant
difference between these events is the timestamp. For example, it is not expected that the TOE generate
an individual audit message for every event of the same kind that occurs within a reasonable time period
(e.g. the TSF need only generate one audit message for an event that repeated X times during Y seconds).
FAU_GEN.1.2/IPS Refinement: The TSF shall record within each IPS auditable event record at least the
following information:
a) Date and time of the event, type of event and/or reaction, subject identity, and the outcome
(success or failure) of the event; and;
b) For each IPS auditable event type, based on the auditable event definitions of the functional
components included in the PP/ST, [Specifically defined auditable events listed in Table 4-2].
Application Note: As with the previous application note, the ST author should update Table of Events
below with any additional information generated such as source and destination addresses, IP, signature
that trigged event, port, etc.
For IPS_SBD_EXT.1 and IPS_ABD_EXT.1 there may be several circumstances in which it would not be
necessary to explicitly identify the action within the audit messages, for example: If the TOE’s action is
implied within the policy definition; or if the default action is to allow traffic then the absence of ‘blocked’
would imply the traffic was allowed.
For IPS_SBD_EXT.1, if certain header fields are inspected and dropped or modified by default (e.g., packets
with bad checksum, reserved bits set to zero), this logging requirement is not applicable.
Page 14 of 47
Table 4-2: Auditable Events and Additional Audit Record Contents
Requirement Auditable Events Additional Audit Record Contents
FMT_SMF.1/IPS Modification of an IPS policy
element.
Identifier or name of the modified IPS policy
element (e.g. which signature, baseline, or
known-good/known-bad list was modified).
IPS_ABD_EXT.1 Inspected traffic matches an
anomaly-based IPS policy.
Source and destination IP addresses.
The content of the header fields that were
determined to match the policy.
TOE interface that received the packet.
Aspect of the anomaly-based IPS policy rule
that triggered the event (e.g. throughput,
time of day, frequency, etc.).
Network-based action by the TOE (e.g.
allowed, blocked, sent reset to source IP,
sent blocking notification to firewall).1
IPS_IPB_EXT.1 Inspected traffic matches a list of
known-good or known-bad
addresses applied to an IPS
policy.
Source and destination IP addresses (and, if
applicable, indication of whether the source
and/or destination address matched the list).
TOE interface that received the packet.
Network-based action by the TOE (e.g.
allowed, blocked, sent reset).2
IPS_NTA_EXT.1 Modification of which IPS policies
are active on a TOE interface.
Enabling/disabling a TOE
interface with IPS policies
applied.
Modification of which mode(s)
is/are active on a TOE interface.
Identification of the TOE interface.
The IPS policy and interface mode (if
applicable).
IPS_SBD_EXT.1 Inspected traffic matches a
signature-based IPS rule with
logging enabled.
Name or identifier of the matched signature.
Source and destination IP addresses.
The content of the header fields that were
determined to match the signature.
TOE interface that received the packet.
Network-based action by the TOE (e.g.
allowed, blocked, sent reset).3
IPS_SBD_EXT.2.1
(optional)
Inspection of encapsulated
packets.
Indication of the encapsulation method.
IPS_SBD_EXT.2.2
(optional)
Failure to re-assemble a
fragmented packet.
Source and destination IP addresses.
TOE interface that received the fragment(s).
1
See application note.
2
See application note.
3
See application note.
Page 15 of 47
Requirement Auditable Events Additional Audit Record Contents
IPS_SBD_EXT.2.3
(optional)
Normalization of traffic by the
TOE.
Source and destination IP addresses of
discarded packet(s).
TOE interface that received the packet(s).
Activity Assurance Activity
TSS The evaluator shall verify that the TSS describes how the TOE can be configured to log IPS
data associated with applicable policies.
The evaluator shall verify that the TSS describes what (similar) IPS event types the TOE will
combine into a single audit record along with the conditions (e.g., thresholds and time
periods) for so doing. The TSS shall also describe to what extent (if any) that may be
configurable.
For IPS_SBD_EXT.1, for each field, the evaluator shall verify that the TSS describes how the
field is inspected and if logging is not applicable, any other mechanism such as counting
that is deployed.
AGD The evaluator shall verify that the operational guidance describes how to configure the TOE
to result in applicable IPS data logging.
The evaluator shall verify that the operational guidance provides instructions for any
configuration that may be done in regard to logging similar events (e.g., setting thresholds,
defining time windows, etc.).
Test Test 1: The evaluator shall test that the interfaces used to configure the IPS polices yield
expected IPS data in association with the IPS policies. A number of IPS policy combination
and ordering scenarios need to be configured and tested by attempting to pass both
allowed and anomalous network traffic matching configured IPS policies in order to
trigger all required IPS events. Note that this activity should have been addressed with a
combination of the Test assurance activities for the other IPS requirements.
4.2.2 FMT: Security Management
4.2.2.1 FMT_SMF.1/IPS Specification of Management Functions (IPS)
FMT_SMF.1.1/IPS The TSF shall be capable of performing the following management functions: [
 Enable, disable signatures applied to sensor interfaces, and determine the behavior of IPS
functionality
 Modify these parameters that define the network traffic to be collected and analyzed:
o Source IP addresses (host address and network address)
o Destination IP addresses (host address and network address)
o Source port (TCP and UDP)
o Destination port (TCP and UDP)
o Protocol (IPv4 and IPv6)
o ICMP type and code
 Update (import) signatures
Page 16 of 47
 Create custom signatures
 Configure anomaly detection
 Enable and disable actions to be taken when signature or anomaly matches are detected
 Modify thresholds that trigger IPS reactions
 Modify the duration of traffic blocking actions
 Modify the known-good and known-bad lists (of IP addresses or address ranges)
 Configure the known-good and known-bad lists to override signature-based IPS policies]
Application Note: The following assurance activity is to be performed in addition to the assurance activities
specified by the base PP’s Supporting Documents for this SFR.
Activity Assurance Activity
TSS The evaluator shall verify that the TSS describes how the IPS data analysis and reactions
can be configured. Note that this activity should have been addressed with the TSS
assurance activities for IPS_ABD_EXT.1, IPS_IPB_EXT.1 and IPS_ABD_EXT.1
AGD The evaluator shall verify that the operational guidance describes the instructions for each
function defined in the SFR, describes how to configure the IPS data analysis and
reactions, including how to set any configurable defaults and how to configure each of the
applicable analysis pattern matching methods and reaction modes.
Test The evaluator shall perform the following tests:
Test 1: The evaluator shall use the operational guidance to create a signature and enable it
on an interface. The evaluator shall then generate traffic that would be successfully
triggered by the signature. The evaluator should observe the TOE applying the
corresponding reaction in the signature.
Test 2: The evaluator shall then disable the signature and attempt to regenerate the same
traffic and ensure that the TOE allows the traffic to pass with no reaction.
Test 3: The evaluator shall use the operational guidance to import signatures and repeat
the test conducted in Test 1.
Note that all other functions should have been address with a combination of the test
assurance activities for IPS_ABD_EXT.1, IPS_SBD_EXT.1.
4.2.3 IPS: Intrusion Prevention
4.2.3.1 IPS_ABD_EXT.1 Anomaly-Based IPS Functionality
IPS_ABD_EXT.1.1 The TSF shall support the definition of [selection (choose one or more of): baselines
(‘expected and approved’), anomaly (‘unexpected’) traffic patterns] including the specification of
[selection:
 throughput ([assignment: data elements (e.g. bytes, packets, etc.) per time period (e.g. minutes,
hours, days)]);
 time of day;
 frequency;
 thresholds;
 [assignment: other methods]]
and the following network protocol fields:
Page 17 of 47
 [selection: all packet header and data elements defined in IPS_SBD_EXT.1; [assignment: subset
list of packet header and data elements from IPS_SBD_EXT.1]]
Application Note: Baselines are the definition of known-good traffic (to be allowed per IPS_ABD_EXT.1.3)
whilst anomaly traffic is definition of (‘offending’) traffic that is to be handled per other actions defined in
IPS_ABD_EXT.1.3. Frequency can be defined as a number of occurrences of an event (such as detection of
packets matching a signature) over a defined period of time, such as the number of new FTP sessions
established during 1 hour. If ‘frequencies’ is selected the TSS shall include an explanation of how
frequencies can be define on the TOE. Thresholds can be defined as an amount or percentage of deviation
from expected levels or limits, such as a number of megabytes of data transferred via FTP per hour. If
‘thresholds’ is selected the TSS shall include an explanation of how the thresholds can be defined on the
TOE.
IPS_ABD_EXT.1.2 The TSF shall support the definition of anomaly activity through [selection: manual
configuration by administrators, automated configuration].
Application Note: The “baseline” and “anomaly” can be something manually defined/configured by a TOE
administrator (or importing definitions), or something that the TOE is able to automatically define/create
by inspecting network traffic over a period of time (a.k.a. “profiling”). It’s not essential for the IPS TOE to
have a capability of “profiling” a network to dynamically defining a baseline or rule, and if the IPS TOE has
that functionality, such functionality is not being evaluated as part of the IPS EP.
IPS_ABD_EXT.1.3 The TSF shall allow the following operations to be associated with anomaly-based IPS
policies:
 In any mode, for any sensor interface: [selection:
o allow the traffic flow
o send a TCP reset to the source address of the offending traffic;
o send a TCP reset to the destination address of the offending traffic;
o send an ICMP [selection: host, destination, port] unreachable message;
o trigger a non-TOE network device to block the offending traffic pattern]
 In inline mode:
o allow the traffic flow
o block/drop the traffic flow
o and [selection: modify and forward packets before they pass through the TOE, no other
actions]
Activity Assurance Activity
TSS The evaluator shall verify that the TSS describes the composition, construction, and
application of baselines or anomaly-based attributes specified in IPS_ABD_EXT.1.1.
The evaluator shall verify that the TSS provides a description of how baselines are defined
and implemented by the TOE, or a description of how anomaly-based rules are defined
and configured by the administrator.
The evaluator shall verify that each baseline or anomaly-based rule can be associated with
a reaction specified in IPS_ABD_EXT.1.3.
The evaluator shall verify that the TSS identifies all interface types capable of applying
baseline or anomaly-based rules and explains how they are associated with distinct
network interfaces. Where interfaces can be grouped into a common interface type (e.g.,
Page 18 of 47
Activity Assurance Activity
where the same internal logical path is used, perhaps where a common device driver is
used) they can be treated collectively as a distinct network interface.
AGD The evaluator shall verify that the operational guidance provides instructions to manually
create baselines or anomaly-based rules according to the selections made in
IPS_ABD_EXT.1.1. Note that dynamic “profiling” of a network to establish a baseline is
outside the scope of this PP.
The evaluator shall verify that the operational guidance provides instructions to associate
reactions specified in IPS_ABD_EXT.1.3 with baselines or anomaly-based rules.
The evaluator shall verify that the operational guidance provides instructions to associate
the different policies with distinct network interfaces.
Test The evaluator shall perform the following tests:
Test 1: The evaluator shall use the instructions in the operational guidance to configure
baselines or anomaly-based rules for each attributes specified in IPS_ABD_EXT.1.1. The
evaluator shall send traffic that does not match the baseline or matches the anomaly-
based rule and verify the TOE applies the configured reaction. This shall be performed for
each attribute in IPS_ABD_EXT.1.1.
Test 2: Repeat the test assurance activity above to ensure that baselines or anomaly-
based rules can be defined for each distinct network interface type supported by the TOE.
4.2.3.2 IPS_IPB_EXT.1 IP Blocking
IPS_IPB_EXT.1.1: The TSF shall support configuration and implementation of known-good and known-bad
lists of [selection: source, destination] IP addresses.
Application note: The address types defined in this SFR are limited to IP addresses (e.g. a single IP address
or a range of IP addresses) because this IPS EP is limited to inspection of IP traffic. IPS TOEs are not
prohibited from enabling functionality that would allow/prohibit traffic flow based on other address types,
such as MAC addresses, but where that functionality exists, the TSS and guidance documentation must
explain what configurations would cause non-IP lists of known-good and known-bad addresses to take
precedence over IP-based address lists.
IPS_IPB_EXT.1.2: The TSF shall allow IPS Administrators and [selection: no other roles, [assignment: other
roles]] to configure the following IPS policy elements: [selection: known-good list rules, known-bad list
rules, IP addresses, [assignment: other IPS policy elements], no other IPS policy elements].
Activity Assurance Activity
TSS The evaluator shall verify how good/bad lists affect the way in which traffic is analyzed
with respect to processing packets. The TSS should also provide detail with the attributes
that create a known good list, a known bad list, their associated rules, including how to
define the source or destination IP address (e.g. a single IP address or a range of IP
addresses).
The evaluator shall also verify that the TSS identifies all the roles and level of access for
each of those roles that have been specified in the requirement.
Page 19 of 47
Activity Assurance Activity
AGD The evaluator shall verify that the administrative guidance provides instructions with how
each role specified in the requirement can create, modify and delete the attributes of a
known good and known bad lists.
Test The evaluator shall perform the following tests:
Test 1: The evaluator shall use the instructions in the operational guidance to create a
known-bad address list. Using a single IP address, a list of addresses or a range of
addresses from that list, the evaluator shall attempt to send traffic through the TOE that
would otherwise be allowed by the TOE and observe the TOE automatically drops that
traffic.
Test 2: The evaluator shall use the instructions in the operational guidance to create a
known-good address list. Using a single IP address, a list of addresses or a range of
addresses from that list, the evaluator shall attempt to send traffic that would otherwise
be denied by the TOE and observe the TOE automatically allowing traffic.
Test 3: The evaluator shall add conflicting IP addresses to each list and ensure that the TOE
handles conflicting traffic in a manner consistent with the precedence in IPS_NTA_EXT.1.1.
4.2.3.3 IPS_NTA_EXT.1Network Traffic Analysis
IPS_NTA_EXT.1.1 The TSF shall perform analysis of IP-based network traffic forwarded to the TOE’s sensor
interfaces, and detect violations of administratively-defined IPS policies.
Application Note: Though it might be the case in some TOEs that any TOE interface can be a sensor
interface, that capability is not a requirement. This SFR uses the term “sensor interface” to refer to any
TOE interface to which one or more IPS policy has been applied. An administratively-defined IPS policy is
any set of rules for traffic analysis, traffic blocking, signature detection, and/or anomaly detection applied
to one or more TOE interfaces. The TOE may be capable of allowing the administrator to configure the
precedence of IPS policy elements (known-good lists, known-bad lists, signature-based rules, and anomaly-
based rules), but any such configurability is not required by this EP.
Activity Assurance Activity
TSS The evaluator shall verify that the TSS explains the TOE’s capability of analyzing IP traffic
in terms of the TOE’s policy hierarchy (precedence). The TSS should identify if the TOE’s
policy hierarchy order is configurable by the administrator for IPS policy elements
(known-good lists, known-bad lists, signature-based rules, and anomaly-based rules).
Regardless of whether the precedence is configurable, the evaluator shall verify that the
TSS describes the default precedence as well as the IP analyzing functions supported by
the TOE.
The TSS associated with this requirement is assessed in the subsequent assurance
activities.
AGD The evaluator shall verify that the guidance describes the default precedence.
If the precedence is configurable. The evaluator shall verify that the guidance explains
how to configure the precedence.
Page 20 of 47
Activity Assurance Activity
Test The testing associated with this requirement is assessed in the subsequent assurance
activities.
IPS_NTA_EXT.1.2 The TSF shall process (be capable of inspecting) the following network traffic protocols:
 Internet Protocol (IPv4), RFC 791
 Internet Protocol version 6 (IPv6), RFC 2460
 Internet control message protocol version 4 (ICMPv4), RFC 792
 Internet control message protocol version 6 (ICMPv6), RFC 2463
 Transmission Control Protocol (TCP), RFC 793
 User Data Protocol (UDP), RFC 768
Application Note: The identification of protocol RFCs does not imply that the TOE must ensure all packets
are conformant to the identified protocol RFCs at all times, nor does it imply that the TOE would be able
to enforce full conformance with the RFCs for any traffic flow at any time. The identification of RFCs
provides a frame of reference for understanding the packet contents (headers, fields, states, commands,
etc.) identified else in this and other SFRs. The implication is that the TOE must be capable of understanding
the RFC implementation to the extent the RFC parameters are identified throughout the SFRs.
Activity Assurance Activity
TSS The evaluator shall verify that the TSS indicates that the following protocols are
supported:
 IPv4
 IPv6
 ICMPv4
 ICMPv6
 TCP
 UDP
The evaluator shall verify that the TSS describes how conformance with the identified
protocols has been determined by the TOE developer. (e.g., third party interoperability
testing, protocol compliance testing)
AGD The Guidance associated with this requirement is assessed in the subsequent assurance
activities.
Test The testing associated with this requirement is addressed in the subsequent test
assurance activities.
IPS_NTA_EXT.1.3 The TSF shall allow the signatures to be assigned to sensor interfaces configured for
promiscuous mode, and to interfaces configured for inline mode, and support designation of one or more
interfaces as ‘management’ for communication between the TOE and external entities without
simultaneously being sensor interfaces.
 Promiscuous (listen-only) mode: [assignment: list of interface types];
 Inline (data pass-through) mode: [assignment: list of interface types];
 Management mode: [assignment: list of interface types];
 [selection:
o Session-reset-capable interfaces: [assignment: list of session-reset-capable
interfaces];
o [assignment: other interface types];
o no other interface types].
Page 21 of 47
Application Note: Interface types may be Ethernet, Gigabit Ethernet, etc. Promiscuous interfaces are ones
that listen to network traffic for the sole purpose of inspecting the traffic, but do not provide any OSI Layer
2, Layer 3, or higher layer functionality, so network services are not listening on the interface, and no IP
protocol stack enabled on the interface so no IP address is assigned to the interface. Inline interfaces are
interface pairings that provide a path for network traffic to traverse the TOE such that traffic flows can be
blocked or modified by the TOE in real-time. Like promiscuous interfaces, inline interfaces typically do not
support OSI Layer 3 and higher functionality, though they may provide OSI Layer 2 functionality (with MAC
address assigned to the interfaces) to allow adjacent network devices to forward traffic to/through the
TOE.
The TOE may support separate interfaces to be used for administration/management purposes that can
be configured as OSI Layer 3 interfaces for communication between the TOE and remote entities including
all entities defined in FTP_ITC, and FTP_TRP. The TOE may optionally support additional interface types.
Session-reset interfaces can be the same as any of the promiscuous, inline, management, or other
interfaces, or can be separate interfaces. Session-reset functionality is not mandatory functionality for the
TOE, but is a selectable option within the SFR.
As mentioned in the application note for IPS_NTA_EXT.1.1, it’s not necessary for the TOE to have multiple
single-purpose interfaces (e.g. “sensor” interface, “management” interface, etc.), though it is expected
that the TOE be able to enable specific ports to serve one or more specific interface functions.
Activity Assurance Activity
TSS The evaluator shall verify that the TSS identifies all interface types capable of being
deployed in the modes of promiscuous, and or inline mode as well as the interfaces
necessary to facilitate each deployment mode (at a minimum, the interfaces need to
support inline mode). The TSS should also provide descriptions how the management
interface is distinct from sensor interfaces.
AGD The evaluator shall verify that the operational guidance provides instructions on how to
deploy each of the deployment methods outlined in the TSS. The evaluator shall also
verify that the operational guidance provides instructions of applying IPS policies to
interfaces for each deployment mode. If the management interface is configurable the
evaluator shall verify operational guidance explains how to configure the interface into a
management interface.
The evaluator shall verify that the operational guidance explains how the TOE sends
commands to remote traffic filtering devices.
Note: the secure channel configurations between the TOE and the remote device would
be discussed as per FTP_ITC.1 (if the ST author selects other interface types) and/or
FTP_TRP.1 (for interfaces in management mode) in the base PP.
Test The tests associated for this requirement have been completed in subsequent assurance
activities in which promiscuous and inline interfaces are tested (e.g. tests for
IPS_SBD_EXT.1.7) and in the requirement of FTP_ITC.1 (if the ST author selects other
interface types) and/or FTP_TRP.1 (for interfaces in management mode) in the base PP.
4.2.3.4 IPS_SBD_EXT.1 Signature-Based IPS Functionality
IPS_SBD_EXT.1.1 The TSF shall support inspection of packet header contents and be able to inspect at
least the following header fields:
Page 22 of 47
 IPv4: Version; Header Length; Packet Length; ID; IP Flags; Fragment Offset; Time to Live (TTL);
Protocol; Header Checksum; Source Address; Destination Address; IP Options; and [selection:
Type of Service (ToS), no other field].
 IPv6: Version; payload length; next header; hop limit; source address; destination address; routing
header; and [selection: traffic class, flow label, no other field].
 ICMP: Type; Code; Header Checksum; and [selection: ID, sequence number, [assignment: other
field in the ICMP header]].
 ICMPv6: Type; Code; and Header Checksum.
 TCP: Source port; destination port; sequence number; acknowledgement number; offset;
reserved; TCP flags; window; checksum; urgent pointer; and TCP options.
 UDP: Source port; destination port; length; and UDP checksum.
Activity Assurance Activity
TSS The evaluator shall verify that the TSS describes what is comprised within a signature rule.
The evaluator shall verify that each signature can be associated with a reaction specified
in IPS_SBD_EXT.1.5.
The evaluator shall verify that the TSS identifies all interface types capable of applying
signatures and explains how rules are associated with distinct network interfaces. Where
interfaces can be grouped into a common interface type (e.g., where the same internal
logical path is used, perhaps where a common device driver is used) they can be treated
collectively as a distinct network interface.
AGD The evaluator shall verify that the operational guidance provides instructions with how to
create and/or configure rules using the following protocols and header inspection fields:
 IPv4: Version; Header Length; Packet Length; ID; IP Flags; Fragment Offset; Time
to Live (TTL); Protocol; Header Checksum; Source Address; Destination Address;
and IP Options.
 IPv6: Version; traffic class; flow label; payload length; next header; hop limit;
source address; destination address; routing header; home address options.
 ICMP: Type; Code; Header Checksum; and Rest of Header(varies based on the
ICMP type and code).
 ICMPv6: Type; Code; and Header Checksum.
 TCP: Source port; destination port; sequence number; acknowledgement number;
offset; reserved; TCP flags; window; checksum; urgent pointer; and TCP options.
 UDP: Source port; destination port; length; and UDP checksum.
The evaluator shall verify that the operational guidance provides instructions with how to
select and/or configure reactions specified in IPS_SBD_EXT.1.5 in the signature rules.
Test The evaluator shall perform the following tests:
Test 1: The evaluator shall use the instructions in the operational guidance to test that
packet header signatures can be created and/or configured with the selected and/or
configured reactions specified in IPS_SBD_EXT.1.5 for each of the attributes listed below.
Each attribute shall be individually assigned to its own unique signature:
 IPv4: Version; Header Length; Packet Length; ID; IP Flags; Fragment Offset; Time
to Live (TTL); Protocol; Header Checksum; Source Address; Destination Address;
and IP Options.
Page 23 of 47
Activity Assurance Activity
 IPv6: Version; traffic class; flow label; payload length; next header; hop limit;
source address; destination address; routing header; home address options.
 ICMP: Type; Code; Header Checksum; and Rest of Header (varies based on the
ICMP type and code).
 ICMPv6: Type; Code; and Header Checksum;.
 TCP: Source port; destination port; sequence number; acknowledgement number;
offset; reserved; TCP flags; window; checksum; urgent pointer; and TCP options.
 UDP: Source port; destination port; length; and UDP checksum.
Using packet sniffers, the evaluator will generate traffic to trigger a signature and using
packet captures will ensure that the reactions of each rule are performed as expected.
Test 2: Repeat the test assurance activity above to ensure that signature-based IPS
policies can be defined for each distinct network interface type capable of applying
signatures as supported by the TOE.
IPS_SBD_EXT.1.2 The TSF shall support inspection of packet payload data and be able to inspect at least
the following data elements to perform string-based pattern-matching:
 ICMPv4 data: characters beyond the first 4 bytes of the ICMP header.
 ICMPv6 data: characters beyond the first 4 bytes of the ICMP header.
 TCP data (characters beyond the 20 byte TCP header), with support for detection of:
i) FTP (file transfer) commands: help, noop, stat, syst, user, abort, acct, allo, appe, cdup, cwd,
dele, list, mkd, mode, nlst, pass, pasv, port, pass, quit, rein, rest, retr, rmd, rnfr, rnto, site,
smnt, stor, stou, stru, and type.
ii) HTTP (web) commands and content: commands including GET and POST, and administrator-
defined strings to match URLs/URIs, and web page content.
iii) SMTP (email) states: start state, SMTP commands state, mail header state, mail body state,
abort state.
iv) [selection: [assignment: other types of TCP payload inspection], no other types of TCP payload
inspection];
 UDP data: characters beyond the first 8 bytes of the UDP header;
 [assignment: other types of packet payload inspection]
In addition, the TSF shall support stream reassembly or equivalent to detect malicious payload even if it
is split across multiple non-fragmented packets.
Activity Assurance Activity
TSS The evaluator shall verify that the TSS describes what is comprised within a string-based
detection signature.
The evaluator shall verify that each packet payload string-based detection signature can
be associated with a reaction specified in IPS_SBD_EXT.1.5.
AGD The evaluator shall verify that the operational guidance provides instructions with how to
configure rules using the packet payload string-based detection fields defined in
IPS_SBD_EXT.1.2. The operational guidance shall provide configuration instructions, if
needed, to detect payload across multiple packets.
Page 24 of 47
Activity Assurance Activity
The evaluator shall verify that the operational guidance provides instructions with how to
configure reactions specified in IPS_SBD_EXT.1.5 for each string-based detection
signature.
The evaluator shall verify that the operational guidance provides instructions with how
rules are associated with distinct network interfaces that are capable of being associated
with signatures.
Test The evaluator shall perform the following tests:
Test 1: The evaluator shall use the instructions in the operational guidance to test that
packet payload string-based detection rules can be assigned to the reactions specified in
IPS_SBD_EXT.1.5 using the attributes specified in IPS_SBD_EXT.1.2. However it is not
required (nor is it feasible) to test all possible strings of protocol data, the evaluator shall
ensure that a selection of strings in the requirement is selected to be tested. At a
minimum at least one string using each of the following attributes from IPS_SBD_EXT.1.2
should be tested for each protocol. The evaluator shall generate packets that match the
string in the rule and observe the corresponding reaction is as configured.
 Test at least one string of characters for ICMPv4 data: beyond the first 4 bytes of
the ICMP header.
 Test at least one string of characters for ICMPv6 data: beyond the first 4 bytes of
the ICMP header.
 TCP data (characters beyond the 20 byte TCP header):
i) Test at least one FTP (file transfer) command: help, noop, stat, syst, user, abort,
acct, allo, appe, cdup, cwd, dele, list, mkd, mode, nlst, pass, pasv, port, pass,
quit, rein, rest, retr, rmd, rnfr, rnto, site, smnt, stor, stou, stru, and type.
ii) HTTP (web) commands and content:
(1) Test both GET and POST commands
(2) Test at least one administrator-defined strings to match URLs/URIs, and
web page content.
iii) Test at least one SMTP (email) state: start state, SMTP commands state, mail
header state, mail body state, abort state.
iv) Test at least one string in any additional attribute type defined within
[selection: [assignment: other types of TCP payload inspection];
 Test at least one string of UDP data: characters beyond the first 8 bytes of the UDP
header;
 Test at least one string for each additional attribute type defined in [assignment:
other types of packet payload inspection]]
Test 2: The evaluator shall repeat one of the tests in Test 1 but generate multiple non-
fragmented packets that contain the string in the rule defined.
Test 3: Repeat the test assurance activity above to ensure that signature-based IPS
policies can be defined for each distinct network interface type capable of applying
signatures as supported by the TOE.
Page 25 of 47
IPS_SBD_EXT.1.3: The TSF shall be able to detect the following header-based signatures (using fields
identified in IPS_SBD_EXT.1.1) at IPS sensor interfaces:
a) IP Attacks
i) IP Fragments Overlap (Teardrop attack, Bonk attack, or Boink attack)
ii) IP source address equal to the IP destination (Land attack)
b) ICMP Attacks
i) Fragmented ICMP Traffic (e.g. Nuke attack)
ii) Large ICMP Traffic (Ping of Death attack)
c) TCP Attacks
i) TCP NULL flags
ii) TCP SYN+FIN flags
iii) TCP FIN only flags
iv) TCP SYN+RST flags
d) UDP Attacks
i) UDP Bomb Attack
ii) UDP Chargen DoS Attack
Activity Assurance Activity
TSS The evaluator shall verify that the TSS describes how the attacks defined in
IPS_SBD_EXT.1.3 are processed by the TOE and what reaction is triggered when these
attacks are identified.
AGD The evaluator shall verify that the operational guidance provides instructions with
configuring rules to identify the attacks defined in IPS_SBD_EXT.1.3 as well as the
reactions to these attacks as specified in IPS_SBD_EXT.1.5.
Test Test 1: The evaluator shall create and/or configure rules for each attack signature in
IPS_SBD_EXT.1.3. For each attack, the TOE should apply its corresponding signature and
enable it to each distinct network interface type capable of applying the signatures. The
evaluator shall use packet captures to ensure that the attack traffic is detected by the TOE
and a reaction specified in IPS_SBD_EXT.1.5 is triggered and stops the attack. Each attack
should be performed one after another so as to ensure that its corresponding signature
successfully identified and appropriately reacted to a particular attack.
IPS_SBD_EXT.1.4: The TSF shall be able to detect all the following traffic-pattern detection signatures, and
to have these signatures applied to IPS sensor interfaces:
a) Flooding a host (DoS attack)
i) ICMP flooding (Smurf attack, and ping flood)
ii) TCP flooding (e.g. SYN flood)
b) Flooding a network (DoS attack)
c) Protocol and port scanning
i) IP protocol scanning
ii) TCP port scanning
iii) UDP port scanning
iv) ICMP scanning
Application Note: This SFR defines the minimum set of packet header fields, packet payload strings,
signature types, and potentially malicious traffic patterns (e.g. flooding and scanning) that the TOE must
be able to detect. Valid signatures can be comprised of one, some, or all attributes listed in this SFR, and
IPS TOEs may support inspection of additional attributes not listed in this SFR, but only those listed in the
SFR will be tested by the evaluators. The set of signature types, traffic patterns, etc. identified in this SFR
Page 26 of 47
are not intended to be an exhaustive or completely representative list of malicious activity, nor is it meant
to address DDoS attacks – the intent of this SFR is addressing attacks form a single source IP.
Protocol and port scanning refers to reconnaissance attacks that scan target IP addresses for
open/listening/responsive services by targeting multiple protocols/ports on one or more target IP address
using obvious (sequentially numbered) patterns of target protocol/port numbers or by randomizing the
protocol/port numbers and/or randomizing the time delays between transmissions.
It is understood and expected that IPS product vendors will support pre-defined signatures, but inspection
of the efficacy of the pre-defined signatures themselves is not objective of this EP. Instead, this EP focuses
on the ability of the TOE to perform detailed analysis of network traffic, and those pre-defined signatures
may be used during evaluation, the evaluation team is expected to make use of custom-made signatures
as well. This set of signature types, traffic patterns, etc. has been selected to: 1) place reasonable
boundaries around the scope of testing; and 2) provide a sufficient sampling of packet contents, and traffic
patterns to demonstrate the TOE’s ability to inspect packet contents, to collect traffic pattern statistics
over a period of time, and to correlate collected data.
An IPS sensor interface refers to any TOE interface to which an IPS policy is currently applied.
Activity Assurance Activity
TSS The evaluator shall verify that the TSS describes how the attacks defined in
IPS_SBD_EXT.1.4 are processed by the TOE and what reaction is triggered when these
attacks are identified.
AGD The evaluator shall verify that the operational guidance provides instructions with
configuring rules to identify the attacks defined in IPS_SBD_EXT.1.4 as well as the
reactions to these attacks as specified in IPS_SBD_EXT.1.5.
Test Test 1: The evaluator shall configure individual signatures for each attack in
IPS_SBD_EXT.1.4. For each attack, the TOE should apply its corresponding signature and
enable it to each distinct network interface type capable of applying signatures. The
evaluator shall use packet captures to ensure that the attack traffic is detected by the TOE
and a reaction specified in IPS_SBD_EXT.1.5 is triggered and stops the attack. Each attack
should be performed one after another so as to ensure that its corresponding signature
successfully identified and appropriately reacted to a particular attack.
IPS_SBD_EXT.1.5 The TSF shall allow the following operations to be associated with signature-based IPS
policies:
 In any mode, for any sensor interface: [selection:
o allow the traffic flow;
o send a TCP reset to the source address of the offending traffic;
o send a TCP reset to the destination address of the offending traffic;
o send an ICMP [selection: host, destination, port] unreachable message;
o trigger a non-TOE network device to block the offending traffic pattern]
 In inline mode:
o allow the traffic flow;
o block/drop the traffic flow;
o and [selection: modify and forward packets before they pass through the TOE, no other
actions]
Application Note: The term “trigger” is used to allow for multiple types of interactions, including: one in
which the TOE initiates a authenticated connection to the remote device across an IP network and uses a
remote administration interface of the remote device to modify the active configuration on that device; or
Page 27 of 47
one in which the connection between the TOE and the non-TOE network device does not traverse an IP
network. If the ST author selects “trigger a non-TOE network device…” and the connection between the
TOE and the non-TOE network device traverses an IP network, the ST author must ensure that the non-
TOE device type is identified within FTP_ITC.1.3 (of the base), and the connection between the TOE and the
remote device must be secured in accordance with FTP_ITC.1. In the last bullet of the SFR, “modify and
forward packets before they pass through the TOE,” could include such actions as removing from packet
data character strings that match regular expression (regex) conditions that violate policies, such as
transmitting personally identifiable information or other private data (phone numbers, credit-card
numbers, etc.).
Page 28 of 47
5 Test Environment
This section contains the expectations for the evaluator test environment that is used to perform the test
specified by the assurance activities.
It is assumed the evaluator will have tools suitable to establish sessions, modify or create session packets,
and perceive whether packets are getting through the TOE as well as to examine the content of those
packets. In general, it is expected that IPS rule configuration and logging capabilities of the TOE can be
used to reach appropriate determinations where applicable.
The tests specified above need to be repeated for each distinct network interface type capable of
monitoring network traffic on all ‘sensor’ interfaces of the TOE, which may include ‘promiscuous’
interfaces (with or without an IP address or IP stack, and whether or not the interfaces are capable of
attempting to terminate unapproved traffic flows by transmitting packets such as TCP resets), and inline
(pass-through) interfaces with or without an IP address or IP stack, but not management interfaces used
to remotely access the TOE, or used by the TOE to initiate outbound connections to syslog servers, AAA
servers, remote traffic filtering devices, etc.
The evaluators shall minimally create a test environment that is functionally equivalent to the test
environment illustrated below. The evaluators must provide justification for any differences in the test
environment. The TOE may be a distributed TOE in which some SFRs or elements of SFRs are enforced by
separate TOE components distributed across a network. For distributed TOEs:
 the “TOE” in the “inline mode test topology” must be the TOE component that controls the flow
of traffic, but that TOE component does not need to be the same component that collects or
analyzes the traffic;
 the “TOE” in the “promiscuous mode test topology” must be the TOE component that
communicates with the non-TOE traffic filtering device, but that TOE component does not need
to be the same component that collects or analyzes the traffic.
IPS devices that can be deployed in more than one mode, two instantiations of the TOE will more than
likely make it easier to conduct testing, however, the evaluator is free to construct a test-bed where one
Figure 2: Sample Inline Mode Test Topology
Figure 3: Sample Promiscuous Mode Test Topology
Page 29 of 47
instance of a TOE exists and there is a device that provides the necessary functions to interact with the
TOE to satisfy the testing activities.
It is expected that the traffic generator is used to construct network packets and will provide the evaluator
with the ability to simulate network attacks. The traffic generator can be a COTS (commercial off the shelf),
shareware, or freeware product; special equipment is not necessary.
Page 30 of 47
6 Security Assurance Requirements
This EP does not define any SARs beyond those defined within the NDcPP or FWcPP. It is important to
note that a TOE that is evaluated against this EP is inherently evaluated against the chosen base PP as
well. When evaluating the TOE, it is necessary to apply the SARs defined for the base PP to the entire TOE
and not just the portion that is described by the base PP.
Page 31 of 47
Appendix A: Rationale
In this EP, the focus in the initial sections of the document is to use a narrative presentation in an attempt
to increase the overall understandability of the threats addressed by IPS devices; the methods used to
mitigate those threats; and the extent of the mitigation achieved by compliant TOEs. This presentation
style does not readily lend itself to a formalized evaluation activity, so this section contains the tabular
artifacts that can be used for the evaluation activities associated with this document.
A.1 Security Problem Definition
A.1.1 Assumptions
The specific conditions listed below are assumed to exist in the TOE’s Operational Environment. These
assumptions are in addition to those defined in the base PP and include both practical realities in the
development of the TOE security requirements and the essential environmental conditions on the use of
the TOE.
Table A-1: TOE Assumptions
Assumption Name Assumption Definition
A.CONNECTIONS It is assumed that the TOE is connected to distinct networks in a manner
that ensures that the TOE security policies will be enforced on all
applicable network traffic flowing among the attached networks.
A.1.2 Threats
The threats listed below are addressed by IPS devices. Note that if the FWcPP is claimed as the base PP,
several of these threats are also defined there. In these cases, the same general threat will be mitigated
by a combination of firewall and IPS functionality.
Table A-2: Threats
Threat Name Threat Definition
T.NETWORK_DISCLOSURE Sensitive information on a protected network might be disclosed
resulting from ingress- or egress-based actions.
T. NETWORK_ACCESS Unauthorized access may be achieved to services on a protected network
from outside that network, or alternately services outside a protected
network from inside the protected network. If malicious external devices
are able to communicate with devices on the protected network via a
backdoor then those devices may be susceptible to the unauthorized
disclosure of information.
T.NETWORK_MISUSE Access to services made available by a protected network might be used
counter to Operational Environment policies. Devices located outside the
protected network may attempt to conduct inappropriate activities while
communicating with allowed public services. E.g. manipulation of
resident tools, SQL injection, phishing, forced resets, malicious zip files,
disguised executables, privilege escalation tools and botnets.
T.NETWORK_DOS Attacks against services inside a protected network, or indirectly by virtue
of access to malicious agents from within a protected network, might
lead to denial of services otherwise available within a protected network.
Page 32 of 47
Threat Name Threat Definition
Resource exhaustion may occur in the event of co-ordinate service
request flooding from a small number of sources
A.1.3 Organizational Security Policies
An organization deploying the TOE is expected to satisfy the organizational security policy listed below in
addition to all organizational security policies defined by the claimed base PP.
Table A-3: Policies
Policy Name Policy Definition
P.ANALYZE Analytical processes and information to derive conclusions about
potential intrusions must be applied to IPS data and appropriate response
actions taken.
A.1.4 Security Problem Definition Correspondence
The following table serves to map the threats, assumptions, and organizational security policies (OSPs)
defined in this EP to the security objectives also defined or identified in this EP.
Table A-4: Security Problem Definition Correspondence
Threat, Assumption, or OSP Security Objective
A.CONNECTIONS OE.CONNECTIONS
T.NETWORK_DISCLOSURE O.SYSTEM_MONITORING
O.IPS_ANALYSE, O.IPS_REACT
T. NETWORK_ACCESS O.SYSTEM_MONITORING,
O.IPS_ANALYSE, O.IPS_REACT
T.NETWORK_MISUSE O.SYSTEM_MONITORING,
O.IPS_ANALYSE, O.IPS_REACT
T.NETWORK_DOS O.SYSTEM_MONITORING,
O.IPS_ANALYSE, O.IPS_REACT
T.UNAUTHORIZED_ADMINISTRATOR_ACCESS (from base PP) O.TOE_ADMINISTRATION
T.UNSTRUSTED_COMMUNICATION_CHANNELS (from base
PP)
O.TRUSTED_COMMUNICATIONS
(optional)
P.ANALYZE O.IPS_ANALYZE,
O.TOE_ADMINISTRATION
A.2 Security Objectives
A.2.1 Security Objectives for the TOE
The following table contains security objectives for the TOE. A TOE that conforms to this EP shall be
capable of satisfying these security objectives.
Table A-5: Security Objectives for the TOE
Security Objective Name Security Objective Definition
O.SYSTEM_MONITORING The IPS must collect and store information about all events that
may indicate an IPS policy violation related to misuse,
inappropriate access, or malicious activity on monitored networks.
Page 33 of 47
O.IPS_ANALYZE The IPS must apply analytical processes to network traffic data
collected from monitored networks and derive conclusions about
potential intrusions or network traffic policy violations.
O.IPS_REACT The IPS must respond appropriately to its analytical conclusions
about IPS policy violations.
O.TOE_ADMINISTRATION The IPS will provide a method for authorized administrator to
configure the TSF.
O.TRUSTED_COMMUNICATIONS The IPS will ensure that communications between distributed
components of the TOE are not subject to unauthorized
modification or disclosure.
A.2.2 Security Objectives for the Operational Environment
The following table contains security objectives specific to the operational environments for IPS devices.
These security objectives are in addition to those defined in the base PPs.
Table A-6: Security Objectives for the Operational Environment
Security Objective Name Security Objective Definition
OE.CONNECTIONS TOE administrators will ensure that the TOE is installed in a manner that
will allow the TOE to effectively enforce its policies on network traffic of
monitored networks.
A.2.3 Security Objective Correspondence
The correspondence between the Security Functional Requirements (SFRs) and Security Objectives
identified or defined in this EP is provided in section 3.
A.3 Rationale for Security Functional Requirements
Table A-7: Rationale for Explicitly Stated Requirements
SFR Rationale
IPS_ABD_EXT.1 This SFR was created to correctly specify the TOE’s ability to analyze and
react to anomalies from traffic collected from the operational
environment.
IPS_IPB_EXT.1 This SFR was created to correctly specify the TOE’s ability to create white
lists and black lists of known source IP addresses to optimize the TOE’s
blocking capability by overriding the signature-based analysis of the traffic.
IPS_NTA_EXT.1 This SFR was created to correctly specify the TOE’s ability to analyze traffic
and network protocols for both signature-based and anomaly-based
detection.
IPS_SBD_EXT.1 This SFR was created to correctly specify the TOE’s ability to analyze
signatures and react to matches of the signature from traffic collected from
the operational environment.
IPS_SBD_EXT.2 This SFR was created to define the ability of a conformant TOE to perform
traffic normalization to reconstruct encapsulated and fragmented packets
for the purpose of analyzing it.
Table A-8: SFR Dependency Rationale
Page 34 of 47
SFR Dependency Rationale
FAU_ARP.1 FAU_SAA.1 Alternatively met by the IPS class of
extended requirements (which determine
the behavior that is flagged as a ‘potential
security violation’ in FAU_ARP.1.1)
FAU_GEN.1/IPS FPT_STM.1 Inherited from base PP
FAU_SAR.1 FAU_GEN.1 Included in EP (as FAU_GEN.1/IPS
iteration)
FAU_SAR.2 FAU_SAR.1 Included in EP
FAU_SAR.3 FAU_SAR.1 Included in EP
FAU_STG.1 FAU_GEN.1 Included in EP (as FAU_GEN.1/IPS
iteration)
FAU_STG.4 FAU_STG.1 Included in EP
FMT_MOF.1/IPS FMT_SMF.1 Included in EP (as FMT_SMF.1/IPS
iteration)
FMT_SMR.1 Hierarchical SFR included in EP (as
FMT_SMR.2/IPS iteration)
FMT_MTD.1/IPS FMT_SMF.1 Included in EP (as FMT_SMF.1/IPS
iteration)
FMT_SMR.1 Hierarchical SFR included in EP (as
FMT_SMR.2/IPS iteration)
FMT_SMF.1/IPS No dependencies Not Applicable
FMT_SMR.2/IPS FIA_UID.1 Alternatively met by FIA_UIA_EXT.1
inherited from base PP (which defines
both identification and authentication in a
single SFR)
FPT_FLS.1/Inline No dependencies Not Applicable
FPT_ITT.1 No dependencies Not Applicable
FRU_RSA.1 No dependencies Not Applicable
IPS_ABD_EXT.1 No dependencies Not Applicable
IPS_IPB_EXT.1 No dependencies Not Applicable
IPS_NTA_EXT.1 No dependencies Not Applicable
IPS_SBD_EXT.1 No dependencies Not Applicable
IPS_SBD_EXT.2 IPS_SBD_EXT.1 Included in EP
Page 35 of 47
Appendix B: Optional Requirements
The baseline requirements are contained in the body of this EP. Additionally, there are three other types
of requirements specified in Appendices B, C, and D.
The first type (in this Appendix) are requirements that can be included in the ST, but do not have to be in
order for a TOE to claim conformance to this EP. The second type (in Appendix C) are requirements based
on selections in the body of the EP: if certain selections are made, then additional requirements in that
appendix will need to be included. The third type (in Appendix D) are components that are not required
in order to conform to this EP, but will be included in the baseline requirements in future versions of this
EP, so adoption by IPS vendors is encouraged. Note that the ST author is responsible for ensuring that
requirements that may be associated with those in Appendix B, Appendix C, and/or Appendix D but are
not listed (e.g., FMT-type requirements) are also included in the ST.
B.1 Requirements
The optional security functional requirements are stated in the sections below.
B.1.1 FAU: Security Audit
The term “IPS Data” includes all of the data extracted from network traffic and stored on the TOE; the
results of analysis performed by the TOE; and messages that indicate the TOE’s reaction to that analysis.
This definition of “IPS Data” excludes the “audit data” relevant to the base PP, which includes data defined
in FAU_GEN from the base PP, such as authentication of administrators, and establishment/termination
of trusted channels. If IPS Data review and/or storage and security alarms are supported by the TOE then
the following audit requirements can be included in the ST, as appropriate.
B.1.1.5 FAU_STG.1 Protected Audit Trail Storage (IPS Data)
FAU_STG.1.1 Refinement: The TSF shall protect the stored audit records IPS data from unauthorized
deletion.
FAU_STG.1.2 Refinement: The TSF shall be able to [prevent] unauthorized modifications to the stored
audit records IPS data in the audit trail.
Application Note: There are no additional auditable IPS events that need to be included in
FAU_GEN.1/IPS.
Activity Assurance Activity
TSS The evaluator shall ensure that the TSS identifies how IPS data is protected from
unauthorized modification and deletion.
AGD The evaluator shall confirm the guidance documentation describes how to protect IPS
data from unauthorized modification and deletion.
Test Test 1: The evaluator shall devise tests that demonstrate that IPS data can be protected
from unauthorized modification and deletion.
B.1.1.6 FAU_STG.4 Prevention of Data Loss (IPS Data)
FAU_STG.4.1 Refinement: The TSF shall be able to [selection: “ignore audited generation of IPS events
that would otherwise be generated”, “prevent audited IPS events, except those taken by the authorised
user with special rights”, “overwrite the oldest stored audit records IPS data”], and [no other actions] if
the audit IPS data trail is full.
Auditable Events Additional Audit Record Contents
Page 36 of 47
A local audit store
reaches its storage limit.4
Indication that the audit store is full, and (if configurable) how the TOE is
responding (e.g. failing to audit new auditable events, or preventing
auditable events from occurring).
Activity Assurance Activity
TSS The evaluator shall ensure that the TSS identifies how IPS data logging is handled once
the IPS data trail is full. The TSS shall also identify how IPS data logging is restored.
AGD The evaluator shall confirm the guidance documentation describes the steps involved to
manage IPS data logging when the IPS audit trail is full.
Test There are no test assurance activities for this requirement.
B.1.2 FMT: Security Management Requirements.
If the TOE allows for multiple administration roles, then these requirements can be included in the ST.
B.1.2.1 FMT_MOF.1/IPS Management of Security Functions Behavior
FMT_MOF.1.1/IPS The TSF shall restrict the ability to [modify the behavior of] the functions [IPS data
collection, analysis, and reaction] to [authorized IPS Administrators].
Activity Assurance Activity
TSS The evaluator shall examine the TSS to determine that, for each administrative function
identified in the operational guidance; those that are accessible through an interface prior
to administrator log-in are identified. For each of these functions, the evaluator shall also
confirm that the TSS details how the ability to manipulate the configuration of the system
through this interface is disallowed for non-administrative users.
AGD The evaluator shall review the operational guidance to determine that each of the
functions implemented in response to the requirements of this EP is identified, and that
configuration information is provided to ensure that only administrators have access to
the functions.
Test Testing for this SFR is completed as part of testing the other FMT requirements defined by
this EP.
B.1.2.2 FMT_MTD.1/IPS Management of IPS data
FMT_MTD.1.1/IPS Refinement: The TSF shall restrict the ability to [selection: change_default, query,
modify, delete, clear, [assignment: other operations]] the [assignment: list of TSF IPS data] to [assignment:
the IPS Administrator, IPS Analyst and other IPS-specific roles identified in FMT_SMR.2/IPS].
Application Note: The ST should define which roles are permitted to access the IPS data (IPS Administrator,
IPS Analyst, and other IPS-specific roles identified in FMT_SMR.2/IPS). The ST may define any number of
roles to meet this requirement. There are no additional auditable IPS events that need to be included in
FAU_GEN.1/IPS.
Activity Assurance Activity
TSS The evaluator shall verify that the TSS includes a description of each identified role in
regards to the responsibly of the role and the access permissions associated with that
role on the TOE.
4
The audit event for FAU_STG.4 does not apply to audit stores that overwrite the oldest records when full.
Page 37 of 47
Activity Assurance Activity
AGD The evaluator shall review the operational guidance to ensure that it contains
instructions for configuring authorized administrators restrict the ability for authorized
identified roles in the requirement the and authorized roles.
Test It is not necessary for all operations described in this SFR to be accessible through all TOE
interfaces. In the course of performing the testing activities for the evaluation, the
evaluator shall make use of all interfaces applicable to each administrative function
described in this SFR, although it is not necessary to repeat each test involving an
administrative action with each interface.
Test 1: The evaluator shall demonstrate that after configuring the TOE for first use from
the operational guidance, it is possible to restrict the ability to query and modify IPS Data
using each of the authorized identified roles as defined in the requirement.
B.1.2.3 FMT_SMR.2/IPS Security roles (IPS)
FMT_SMR.2.1/IPS Refinement: The TSF shall maintain the roles: [IPS Administrator, IPS Analyst, and
[selection: [assignment: other authorized IPS roles], no other roles]].
FMT_SMR.2.2/IPS The TSF shall be able to associate users with roles.
FMT_SMR.2.3/IPS The TSF shall ensure that [assignment: conditions for the different roles] are satisfied.
Application Note: The roles defined in this SFR are intended to be specific to management of IPS
functionality. The “Authorized Administrator” role defined in the base PP within FMT_SMR.2 may be the
same role as the “IPS Administrator” defined in this EP, or may be a different role where the Authorized
Administrator has full rights to administer the entire TOE, and the IPS Administrator only has full rights
to IPS-specific functionality. The IPS Analyst role is intended to represent a role that has less than full
rights, or may have limited read-only rights. Other roles can be defined by the ST author. There are no
additional auditable IPS events that need to be included in FAU_GEN.1/IPS.
Activity Assurance Activity
TSS The evaluator shall review the TSS to ensure it describes the distinction between rights of
the IPS Administrator, the IPS Analyst, and any other roles identified in the assignment of
this SFR. The TSS should also describe any distinctions, if any, between the rights of the IPS
Administrator identified in this SFR, and the Authorized Administrator identified in
FMT_SMR.2 of the base PP.
AGD There are no operational guidance assurance activities for this SFR.
Test Since administrative roles are need to view the TSF data, the analysis performed by the
evaluators in the Assurance Activity for FMT_MTD.1 will demonstrate that this
requirement is met.
B.1.3 FPT: Protection of the TSF
B.1.3.1 FPT_FLS.1/Inline Failure with Preservation of Secure State
FPT_FLS.1.1/Inline Refinement: The TSF shall be able to preserve a secure state for inline interfaces when
the following types of failures occur: [assignment: list of types of failures in the TSF].
Application Note: The intent of this SFR in the IPS EP is to allow the ST author to define the types of failures
that can occur on the TOE which could result in failure to effectively detect and react to IPS policy violations
for traffic traversing inline interface, and to not allow traffic to traverse those interfaces. The first
refinement “to be able” is included to allow the TOE administrator to configure the TOE to allow traffic to
Page 38 of 47
traverse inline interfaces, when the TOE is in a partially of fully failed state, but to provide assurance that
the TOE is capable of blocking traffic if it has been configured to do so. The purpose of this SFR, as stated
in CC Part 2, is to “ensure that the TOE will always enforce its SFRs in the event of identified categories of
failures in the TSF.” Since some of the SFRs require inspection of data, and that inspection cannot occur
when a network interface fails, it will not always be true that “all” the SFRs will continue to be enforced in
the event of failure of certain components.
Auditable Events Additional Audit Record Contents
Failure of the TSF. The type of failure that occurred.
Activity Assurance Activity
TSS The evaluator shall review the TSS section to determine that the TOE’s implementation of
the fail secure functionality is documented. The evaluator shall first examine the TSS
section to ensure that all failure modes specified in the ST are described. The evaluator
shall then ensure that the TOE will attain a secure state after inserting each specified
failure mode type. The evaluator shall review the TSS to determine whether the TOE
administrator would be able to configure how the traffic-forwarding will be impacted by
those failures.
AGD There are no operational guidance assurance activities for this SFR.
Test For each type of failure listed in the assignment, the TOE vendor must provide the
evaluator with the means to trigger the failure, and the evaluator must reproduce each
type of failure to ensure that an applied IPS policy remains enforced during the failure.
For example, various causes including temporary loss of power could result in a reboot of
the TOE. If the active IPS policy at the time of the failure (e.g. reboot) ensured that ICMP
echo packets were dropped by the TOE, the evaluator shall confirm that at no point
during the shutdown or restart of the TOE is any ICMP echo packet allowed through the
TOE (though in this example, it should be understood that there will be a period at which
IPS events are not audited while the audit mechanism is pending restart).
B.1.3.2 FPT_ITT.1 Basic Internal TSF Data Transfer Protection
FPT_ITT.1.1 Refinement: The TSF shall protect TSF data from [disclosure, modification] using [selection:
choose one or more of: IPsec, SSH, TLS, HTTPS] when it is transmitted between [assignment: list of
distributed TOE components] separate parts of the TOE.
Application Note: Based on the selections made here, a conformant ST will include one or more of the
FCS_IPSEC_EXT.1, FCS_HTTPS_EXT.1, FCS_SSHC_EXT.1, FCS_SSHS_EXT.1, FCS_TLSC_EXT.1,
FCS_TLSC_EXT.2, FCS_TLSS_EXT.1, and FCS_TLSS_EXT.2 selection-based SFRs that are defined in the base
PPs. A conformant ST will also include the optional O.TRUSTED_COMMUNICATIONS objective.
The manager/host sensor architecture is an acceptable architecture. When this architecture is used, the
manager must comply with the NDcPP or FWcPP as a base, and the sensors must comply with the
Application Software PP as a base. The FPT_ITT requirements apply to sensor/management
communications and would only need to be tested in that context.
Activity Assurance Activity
TSS The evaluator shall examine the TSS to determine that, for all communications between
distributed TOE components identified in the requirement, each communications
mechanism is identified in terms of the allowed protocols for that component. The
Page 39 of 47
Activity Assurance Activity
evaluator shall also confirm that all protocols listed in the TSS are specified and included
in the requirements in the ST.
AGD The evaluator shall confirm that the guidance documentation contains instructions for
establishing the allowed protocols with each TOE component, and that it contains
recovery instructions should a connection be unintentionally broken.
Test The evaluator shall perform the following tests:
Test 1: The evaluator shall ensure that communications using each protocol with each
TOE component is tested during the course of the evaluation, setting up the connections
as described in the guidance documentation and ensuring that communication is
successful.
Test 2: The evaluator shall ensure, for each communication channel between distributed
TOE components, the channel data is not sent in plaintext.
Test 3: The evaluators shall, for each protocol associated with each TOE component
tested during test 1, the connection is physically interrupted. The evaluator shall ensure
that when physical connectivity is restored, communications are appropriately protected.
B.1.4 FRU: Resource Utilization
B.1.4.1 FRU_RSA.1 Maximum Quotas
FRU_RSA.1.1 The TSF shall enforce maximum quotas of the following resources: [resources supporting
inspection of network traffic] that [subjects] can use [simultaneously].
Application Note: Compliant TOEs will impose quotas on exhaustible resources used to support inspection
of network traffic that ‘subjects’ (inspected network traffic flows) can use simultaneously. The intent of
this requirement is to ensure that the TOE is not deployed in such a way that the flow of data across its
sensor interfaces can exceed the amount of traffic that the TOE is capable of inspecting. If the flow
(volume/speed) of data to be inspected exceeds the defined quota, the TOE should trigger an alert
signifying effect of the exceeded quota, for example: when the TOE is deployed inline, exceeding the quota
may result in the TSF dropping (not forwarding) and failing to inspect network traffic; or when the TOE is
not deployed inline, exceeding the quota may result in traffic having been forwarded without inspection.
In any case, exceeding the maximum quota results in a “potential security violation” relevant to FAU_ARP
in that the TSF may have failed to inspect some network traffic.
Auditable Events Additional Audit Record Contents
Traffic flow volume exceeds the maximum
quota.
Identification of the TOE interface at which the quota
was exceeded.
Activity Assurance Activity
TSS The evaluator shall examine the TSS to ensure that it identifies all resources controlled
through the quota mechanism, and that this list contains those resources used to support
traffic inspection. The evaluator shall ensure that the TSS describes how each resource is
counted as “used” and how a maximum quota or use is determined, as well as the action
taken when the quota is reached.
Page 40 of 47
Activity Assurance Activity
AGD The evaluator shall examine the operational guidance to determine that it contains
instructions for establishing quotas (if they are configurable), and describes any actions
administrators can or should take in response to a quota being reached.
Test Test 1: The evaluator follows the operational guidance to configure quotas for the
resource (if such a capability is provided). The evaluator then causes the resource quota to
be reached, and observes that the action specified in the TSS occurs.
B.1.5 IPS: Intrusion Prevention
In the case that the TOE supports the implementation of normalization of network packets, then the
following requirements can be included in the ST.
B.1.5.1 IPS_SBD_EXT.2 Traffic Normalization
IPS_SBD_EXT.2.1: The TSF shall be able to inspect packets encapsulated through the following means:
 [selection: GRE, IP-in-IP, IPv4-in-IPv6, MPLS, PPTP, [assignment: other encapsulation methods], no
other methods]
Activity Assurance Activity
TSS The evaluator shall verify that the TSS describes how the TOE is able to inspect traffic
within inside tunnels defined in the requirement.
AGD The evaluator shall examine the operational guidance to determine that it contains
instructions for inspecting tunneled packets through the encapsulation methods identified
in the requirement.
Test Test 1: The evaluator shall re-run a previous signature-based test within the tunnel
defined in the requirement.
IPS_SBD_EXT.2.2: The TSF shall be able to perform IP normalization to reassemble fragmented packets
for inspection, and: [selection:
 For data collected at promiscuous interfaces: generate an alert if the packet cannot be
reassembled;
 For data collected at inline interfaces: do not forward any packet fragments and generate an alert
if the TSF cannot reassemble the entire packet].
Activity Assurance Activity
TSS The evaluator shall verify that the TSS describes how audit records are generated when
packets cannot be reassembled after fragmentation. Also, for inline mode, the evaluator
shall examine the TSS to ensure packets are dropped.
AGD There are no operational guidance assurance activities for this element.
Test The evaluator shall perform the following tests:
Test 1: The evaluator shall generate packets that cannot be reassembled after
fragmentation; the evaluator shall ensure audit events are generated for all instances of IP
normalization.
Test 2: For inline mode: The evaluator shall test for automatic packet rejection for when
packets cannot be reassembled after fragmentation. The evaluator shall use packet
captures to ensure that the IP traffic is detected by the TOE and packets are dropped.
Page 41 of 47
Activity Assurance Activity
Test 3: The evaluator shall generate packets that can be reassembled after fragmentation;
the evaluator shall ensure audit events are generated for all instances of IP normalization.
IPS_SBD_EXT.2.3: The TSF shall be able to perform TCP normalization for traffic flows through the TOE
when the TOE is deployed in inline mode, and prohibit forwarding of: [selection:
 duplicate packets;
 changed packets;
 out-of-sequence packets;
 [selection: [assignment: other packet types that should not be forwarded], no other packets]]
Activity Assurance Activity
TSS The evaluator shall verify that the TSS describes that packets are automatically dropped for
the following normalization:
 duplicate packets
 changed packets
 Out of sequence packets
 Any other methods defined in the requirement.
AGD There are no operational guidance assurance activities for this element.
Test Test 1: The evaluator shall generate the following types of packets and observe that
packets are dropped:
 Duplicate packets
 Changed packets
 Out of sequence packets
 Any other methods defined in the requirement..
Page 42 of 47
Appendix C: Selection-Based Requirements
As indicated in the introduction to this EP, the baseline requirements (those that must be performed by
the TOE or its underlying platform) are contained in the body of this EP. There are additional
requirements based on selections in the body of the EP; if certain selections are made, then additional
requirements below will need to be included.
C.1 Requirements
The selection-based security functional requirements are stated in the sections below.
C.1.1 FCS: Cryptographic Support
This EP does not define any new selection-based requirements that are not already defined by the NDcPP
or FWcPP. Note however that for each secure communications protocol selected in FPT_ITT.1, a
conformant ST shall include the corresponding selection-based requirements for the selected protocol(s)
that are defined in the NDcPP or FWcPP. The ST author shall clearly identify which of these requirements
apply to the inter-TSF trusted communications as opposed to the trusted channel and path functions that
are defined in the base PP.
Page 43 of 47
Appendix D: Objective Requirements
As indicated in the introduction to this EP, the baseline requirements (those that must be performed by
the TOE or its underlying platform) are contained in the body of this EP. There are additional requirements
that specify security functionality that is desirable and these requirements are contained in this Appendix.
It is expected that these requirements will transition from objective requirements to baseline
requirements in future versions of this EP.
D.1 Requirements
The objective security functional requirements are stated in the sections below.
D.1.1 FAU: Security Audit
The term “IPS Data” includes all of the data extracted from network traffic and stored on the TOE; the
results of analysis performed by the TOE; and messages that indicate the TOE’s reaction to that analysis.
This definition of “IPS Data” excludes the “audit data” relevant to the base PP, which includes data defined
in FAU_GEN from the base PP, such as authentication of administrators, and establishment/termination
of trusted channels. If IPS Data review and/or storage and security alarms are supported by the TOE then
the following audit requirements can be included in the ST, as appropriate.
D.1.1.1 FAU_ARP.1 Security Alarms
FAU_ARP.1.1 The TSF shall take [assignment: list of actions] upon detection of a potential security
violation.
Application Note: In CC Part 2, FAU_ARP is intended to depend on FAU_SAA to define a potential violation
of the SFRs. FAU_SAA is not included in this IPS EP, and FRU_RSA is used instead to define the “potential
security violation” relevant to FAU_ARP, namely that the TOE has experienced a spike in network traffic
that has exceeded its ability to inspect all network traffic, and that event has result in network traffic being
dropped or passed without inspection. This SFR should be used to define actions that the IPS TOE can take
which may include generating one or more messages that are not part of the audit trail that must be
transmitted securely to a remote audit server. Messaging actions defined by this SFR that are not
specifically relevant to FAU_GEN.1/IPS do not need to be encrypted during transit. The primary intent of
this functionality is the speed of notification, not the integrity, or confidentiality of the data in transit. In
most cases, the audit trail applicable to FAU_STG_EXT.1 will be syslog data, and is being protected in
transit to help ensure integrity of remotely stored audit data. This SFR is intended to cover transmission of
messages related to single events through protocols such as SNMP (traps) and SMTP (email). In TOEs that
support securing SNMP traps, SMTP email, or other messaging types within trusted channels (as defined
by FTP_ITC.1), the ST author can choose to list these messaging methods within FTP_ITC.1 and/or within
this SFR. There are no additional auditable IPS events that need to be included in FAU_GEN.1/IPS.
Activity Assurance Activity
TSS The evaluator shall verify that the TSS includes a description of the alerts specified in the
requirement. The evaluator shall also verify that the TSS states that audit data cannot be
transmitted through the security alarms interface.
AGD The evaluator shall verify that the guidance explains how to enable alerts specified in the
requirement as applicable to FRU_RSA.1.
Test Test 1: The evaluator shall devise tests that demonstrate that transmission of messages
related to single events through the defined actions. Note that this activity can be
Page 44 of 47
Activity Assurance Activity
addressed with a combination of the test assurance activities for IPS_ABD_EXT.1,
IPS_SBD_EXT.1, and FRU_RSA.1.
D.1.1.2 FAU_SAR.1 Audit Review (IPS Data)
FAU_SAR.1.1 Refinement: The TSF shall provide [authorized administrators] with the capability to read
[IPS data] from the audit records IPS events.
FAU_SAR.1.2 Refinement: The TSF shall provide the audit records IPS data in a manner suitable for the
user administrators to interpret the information.
Application note: It is anticipated, but not required, that TOEs would provide a graphical user interface
that would allow searching and sorting, and it would be acceptable for such output to group similar events
together to ease administrative review of the IPS data. For example, the display might allow grouping of
data by event type, or by source IP address, where multiple events that occurred in a time period are
displayed on a single line as in the sample table below. Regardless whether such a view is provided, it is
expected that the administrator will be able to view the details of individual event occurrences. There are
no additional auditable IPS events that need to be included in FAU_GEN.1/IPS.
Table D-1: Table of Events (some examples inserted)
Time/Date Event Type Reaction Event total
2013-01-1 10:45:00 Port scan from 10.1.2.3 Blocked all traffic from 10.1.2.3 34
Activity Assurance Activity
TSS The evaluator shall examine the TSS to verify that it describes the ability of administrators
to view IPS data from the IPS events, the format in which this IPS data is displayed, and
how an administrator is authorized to view this data.
AGD The evaluator shall examine the operational guidance to verify that it provides
instructions on how to access and interpret IPS events using the TOE’s management
interface.
Test Test 1: The evaluator shall devise tests that demonstrate that IPS data (generated as
defined in FAU_GEN) can be interpreted by authorized administrators from the TOE’s
management interface.
D.1.1.3 FAU_SAR.2 Restricted Audit Review (IPS Data)
FAU_SAR.2.1 Refinement: The TSF shall prohibit all users administrators read access to the audit records
IPS data, except those that have been granted explicit read-access.
Application Note: There are no additional auditable IPS events that need to be included in
FAU_GEN.1/IPS.
Assurance Activity
Since administrative roles are needed to view the IPS data, the analysis performed by the evaluators in
the Assurance Activity for FMT_MTD.1/IPS will demonstrate that this requirement is met.
D.1.1.4 FAU_SAR.3 Selectable Audit Review (IPS Data)
FAU_SAR.3.1 Refinement: The TSF shall provide the ability to apply [filtering and sorting] of audit IPS data
based on [filtering parameters: risk rating, time period, source IP address, destination IP address and
Page 45 of 47
[selection: [assignment: other filtering parameters]; no other filtering parameters]; and sorting
parameters: event ID, event type, time, signature ID, IPS actions performed, and [selection: [assignment:
other sorting parameters; no other sorting parameters]].
Application Note: There are no additional auditable IPS events that need to be included in
FAU_GEN.1/IPS.
Activity Assurance Activity
TSS The evaluator shall verify that the TSS includes a description of how the TOE has the
ability to apply filtering and sorting of IPS data using the parameters listed in the
requirement.
AGD The evaluator shall review the administrative guidance to ensure that the guidance
itemizes all event types, as well as describes all attributes that are to be selectable in
accordance with the requirement, to include those attributes listed in the assignment.
The administrative guidance shall also contain instructions on how to set the pre-
selection, as well as explain the syntax (if present) for multi-value pre-selection. The
administrative guidance shall also identify those audit records that are always recorded,
regardless of the selection criteria currently being enforced.
Test The evaluator shall perform the following tests:
Test 1: For each attribute listed in the requirement, the evaluator shall devise a test to
show that selecting the attribute causes only audit events with that attribute (or those
that are always recorded, as identified in the administrative guidance) to be recorded.
Test 2 [conditional]: If the TSF supports specification of more complex audit pre-selection
criteria (e.g., multiple attributes, logical expressions using attributes) then the evaluator
shall devise tests showing that this capability is correctly implemented. The evaluator
shall also, in the test plan, provide a short narrative justifying the set of tests as
representative and sufficient to exercise the capability.
Page 46 of 47
Appendix E: Definitions
E.1 Definitions of Attacks
Title Description
DoS Denial of Service
Flooding Causing an excessive amount of traffic on an IP subnet or targeted against a
specific IP address.
IP Impossible Packet
(Land)
IP packet detected with source equal to destination address (Land Attack).
IP options
Bad Option List
IP datagram where the list of IP options in the IP datagram header is
incomplete or malformed.
IP options
Record Packet Route
IP datagram where the IP option list for the datagram includes option 7
(Record Packet Route).
IP options
Timestamp
IP datagram where the IP option list for the datagram includes option 4
(Timestamp).
IP options
Security
IP datagram where the IP option list for the datagram includes option 2
(Security options).
IP options
Loose Source Route
IP datagram where the IP option list for the datagram includes option 3
(Loose Source Route).
IP options
Strict Source Route
IP datagram in which the IP option list for the datagram includes option 2
(Strict Source Routing).
IP Overlapping
Fragments (Teardrop,
Bonk)
Two fragments contained within the same IP datagram have offsets that indicate
that they share positioning within the datagram. This could mean that fragment A is
being completely overwritten by fragment B, or that fragment A is partially being
overwritten by fragment B.
ICMP fragments
(Ping of Death, Nuke)
IP datagram with the protocol field of the IP header set to 1(ICMP), the Last
Fragment bit is set, and ( IP offset * 8 ) + ( IP data length) > 65535. The IP
offset (which represents the starting position of this fragment in the original
packet, and which is in 8 byte units) plus the rest of the packet is greater
than the maximum size for an IP packet.
ICMP flooding (Smurf,
ping flood)
The destination IP address in the packet is the broadcast address of the
destination subnet so all machines on that subnet respond to the broadcast.
Scanning (IP protocols,
TCP ports, UDP ports)
Attempting to determine whether any listening services exist on specific IP
protocol numbers, TCP ports, or UDP ports by transmitting traffic to
generate an expected response.
TCP FIN only flags Orphaned TCP FIN packet is sent to a privileged port (port number less than
1024).
TCP flood (SYN flood) Sending an excessive number of TCP packets with the SYN flag set in order to
exhaust the target hosts limit of half-open TCP sessions.
TCP NULL flags TCP packet with none of the SYN, FIN, ACK, or RST flags set has been sent to
a specific host.
TCP SYN+FIN flags TCP packet with the SYN and FIN flags are set.
UDP Bomb attack UDP length specified is less than the IP length specified. This malformed packet type
is associated with a denial of service attempt.
UDP Chargen DoS
attack
UDP packet is detected with a source port of 7 and a destination port of 19.
Page 47 of 47
E.2 Definitions of Terms and Acronyms
Title Description
Anomaly / Anomalous
(network traffic)
Traffic that does not fit into a defined baseline and is therefore unexpected
or atypical traffic. Anomalous traffic is not necessarily dangerous, and does
not necessarily indicate any threat to the monitored network.
Baseline / Base-lining
(network traffic)
Defining what is to be considered expected or typical network traffic on a
monitored network. A traffic baseline does not indicate that all traffic that
matches the baseline is safe, or that the traffic is not a potential threat to
the monitored network. For example: traffic that matches a baseline can
still match a list of known-bad IP addresses; or can match signatures of
known threats.
Inline mode The deployment of the TOE (or TOE component) such that monitored
network traffic must flow across the TOE, thus providing the TOE with the
opportunity to block the traffic.
IPS Intrusion Prevention System
IPS policy Any set of rules for traffic analysis, traffic blocking, signature detection,
and/or anomaly detection. Many IPS policies could be defined and stored
on the TOE, but an IPS policy will not have any affect unless is applied to
(made active on) one or more IPS interfaces.
Normalization (of
network traffic)
Filtering of network traffic such that only the useful packets/fragments are
allowed through to the destination. Normalization can only be performed
by the TOE when the TOE is deployed in inline mode. Normalization can
include filtering out any of
duplicate packets; fragments that cannot be re-assembled, packets
determined to be invalid such as with invalid checksums, out-of-sequence
packets, etc.
Profiling (network
traffic)
See base-lining.
Promiscuous mode The state of an IPS interface in which it’s listening (collecting and
inspecting) network traffic. A promiscuous interface could be one that is
only listening and never transmitting traffic, or could be an interface
through which traffic flows both inbound and outbound as in an inline
mode deployment.
Sensor interface Any interface of the TOE that has an IPS policy applied to it.