The scope of this PP-Module is to describe the security functionality of an Intrusion Prevention System
(IPS) in terms of [CC] and to define functional and assurance requirements for such products. This PP-Module is intended for use with the following Base-PPs:
Network Device collaborative Protection Profile Version 4.0
This Base-PP is valid because a device that implements IPS is a specific type of network device, and there is nothing about the implementation of IPS that would prevent any of the security capabilities defined by the Base-PP from being satisfied.
A TOE that conforms to a PP-Configuration containing this PP-Module may be a ‘Distributed TOE’ as defined in the NDcPP. For example, the TOE could have distributed ‘sensor’ components monitoring various logically separated networks, each of which reports to a centralized ‘manager’ component for
configuration of IPS policies and aggregation of IPS data.
1.2 Terms
The following sections list Common Criteria and technology terms used in this document.
1.2.1 Common Criteria Terms
Assurance
Grounds for confidence that a TOE meets the SFRs [CC].
Base Protection Profile (Base-PP)
Protection Profile used as a basis to build a PP-Configuration.
Collaborative Protection Profile (cPP)
A Protection Profile developed by
international technical communities and approved by multiple schemes.
Common Criteria (CC)
Common Criteria for Information Technology Security Evaluation (International Standard ISO/IEC 15408).
Common Criteria Testing Laboratory
Within the context of the Common Criteria Evaluation and Validation Scheme (CCEVS), an IT security evaluation facility
accredited by the National Voluntary Laboratory Accreditation Program (NVLAP) and approved by the NIAP Validation Body to conduct Common Criteria-based evaluations.
Common Evaluation Methodology (CEM)
Common Evaluation Methodology for Information Technology Security Evaluation.
Distributed TOE
A TOE composed of multiple components operating as a logical whole.
Functional Package (FP)
A document that collects SFRs for a particular protocol, technology,
or functionality.
Operational Environment (OE)
Hardware and software that are outside the TOE boundary that support the TOE functionality and security policy.
Protection Profile (PP)
An implementation-independent set of security requirements for a category of products.
A comprehensive set of security requirements for a product type that consists of at least one Base-PP and at least one PP-Module.
Protection Profile Module (PP-Module)
An implementation-independent statement of security needs for a TOE type complementary to one or more Base-PPs.
Security Assurance Requirement (SAR)
A requirement to assure the security of the TOE.
Security Functional Requirement (SFR)
A requirement for security enforcement by the TOE.
Security Target (ST)
A set of implementation-dependent security requirements for a specific product.
Target of Evaluation (TOE)
The product under evaluation.
TOE Security Functionality (TSF)
The security functionality of the product under evaluation.
TOE Summary Specification (TSS)
A description of how a TOE satisfies the SFRs in an ST.
1.2.2 Technical Terms
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.
Flooding
Causing an excessive amount of traffic on an IP subnet or targeted against a specific IP address.
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.
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.
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 type of 'known-good' traffic that is expected to be present on the network and therefore not considered to be an indicator of potential intrusion.
Profiling (network traffic)
See base-lining.
Promiscuous mode
The state of an IPS interface in which it is 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.
1.3 Compliant Targets of Evaluation
This PP-Module specifically addresses network-based IPSs. A conformant IPS is a product that is connected
to one or more distinct networks and is managed as part of an overall enterprise 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 PP-Module 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 PP-Module
and to allow future PP-Modules to address other IPS and functionality that includes scanners, analyzers,
sensors, etc. The scope of the PP-Module does not preclude support for inspection of other IP protocols
(e.g. GRE, ESP, AH), but the scope of this PP-Module does not include the evaluation of non-IP protocols
including layer 2 protocols, or Ethernet.
The baseline requirements of this PP-Module 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 IPSTOEs 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.1 of the NDcPP.
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 IPSTOE and an Intrusion Detection System (IDS), but there
are some important distinctions. The conformant IPSTOE 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 is 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 security 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.
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 NDcPP guidance on the handling of
distributed TOEs applies. This PP-Module does not mandate that specific SFRs be assigned to specific
components in a distributed TOE; however, it is expected that any TOE component that enforces any IPS
function must enforce all dependent functionality for management and audit at minimum
Deployment scenarios supported by the TOE include those shown in Figure 1, which includes a number of
possible deployments or use cases for IPS functionality within a single network. Note that this is just an
example of an IPS deployment where individual devices implement specific IPS functionality differently;
per the requirements in this PP-Module (specifically IPS_NTA_EXT.1), a conformant TOE must implement
both promiscuous and inline mode interfaces, though it is not a requirement for every TOE component to
implement both modes.
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.
The physical boundary for a TOE that conforms to this PP-Module is a physical or virtual network device,
that also provides generalized network device functionality, such as auditing, I&A, and cryptographic
services for network communications. The TOE may be standalone or distributed, where a distributed TOE
is one that requires multiple distinct components to operate as a logical whole in order to fulfill the
requirements of this PP-Module. The TOE’s logical boundary includes all functionality required by the
Base-PP as well as the IPS functionality and related capabilities that are defined in this PP-Module. Any
functionality that is provided by the network device that is not relevant to the security requirements
defined by this PP-Module or the Base-PP is considered to be outside the scope of the TOE.
1.5 Use Cases
This PP-Module defines two potential use cases for the IPSTOE, listed below.
This PP-Module also defines optional and objective requirements for functionality including separation of
management roles and ability to use the TSF to review collected IPS data. These functions are not
dependent on a particular use case being chosen.
[USE CASE 1] Standalone System
The TOE exists as a standalone device that is capable of enforcing all of the mandatory requirements
defined in this PP-Module by itself.
[USE CASE 2] Distributed System
The TOE exists as a distributed system that is able to apply different IPS functions to different network
segments. In this case, distributed nodes may each implement all required IPS functionality, or
different node types may offer different functions so long as the evaluated configuration collectively
addresses all of the mandatory requirements defined in this PP-Module. In this deployment, it is
expected (though not required) that a single device be used as a central point to perform
configuration and collect relevant log data for the rest of the TOE.
1.6 Implementation-Based Features
The following features of the TOE are implementation-based. A TOE is not required to implement these features to conform to this PP-Module, but if the feature is implemented, it is expected that associated implementation-based requirements are claimed as part of the TSF.
1.6.1 Support for Alerting
The TOE implements the capability to alert administrators when a potential security incident has occurred.
If this feature is implemented by the TOE, the following requirements must be claimed in the ST:
This section contains the expectations for the evaluator test environment that is used to perform the
test specified by the EAs.
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 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
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.
Figure 2:
Sample Inline Mode Test Topology
Figure 3:
Sample Promiscuous Mode Test Topology
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.
2 Conformance Claims
Conformance Statement
An ST must claim exact conformance
to this PP-Module.
The evaluation methods used for evaluating the TOE are a combination of the workunits
defined in [CEM] as well as the Evaluation Activities for ensuring that individual SFRs
and SARs have a sufficient level of supporting evidence in the Security Target and guidance
documentation and have been sufficiently tested by the laboratory as part of completing
ATE_IND.1. Any functional packages this PP claims similarly contain their own Evaluation
Activities that are used in this same manner.
CC Conformance Claims
This PP-Module is conformant to
Part 2 (extended)
and Part 3 (conformant)
of Common Criteria CC:2022, Revision 1.
PP Claim
This PP-Module does not claim conformance to
any Protection Profile.
Network Device collaborative Protection Profile Version 4.0
collaborative Protection Profile Module for Stateful Traffic Filter Firewalls
v2.0
PP-Module for Virtual Private Network (VPN) Gateways, Version 2.0
Package Claim
This PP-Module is not conformant to any
Functional or Assurance Packages.
3 Security Problem Definition
The security problem is described in terms of the threats that the TOE is expected to address, assumptions
about its operational environment, and any organizational security policies that the TOE is expected to
enforce.
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, 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 PP-Module 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 PP-Module 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 PP-Module does not repeat the threats identified in the NDcPP, though they all apply given
the conformance and hence dependence of this PP-Module on the NDcPP.
The NDcPP contains only threats to the ability of the TOE to provide its own functions. This PP-Module
defines threats to resources in the operational environment that will be mitigated by an IPSTOE. Together,
the threats of the Base-PP and those defined in this PP-Module define the comprehensive set of security
threats addressed by an IPSTOE.
3.1 Threats
The following threats defined in this PP-Module extend the threats defined by the Base-PP.
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_DISCLOSURE
A malicious actor could gain access to sensitive information on a protected network that was disclosed as a result of ingress- or egress-based actions.
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.
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.UNAUTHORIZED_ADMINISTRATION
(from NDcPP)
T.UNDETECTED_ACTIVITY
(from NDcPP)
3.2 Assumptions
These assumptions are made on the Operational Environment (OE) in order to be able to ensure that the
security functionality specified in the PP-Module can be provided by the TOE.
If the TOE is placed in an OE that does not meet these assumptions, the TOE may no longer be able to
provide all of its security functionality.
All assumptions for the operational environment of the Base-PP also apply to this PP-Module.
A.NO_THRU_TRAFFIC_PROTECTION is still operative, but only for the interfaces in the TOE that are
defined by the Base-PP and not the PP-Module.
The following additional assumption is made on the operational environment in order to be able to
ensure that the security functionality specified in the PP-Module can be provided by the TOE. If the TOE
is placed in an operational environment that does not meet this assumption, the TOE may no longer be
able to provide all of its security functionality.
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.
3.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.
P.ANALYZE
Analytical processes and information to derive conclusions about potential intrusions must be applied to IPS data and appropriate response actions taken.
4 Security Objectives
4.1 Security Objectives for the Operational Environment
All objectives for the operational environment of the Base-PP also apply to this PP-Module.
OE.NO_THRU_TRAFFIC_PROTECTION is still operative, but only for the interfaces in the TOE that are
defined by the Base-PP and not the PP-Module.
This PP-Module defines the following additional environmental security objectives, which extend those
defined in the Base-PP.
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.
4.2 Security Objectives Rationale
This section describes how the assumptions and organizational
security policies map to operational environment security objectives.
The objective supports the
assumption by setting the
expectation that
administrators will deploy the
TOE in such a manner that
there is no network path that
will be exempt from the TOE’s
inspection capabilities.
The operational environment's ability to facilitate network connections is necessary for the policy to analyze the network traffic associated with these connections.
5 Security Requirements
This chapter describes the security requirements which have to be fulfilled by the product under evaluation.
Those requirements comprise functional components from Part 2 and assurance components from Part 3 of
[CC].
The following conventions are used for the completion of operations:
Refinement operation (denoted by bold text or strikethrough
text): Is used to add details to a requirement or to remove part of the requirement that is made irrelevant
through the completion of another operation, and thus further restricts a requirement.
Selection (denoted by italicized text): Is used to select one or more options
provided by the [CC] in stating a requirement.
Assignment operation (denoted by italicized text): Is used to assign a
specific value to an unspecified parameter, such as the length of a password. Showing the
value in square brackets indicates assignment.
Iteration operation: Is indicated by appending the SFR name with a slash and unique identifier
suggesting the purpose of the operation, e.g. "/EXAMPLE1."
5.1 Collaborative
Protection Profile for Network Devices
Security Functional Requirements Direction
In a PP-Configuration that includes the NDcPP, the TOE is expected to rely on some of the security
functions implemented by the network device as a whole and evaluated against the Base-PP. However,
this PP-Module does not change how any of the NDcPP functions are implemented so there is no
modification to the NDcPP SFRs used with this PP-Module. Note in particular that requirements that apply
to distributed TOEs (e.g. FCO_CPC_EXT.1, FPT_ITT.1) remain optional as this PP-Module supports but does
not mandate a distributed deployment.
5.1.1 Modified SFRs
This PP-Module does not modify any SFRs defined by the NDcPP.
5.2 TOE Security Functional Requirements
The following section describes the SFRs that must be satisfied by any TOE that claims conformance to this PP-Module.
These SFRs must be claimed regardless of which PP-Configuration is used to define the TOE.
5.2.1 Auditable Events for Mandatory SFRs
Table 2: Auditable Events for Mandatory Requirements
Totals of similar events occurring within a specified time period;
Totals of similar reactions occurring within a specified time period;
The events in the Auditable Events for Mandatory SFRs table (Table 2);
[selection: no other auditable events, Auditable events listed in the Auditable Events for Optional SFRs table (Table 7) for SFRs that are present in the ST, Auditable events listed in the Auditable Events for Objective SFRs
table (Table 8) for SFRs that are present in the ST, Auditable events listed in the Auditable Events for Implementation-dependent SFRs table (Table 9) for SFRs that are present in the ST]].
Application
Note:
This SFR exists in addition to the FAU_GEN.1 SFR in the Base-PP. All required
auditable events from the Base-PP still apply. As the data that this SFR addresses
is still considered to be “audit data,” the requirement for secure remote
transmission per FAU_STG.1 applies to this SFR in the same manner as the
Base-PP’s iteration of FAU_GEN.1.
The ST author is not limited to the list presented and should update the list of
auditable events with any additional information generated. The ST Author
should use FAU_GEN.1 as defined in the Base-PP for standard (non-IPS data)
audit functions.
For all requirements marked as optional, it is expected that if the requirement is
claimed, the corresponding IPS events should be generated by the TSF; if the
requirement is not claimed, then the ST author may also omit these events.
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).
The TSF shall record within the IPS audit data at least the following information:
Date and time of the event, type of event and/or reaction,subject identity, and the outcome (success or failure) of the event; and;
For each IPS auditable event type, based on the auditable event definitions
of the functional components included in the PP, PP-Module, functional package, or ST, [information specified in column three of the Auditable Events for Mandatory SFRs table (Table 2), [selection: no other auditable events, additional information in column three of the Auditable Events for Optional SFRs table (Table 7) for SFRs that are present in the ST, additional information in column three of the Auditable Events for Objective SFRs
table (Table 8) for SFRs that are present in the ST, additional information in column three of the Auditable Events for Implementation-dependent SFRs table (Table 9) for SFRs that are present in the ST]].
Application
Note:
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.
The ST author should update IPS Events table below with any additional
information generated such as source and destination addresses, IP, signature
that triggered event, port, etc.
5.2.3 Security Management (FMT)
FMT_SMF.1/IPS Specification of Management Functions (IPS)
The TSF shall support the definition of [selection: 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:
[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 one hour. 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.
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 is not essential for the IPSTOE to have a capability
of “profiling” a network to dynamically defining a baseline or rule; if the product
has this functionality, it is outside the scope of this PP-Module.
The TSF shall support configuration and implementation of known-good and known-bad lists of [selection: source, destination] IP addresses and [selection: no additional address types,
[assignment:
list of address types]].
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 PP-Module is limited to
inspection of IP traffic. IPSTOEs are not prohibited from enabling functionality
that would allow/prohibit traffic flow based on other address types, such as
MAC addresses.
The TSF shall allow [security administrators] 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].
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 PP-Module.
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.
The TSF shall allow the signatures to be assigned to sensor interfaces configured for promiscuous mode and to sensor interfaces configured for inline mode, and to
support designation of one or more interfaces as being used as a management interface for communication between the TOE and external entities without simultaneously
being a sensor interface, as indicated by the following interface types:
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].
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.
The TSF shall support inspection of packet header contents and be able to inspect at least the following header fields:
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]]
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:
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 IPSTOEs 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 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 PP-Module. Instead, this PP-Module 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.
The TSF shall allow the following operations to be associated with signature-based IPS policies:
In any mode, for any sensor interface: [selection:
allow the traffic flow;
send a TCP reset to the source address of the offending traffic;
send a TCP reset to the destination address of the offending traffic;
send an ICMP[selection: host, destination, port]unreachable message;
trigger a non-TOE network device to block the offending traffic pattern
]
In inline mode:
block/drop the traffic flow;
and [selection:
allow all traffic flow;
allow the traffic flow with following exceptions:[assignment:
malicious traffic such as but not limited to IPS_EXT.1.3 and IPS_EXT.1.4 if always dropped];
modify and forward packets before they pass through the TOE
].
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 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.).
This requirement mitigates the threat of network access by defining the network traffic the TSF is able to examine to determine the potential realization of a threat.
This requirement mitigates the threat by allowing for detection of potential malicious network activity that would otherwise be undetected because of its fragmentation across multiple packets.
This requirement mitigates the threat of network disclosure by providing a mechanism to restrict ingress and egress of network traffic by source or destination.
This requirement mitigates the threat of network disclosure by defining the network traffic the TSF is able to examine to determine the potential realization of a threat.
This requirement mitigates the threat of network denial of service by providing a means to detect network traffic signatures that are indicative of attempts to establish insecure or otherwise malformed sessions over a trusted protocol.
This requirement mitigates the threat by allowing for detection of potential malicious network activity that would otherwise be undetected because of its fragmentation across multiple packets.
This requirement mitigates the threat of network denial of service by providing a mechanism to restrict network traffic that originates from a particular source.
This requirement mitigates the threat of network denial of service by defining the network traffic the TSF is able to examine to determine the potential realization of a threat.
This requirement mitigates the threat of network denial of service by providing a means to detect network traffic signatures that are indicative of denial of service attempts.
This requirement mitigates the threat by allowing for detection of potential malicious network activity that would otherwise be undetected because of its fragmentation across multiple packets.
This requirement mitigates the threat of network misuse by providing a mechanism to restrict network traffic that originates from within a protected network and is bound for an untrusted source, which may indicate compromise or misuse of a protected resource.
This requirement mitigates the threat of network misuse by defining the network traffic the TSF is able to examine to determine the potential realization of a threat.
This requirement mitigates the threat by allowing for detection of potential malicious network activity that would otherwise be undetected because of its fragmentation across multiple packets.
This requirement mitigates the threat of undetected actions by ensuring that records of stored IPS data cannot be read without authorization or modified by any subject so as not to falsely disclose the history of activity observed on the network.
This requirement mitigates the threat of undetected actions by providing a predictable mechanism for how storage of IPS data is prioritized in the event that insufficient storage is available, allowing for the administrator to have adequate warning of the limitations of the collection process.
This requirement mitigates the threat of undetected actions by implementing a mechanism that allows the TSF to fail closed so that network traffic is not transmitted without inspection in the event that its inspection functionality is unavailable.
This requirement mitigates the threat of undetected actions by generating an alert in response to the detection of suspicious network events, allowing for timely analysis of potential threats.
This requirement mitigates the threat of undetected actions by providing authorized subjects with a means to review stored IPS data for detection of potential threats.
This requirement mitigates the threat of undetected actions by enforcing restrictions on the subjects that can review stored network data so that this is not disclosed to untrusted or potentially malicious subjects.
This requirement mitigates the threat of undetected actions by enforcing network traffic quotas so that network traffic is not transmitted through the TOE without analysis.
6 Consistency Rationale
6.1 Collaborative
Protection Profile for Network Devices
6.1.1
Consistency of TOE Type
When this PP-Module is used to extend the NDcPP, the TOE type for the overall TOE is still a network
device. The TOE boundary is simply extended to include IPS functionality that is provided by the network
device.
6.1.2
Consistency of Security Problem Definition
The threats defined by this PP-Module (see section 3.1) supplement those defined in the NDcPP as follows:
Table 4: Consistency of Security Problem Definition (NDcPP base)
The NDcPP only defines a security problem that relates to network traffic
bound to or originating from the TOE. This PP-Module expands the security
problem to include a logical interface for network traffic between two non-TOE endpoints that is intercepted (inline) or observed (promiscuous) by the
TSF. This is not inconsistent because the PP-Module introduces a new logical
interface for this functionality that is beyond the scope of the NDcPP.
The NDcPP only defines a security problem that relates to network traffic
bound to or originating from the TOE. This PP-Module expands the security
problem to include a logical interface for network traffic between two non-TOE endpoints that is intercepted (inline) or observed (promiscuous) by the
TSF. This is not inconsistent because the PP-Module introduces a new logical
interface for this functionality that is beyond the scope of the NDcPP.
The NDcPP only defines a security problem that relates to network traffic
bound to or originating from the TOE. This PP-Module expands the security
problem to include a logical interface for network traffic between two non-TOE endpoints that is intercepted (inline) or observed (promiscuous) by the
TSF. This is not inconsistent because the PP-Module introduces a new logical
interface for this functionality that is beyond the scope of the NDcPP.
The NDcPP only defines a security problem that relates to network traffic
bound to or originating from the TOE. This PP-Module expands the security
problem to include a logical interface for network traffic between two non-TOE endpoints that is intercepted (inline) or observed (promiscuous) by the
TSF. This is not inconsistent because the PP-Module introduces a new logical
interface for this functionality that is beyond the scope of the NDcPP.
The NDcPP only defines a security problem that relates to network traffic
bound to or originating from the TOE. This PP-Module expands the security
problem to include a logical interface for network traffic between two non-TOE endpoints that is intercepted (inline) or observed(promiscuous) by the
TSF. This is not inconsistent because the PP-Module introduces a new logical
interface for this functionality that is beyond the scope of the NDcPP.
This assumption requires a specific network configuration to ensure that
network traffic cannot be routed in a way that allows it to bypass the TOE’s
inspection interfaces. This does not interfere with any of the assumptions in the NDcPP because the NDcPP doesn’t make any assumptions about the
TOE’s position in a network architecture.
This organizational security policy does not conflict with the NDcPP because
it sets expectations for administrative use of the data that is specifically
collected by the TOE’s IPS function.
6.1.3
Consistency of OE Objectives
The objectives for the TOE’s operational environment are consistent with the NDcPP based on the following rationale:
Table 5: Consistency of OE Objectives (NDcPP base)
This objective expects the TOE to be deployed in a network architecture that
insures that network traffic cannot be routed in a way that allows it to
bypass the TOE’s inspection interfaces. This does not interfere with any of
the environmental objectives in the NDcPP because the NDcPP doesn’t have
any objectives that relate to the TOE’s position in a network architecture.
6.1.4
Consistency of Requirements
This PP-Module identifies several SFRs from the
NDcPP that are needed to support
IPS functionality.
This is considered to be consistent because the functionality provided by the
NDcPP is being used for its intended purpose.
The rationale for why this does not conflict with the claims
defined by the
NDcPP are as follows:
The PP-Module iterates an SFR defined in the Base-PP to define additional
audit events specific to IPS functionality that the IPS part of the TOE must
generate.
The PP-Module iterates an SFR defined in the Base-PP to define additional
management functions specific to the IPS functionality that the IPS part of the TOE must generate. Authorizations to perform these functions are based
on FMT_SMR.2 defined by the Base-PP.
This SFR applies to secure failure for inline interfaces, which is a type of
logical interface that was introduced in this PP-Module and therefore
doesn’t interfere with the Base-PP.
This SFR applies to quota enforcement on network interfaces that perform
scanning of network traffic for enforcement of IPS requirements. This
functionality was introduced in this PP-Module and therefore doesn’t
interfere with the Base-PP.
Indication that the audit store is full, and (if configurable) how the TOE is responding (e.g., failing to audit new auditable events, removing old audit events to make space for new events, preventing auditable events from occurring).
The TSF shall
[[selection: ignore generation of IPS events that would otherwise be generated, prevent audited IPS events, overwrite the oldest stored IPS data]] if the IPS audit data storage is full.
A.1.3 Protection of the TSF (FPT)
FPT_FLS.1/IPS Failure with Preservation of Secure State
The TSF shall 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 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
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. The intent here is to ensure that if network traffic is not
capable of being inspected by the TSF, then it should automatically be treated
as untrusted.
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]].
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]
].
A.2 Objective Requirements
A.2.1 Auditable Events for Objective SFRs
All objective SFRs need a review to determine if they should change status with the new release of this module.
Table 8: Auditable Events for Objective Requirements
The TSF shall take [assignment:
list of actions] upon detection of potential security violation.
Application
Note:
At minimum, the set of potential security violations must include network traffic
in excess of maximum quotas. Therefore, when this SFR is included, the ST author
must also include FRU_RSA.1.
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; FRU_RSA and the
various IPS class requirements are used instead to define the “potential security
violation” relevant to FAU_ARP, namely that the TOE has detected potential
malicious network traffic or has experienced a spike in network traffic that has
exceeded its ability to inspect all network traffic which may result in some network
traffic being uninspected by the TSF. This SFR should be used to define actions that
the IPSTOE 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.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.
The TSF shall provide the IPS audit data in a manner suitable for the user 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.
The TSF shall provide the ability to apply [filtering and sorting] of IPS audit data
based on [filtering parameters: risk rating, time period, source IP address,
destination IP address and [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]].
A.3 Implementation-dependent Requirements
A.3.1 Auditable Events for Implementation-Dependent SFRs
The TSF shall enforce maximum quotas of the following resources: [resources
supporting inspection of network traffic] that [subjects] can use [simultaneously].
Application
Note:
This SFR is optional but the behavior specified by FAU_ARP.1 requires this function
to be implemented. Therefore, this SFR is implementation-dependent on the
condition that it be claimed if FAU_ARP.1 is claimed. If FAU_ARP.1 is not claimed
this SFR should also not be claimed because effective enforcement of maximum
quotas requires an alert mechanism when quotas are exceeded. Otherwise it is
not possible for an administrator to determine whether a lack of potential security
violations is caused by an absence of potential malicious activity or by the inability
of the TSF to detect such activity due to an inability to process the volume of traffic
being received.
Conformant 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.1 in that the TSF may have failed to
inspect some network traffic.
Appendix B - Selection-based Requirements
This PP-Module does not define any
Selection-based SFRs.
Appendix C - Extended Component Definitions
This appendix contains the definitions for all extended requirements specified in the PP-Module.
C.1 Extended Components Table
All extended components specified in the PP-Module are listed in this table:
Intrusion prevention involves the TOE’s ability to collect network packets, examine their contents for
information that suggests malicious activity, and to perform some action in response such as terminating
the connection.
This family defines requirements for detection of anomalous network traffic and how the TSF should
respond if an anomaly is detected.
Component Leveling
IPS_ABD_EXT.1,
Anomaly-Based IPS Functionality,
requires the TSF to detect anomalous network traffic
based on some criteria and to define the response that is issued if an anomaly is detected.
Management: IPS_ABD_EXT.1
The following actions could be considered for the management functions in FMT:
Configuration of anomaly detection.
Enabling and disabling actions to be taken when anomaly matches are detected.
Modification of thresholds that trigger IPS reactions.
Modification of the duration of traffic blocking actions.
Audit: IPS_ABD_EXT.1
The following actions should be auditable if FAU_GEN Security audit data generation is included in the
PP/ST:
Inspected traffic that matches an anomaly-based IPS policy.
The TSF shall support the definition of [selection: 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:
[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]].
IPS_ABD_EXT.1.2
The TSF shall support the definition of anomaly activity through [selection: manual configuration by administrators, automated configuration].
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:
allow the traffic flow
send a TCP reset to the source address of the offending traffic
send a TCP reset to the destination address of the offending traffic
send an ICMP
[selection: host, destination, port]
unreachable message
trigger a non-TOE network device to block the offending traffic pattern
]
In inline mode:
allow the traffic flow
block/drop the traffic flow
and
[selection: modify and forward packets before they pass through the TOE, no other actions].
C.2.1.2 IPS_IPB_EXT IP Blocking
Family Behavior
This family defines requirements for handling of inspected network traffic based on IP address.
Component Leveling
IPS_IPB_EXT.1,
IP Blocking,
requires the TSF to enforce IPS policies that are based on IP address.
Management: IPS_IPB_EXT.1
The following actions could be considered for the management functions in FMT:
Modification of the known-good and known-bad lists (of IP addresses or address ranges).
Configuration of the known-good and known-bad lists to override signature-based IPS policies.
Audit: IPS_IPB_EXT.1
The following actions should be auditable if FAU_GEN Security audit data generation is included in the
PP/ST:
Inspected traffic matches a list of known-good or known-bad addresses applied to an IPS policy.
The TSF shall support configuration and implementation of known-good and known-bad lists of [selection: source, destination] IP addresses and [selection: no additional address types,
[assignment:
list of address types]].
IPS_IPB_EXT.1.2
The TSF shall allow [assignment:
authorized 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].
C.2.1.3 IPS_NTA_EXT Network Traffic Analysis
Family Behavior
This family defines the network traffic protocols for which the TOE is capable of analyzing and detecting violations.
Component Leveling
IPS_NTA_EXT.1,
Network Traffic Analysis,
requires the TSF to be able to inspect traffic for certain network
protocols and in certain architectural deployments.
Management: IPS_NTA_EXT.1
The following actions could be considered for the management functions in FMT:
Modification of the parameters that define the network traffic to be collected and analyzed.
Audit: IPS_NTA_EXT.1
The following actions should be auditable if FAU_GEN Security audit data generation is included in the
PP/ST:
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.
IPS_NTA_EXT.1 Network Traffic Analysis
Hierarchical to:
No other components.
Dependencies to:
No dependencies.
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.
IPS_NTA_EXT.1.2
The TSF shall process (be capable of inspecting) the following network traffic protocols:
The TSF shall allow the signatures to be assigned to sensor interfaces configured for promiscuous mode and to sensor interfaces configured for inline mode, and to
support designation of one or more interfaces as being used as a management interface for communication between the TOE and external entities without simultaneously
being a sensor interface, as indicated by the following interface types:
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].
This family defines the network traffic protocols for which the TOE is capable of analyzing and detecting violations.
Component Leveling
IPS_SBD_EXT.1,
Signature-Based IPS Functionality,
requires the TSF to detect network traffic with certain
packet characteristics and take some action when this traffic is detected.
IPS_SBD_EXT.2,
Traffic Normalization,
requires the TSF to support the inspection of encapsulated or
fragmented traffic by normalizing it.
Management: IPS_SBD_EXT.1
The following actions could be considered for the management functions in FMT:
Enabling and disabling signatures applied to sensor interfaces.
Updating (importing) signatures.
Creating custom signatures.
Enabling and disabling actions to be taken when signature matches are detected.
Audit: IPS_SBD_EXT.1
The following actions should be auditable if FAU_GEN Security audit data generation is included in the
PP/ST:
Inspected traffic matches a signature-based IPS rule with logging enabled.
The TSF shall support inspection of packet header contents and be able to inspect at least the following header fields:
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]]
UDP: source port; destination port; length; and UDP checksum.
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:
The TSF shall allow the following operations to be associated with signature-based IPS policies:
In any mode, for any sensor interface: [selection:
allow the traffic flow;
send a TCP reset to the source address of the offending traffic;
send a TCP reset to the destination address of the offending traffic;
send an ICMP[selection: host, destination, port]unreachable message;
trigger a non-TOE network device to block the offending traffic pattern
]
In inline mode:
block/drop the traffic flow;
and [selection:
allow all traffic flow;
allow the traffic flow with following exceptions:[assignment:
malicious traffic such as but not limited to IPS_EXT.1.3 and IPS_EXT.1.4 if always dropped];
modify and forward packets before they pass through the TOE
].
IPS_SBD_EXT.1.6
The TSF shall support stream reassembly or equivalent to detect malicious payload even if it is split across multiple non-fragmented packets.
Management: IPS_SBD_EXT.2
The following actions could be considered for the management functions in FMT:
Enabling and disabling signatures applied to sensor interfaces.
Updating (importing) signatures.
Creating custom signatures.
Enabling and disabling actions to be taken when signature matches are detected.
Audit: IPS_SBD_EXT.2
The following actions should be auditable if FAU_GEN Security audit data generation is included in the
PP/ST:
Inspected traffic matches a signature-based IPS rule with logging enabled.
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]].
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
].
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]
].
Appendix D - Inherently Satisfied Requirements
This appendix lists requirements that should be considered satisfied by products
successfully evaluated against this Protection Profile.
However, these requirements are not featured explicitly as SFRs and should not be
included in the ST.
They are not included as standalone SFRs because it would
increase the time, cost, and complexity of evaluation. This approach is permitted
by [CC] Part 1, 8.3 Dependencies between components.
This information benefits systems engineering activities which call for inclusion of
particular security controls. Evaluation against the Protection Profile
provides evidence that these controls are present and have been evaluated.
FAU_ARP.1 has a dependency on FAU_SAA.1. This is
because FAU_SAA.1 defines the behavior that the TSF may
consider to be a potential security violation while
FAU_ARP.1 defines what actions the TSF takes when such
behavior is detected. This dependency is implicitly
satisfied in this PP-Module because the behavior defined
in FRU_RSA.1 and the various IPS class requirements
collectively define potential security violation behavior so
a separate SFR to enumerate this is redundant.
FAU_GEN.1 has a dependency on FPT_STM.1 The
extended SFR FPT_STM_EXT.1 that is defined in the Base-PP provides equivalent functionality to FPT_STM.1 and
therefore satisfies this dependency.
Appendix E - Entropy Documentation and Assessment
The TOE does not require any additional supplementary information to describe its entropy sources
beyond the requirements outlined in the Base-PP.
