Network Device collaborative Protection Profile (NDcPP) Extended Package (EP) for Intrusion Prevention Systems (IPS) 01 December 2015 Version 2.

Transcription

1 Network Device collaborative Protection Profile (NDcPP) Extended Package (EP) for Intrusion Prevention Systems (IPS) 01 December 2015 Version 2.0

2 Table of Contents 1 Introduction Conformance Claims How to Use This Extended Package Compliant Targets of Evaluation Security Problem Definition Unauthorized Disclosure of Information Unauthorized Access Inappropriate Access to Services Disruption or Denial of Services Security Objectives System Monitoring Analysis of Network Traffic Policy Violations Reaction to Network Traffic Policy Violations TOE Administration Trusted Communications Security Requirements Conventions TOE Security Functional Requirements FAU: Security Audit FMT: Security Management IPS: Intrusion Prevention Environment Security Assurance Requirements Appendix A: Rationale A.1 Security Problem Definition A.1.1 Assumptions A.1.2 Threats A.1.3 Organizational Security Policies A.1.4 Security Problem Definition Correspondence A.2 Security Objectives A.2.1 Security Objectives for the TOE A.2.2 Security Objectives for the Operational Environment A.2.3 Security Objective Correspondence Page 2 of 43

3 A.3 Rationale for Security Functional Requirements Appendix B: Optional Requirements B.1 Requirements B.1.1 FAU: Security Audit B.1.2 FMT: Security Management Requirements B.1.3 FPT: Protection of the TSF B.1.4 FRU: Resource Utilization B.1.5 IPS: Intrusion Prevention Appendix C: Selection-Based Requirements C.1 Requirements C.1.1 FCS: Cryptographic Support Appendix D: Objective Requirements D.1 Requirements D.1.1 FAU: Security Audit Appendix E: Definitions E.1 Definitions of Attacks E.2 Definitions of Terms and Acronyms Tables Table 4-1: Security Functional Requirements Table 4-2: Auditable Events and Additional Audit Record Contents Table A-1: TOE Assumptions Table A-2: Threats Table A-3: Policies Table A-4: Security Problem Definition Correspondence Table A-5: Security Objectives for the TOE Table A-6: Security Objectives for the Operational Environment Table A-7: Rationale for Explicitly Stated Requirements Table A-8: SFR Dependency Rationale Table D-1: Table of Events (some examples inserted) Figures Figure 1: TOE Deployment Scenario Diagram... 7 Figure 2: Sample Inline Mode Topology Figure 3: Sample Promiscuous Mode Topology Page 3 of 43

4 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 the collaborative Protection Profile for Network Devices (NDcPP). 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. 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. This EP serves to extend the NDcPP baseline 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 the NDcPP, it is expected that the content of both this EP and the NDcPP 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 (see 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. 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 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 Page 4 of 43

5 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 FCS_STG_EXT.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 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. ST authors should consider whether it would be appropriate for the IPS TOE to also claim conformance to the Firewall collaborative Protection Profile (FWcPP). 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. 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 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. Page 5 of 43

6 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 6 of 43

7 Figure 1: TOE Deployment Scenario Diagram Page 7 of 43

8 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 described in the NDcPP as defined in FAU_GEN from the NDcPP, 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, though they all apply given the conformance and hence dependence of this EP on the NDcPP. 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. A full mapping between threats and objectives is provided in Appendix A of this EP. Also note that while the NDcPP contains only threats to the ability of the TOE to provide its own security functions, this EP focuses on threats to resources in the operational environment. Together the threats of the NDcPP 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. (T.NETWORK_DISCLOSURE) Page 8 of 43

9 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 9 of 43

10 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. Compliant 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. This refers to the objectives that are addressed by this EP and does not include any capabilities from the NDcPP unless they are mandated for inclusion within the TSF when this EP is claimed. 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 NDcPP, 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 10 of 43

11 3.1 Trusted Communications To further address the threat of untrusted communications channels that is defined in the NDcPP, conformant TOEs will provide trusted communications between distributed components if any exist. (O.TRUSTED_COMMUNICATIONS (optional) -> FPT_ITT.1 (optional)) 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 the NDcPP, 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. This EP does not mandate the inclusion or exclusion of any optional SFRs in the NDcPP, nor does it complete any selection, assignment, or refinement operations of SFRs that are defined the NDcPP. 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) Page 11 of 43

12 IPS: Intrusion Prevention System FAU: Security Audit IPS_ABD_EXT.1 IPS_IPB_EXT.1 IPS_NTA_EXT.1 IPS_SBD_EXT.1 Anomaly-Based IPS Functionality IP Blocking Network Traffic Analysis Signature-Based IPS Functionality The IPS EP defines auditable events for IPS behavior which are similar to auditable events of TSF behavior that are defined in the NDcPP but sufficiently distinct to justify existing as a separate iteration of FAU_GEN 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 the NDcPP FAU_GEN.1 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 Error! Reference source not found.]. 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 Page 12 of 43

13 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. 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 Identifier or name of the modified IPS policy element. element (e.g. which signature, baseline, or IPS_ABD_EXT.1 IPS_IPB_EXT.1 IPS_NTA_EXT.1 Inspected traffic matches an anomaly-based IPS policy. Inspected traffic matches a list of known-good or known-bad addresses applied to an IPS policy. Modification of which IPS policies are active on a TOE interface. known-good/known-bad list was modified). 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 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 Identification of the TOE interface. Enabling/disabling a TOE interface with IPS policies applied. The IPS policy and interface mode (if applicable). Modification of which mode(s) is/are active on a TOE interface. IPS_SBD_EXT.1 Inspected traffic matches a Name or identifier of the matched signature. signature-based IPS policy. 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 Inspection of encapsulated Indication of the encapsulation method. 1 See application note. 2 See application note. 3 See application note. Page 13 of 43

14 Requirement Auditable Events Additional Audit Record Contents (optional) packets. 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). 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). The evaluator shall verify that the describes how the TOE can be configured to log IPS data associated with applicable policies. The evaluator shall verify that the 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 shall also describe to what extent (if any) that may be configurable. 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.). 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 assurance activities for the other IPS requirements FMT: Security Management 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 Create custom signatures Page 14 of 43

15 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 NDcPP Supporting Documents for this SFR. The evaluator shall verify that the describes how the IPS data analysis and reactions can be configured. Note that this activity should have been addressed with the assurance activities for IPS_ABD_EXT.1, IPS_IPB_EXT.1 and IPS_ABD_EXT.1 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. The evaluator shall perform the following tests: 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. 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. 3: The evaluator shall use the operational guidance to import signatures and repeat the test conducted in 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 IPS: Intrusion Prevention 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 15 of 43

16 [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 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 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] The evaluator shall verify that the 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 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 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., where the same internal logical path is used, perhaps where a common device driver is Page 16 of 43

17 used) they can be treated collectively as a distinct network interface. 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. The evaluator shall perform the following tests: 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 : 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 IPS_IPB_EXT.1 IP Blocking IPS_IPB_EXT.1.1: The TSF shall support configuration and implementation of known-good and knownbad 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 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]. The evaluator shall verify how good/bad lists affect the way in which traffic is analyzed with respect to processing packets. The 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 identifies all the roles and level of access for each of those roles that have been specified in the requirement. 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 Page 17 of 43

18 known good and known bad lists. The evaluator shall perform the following tests: 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. 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. 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 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. The evaluator shall verify that the explains the TOE s capability of analyzing IP traffic in terms of the TOE s policy hierarchy (precedence). The 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 describes the default precedence as well as the IP analyzing functions supported by the TOE. The associated with this requirement is assessed in the subsequent assurance activities. 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. 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: Page 18 of 43

19 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. The evaluator shall verify that the indicates that the following protocols are supported: IPv4 IPv6 ICMPv4 ICMPv6 TCP UDP The evaluator shall verify that the describes how conformance with the identified protocols has been determined by the TOE developer. (e.g., third party interoperability testing, protocol compliance testing) The Guidance associated with this requirement is assessed in the subsequent assurance activities. 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]. 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 Page 19 of 43

20 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 evaluator shall verify that the 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 should also provide descriptions how the management interface is distinct from sensor interfaces. The evaluator shall verify that the operational guidance provides instructions on how to deploy each of the deployment methods outlined in the. 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 NDcPP FTP_ITC (if the ST author selects other interface types) and FTP_TRP (for interfaces in management mode). 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 (if the ST author selects other interface types) and FTP_TRP (for interfaces in management mode) of NDcPP 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: 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. Page 20 of 43

21 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 describes what is comprised within a signature rule. The evaluator shall verify that each signature can be associated with a reactions specified in IPS_SBD_EXT.1.5. The evaluator shall verify that the 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. 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. The evaluator shall perform the following tests: 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. 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. Page 21 of 43

22 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. 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 administratordefined strings to match URLs/URIs, and web page content. iii) SMTP ( ) 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. The evaluator shall verify that the 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 reactions specified in IPS_SBD_EXT.1.5. 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. 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. The evaluator shall perform the following tests: 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 Page 22 of 43