IPv4 & IPv6: Some header fields do not need to be inspected.
ICMP: The requirement must be explicit in what is required to be inspected. If it is not, this can lead to inconsistent interpretation of the requirement and/or testing the wrong fields
FAU_GEN.1.2/IPS Refinement is updated so it only applies to an event that matches an intrusion rule (i.e., bad checksums are not considered an IPS event and are not be required to be auditable).
FAU_GEN.1.2/IPS is replaced as follows:
FAU_GEN.1.2/IPS Refinement: The TSF shall record within each IPS auditable event record at least the following information:
a) Date and time of the event, type of event and/or reaction, subject identity, and the outcome (success or failure) of the event; and;
b) For each IPS auditable event type, based on the auditable event definitions of the functional components included in the PP/ST, [Specifically defined auditable events listed in Table 4-2].
Application Note: The ST author should update the Table of Events below with any additional information generated such as source and destination addresses, IP, signature that trigged event, port, etc.
For IPS_SBD_EXT.1 and IPS_ABD_EXT.1 there may be several circumstances in which it would not be necessary to explicitly identify the action within the audit messages, for example: If the TOE’s action is implied within the policy definition; or if the default action is to allow traffic then the absence of ‘blocked’ would imply the traffic was allowed.
For IPS_SBD_EXT.1, if certain header fields are inspected and dropped or modified by default (e.g., packets with bad checksum, reserved bits set to zero), this logging requirement is not applicable.
Table 4-2: Auditable Events and Additional Audit Record Contents
|
Requirement
|
Auditable Events
|
Additional Audit Record Contents
|
|
FMT_SMF.1/IPS
|
Modification of an IPS policy element.
|
Identifier or name of the modified IPS policy element (e.g. which signature, baseline, or known-good/known-bad list was modified).
|
|
IPS_ABD_EXT.1
|
Inspected traffic matches an anomaly-based IPS policy.
|
Source and destination IP addresses.
|
|
The content of the header fields that were determined to match the policy.
|
|
TOE interface that received the packet.
|
|
Aspect of the anomaly-based IPS policy rule that triggered the event (e.g. throughput, time of day, frequency, etc.).
|
|
Network-based action by the TOE (e.g. allowed, blocked, sent reset to source IP, sent blocking notification to firewall).[1]
|
|
IPS_IPB_EXT.1
|
Inspected traffic matches a list of known-good or known-bad addresses applied to an IPS policy.
|
Source and destination IP addresses (and, if applicable, indication of whether the source and/or destination address matched the list).
|
|
TOE interface that received the packet.
|
|
Network-based action by the TOE (e.g. allowed, blocked, sent reset).[2]
|
|
IPS_NTA_EXT.1
|
Modification of which IPS policies are active on a TOE interface.
Enabling/disabling a TOE interface with IPS policies applied.
Modification of which mode(s) is/are active on a TOE interface.
|
Identification of the TOE interface.
|
|
The IPS policy and interface mode (if applicable).
|
|
IPS_SBD_EXT.1
|
Inspected traffic matches a signature-based IPS rule with logging enabled.
|
Name or identifier of the matched signature.
|
|
Source and destination IP addresses.
|
|
The content of the header fields that were determined to match the signature.
|
|
TOE interface that received the packet.
|
|
Network-based action by the TOE (e.g. allowed, blocked, sent reset).[3]
|
|
IPS_SBD_EXT.2.1 (optional)
|
Inspection of encapsulated packets.
|
Indication of the encapsulation method.
|
|
IPS_SBD_EXT.2.2 (optional)
|
Failure to re-assemble a fragmented packet.
|
Source and destination IP addresses.
|
|
TOE interface that received the fragment(s).
|
|
IPS_SBD_EXT.2.3 (optional)
|
Normalization of traffic by the TOE.
|
Source and destination IP addresses of discarded packet(s).
|
|
TOE interface that received the packet(s).
|
|
Activity
|
Assurance Activity
|
|
TSS
|
The evaluator shall verify that the TSS describes how the TOE can be configured to log IPS data associated with applicable policies.
The evaluator shall verify that the TSS describes what (similar) IPS event types the TOE will combine into a single audit record along with the conditions (e.g., thresholds and time periods) for so doing. The TSS shall also describe to what extent (if any) that may be configurable.
For IPS_SBD_EXT.1, for each field, the evaluator shall verify that the TSS describes how the field is inspected and if logging is not applicable, any other mechanism such as counting that is deployed.
|
|
AGD
|
The evaluator shall verify that the operational guidance describes how to configure the TOE to result in applicable IPS data logging.
The evaluator shall verify that the operational guidance provides instructions for any configuration that may be done in regard to logging similar events (e.g., setting thresholds, defining time windows, etc.).
|
|
Test
|
Test 1: The evaluator shall test that the interfaces used to configure the IPS polices yield expected IPS data in association with the IPS policies. A number of IPS policy combination and ordering scenarios need to be configured and tested by attempting to pass both allowed and anomalous network traffic matching configured IPS policies in order to trigger all required IPS events. Note that this activity should have been addressed with a combination of the Test assurance activities for the other IPS requirements.
|
