UNCLASSIFIED

(1)

12686381

CPA SECURITY CHARACTERISTIC

IP FILTERING FIREWALLS

Version 1.1

(2)

CPA Security Characteristics for IP Filtering firewalls 26/07/2011

Document History

Version Date Description

0.5 July 2011 Fourth draft of documentation

0.6 August 2011 Fifth draft of documentation

1.0 September 2011 Document ready for release

1.1 October 2011 Document ready for publishing

This Security Characteristic is derived from the following files

File Name Version

IP Filtering Firewall – v1.1.cxl 1.1

Common Libraries - v1.3.cxl 1.3

Crypt Libraries - v1.3.cxl 1.3

Hardware Libraries v1.2.cxl 1.2

Passphrase Libraries - v1.4.cxl 1.4

Soft copy location

DiscoverID 12686381

This document is authorised by:

Deputy Technical Director (Assurance) CESG

This document is issued by CESG

For queries about this document please contact: CPA Administration Team

CESG Hubble Road Cheltenham Gloucestershire GL51 0EX United Kingdom Tel: +44 (0)1242 221 491 Email: [email protected]

The CPA Authority may review, amend, update, replace or issue new Scheme Documents as may be required from time to time.

(3)

CPA Security Characteristics for IP Filtering firewalls 26/07/2011

REFERENCES

[a] The Process for Performing Foundation Grade CPA Evaluations, v1.3, August 2011, CESG

[b] HMG IA Standard No. 7 – Authentication of Internal Users of ICT Systems Handling Government Information [October 2010 Issue No: 1.0]

[c] Good Practice Guide 35 – Protecting an Internal ICT Network [August 2011 Issue No: 2.0]

(5)

I. OVERVIEW

1. This document is a CPA Security Characteristic – it describes requirements for a particular type of assured product for evaluation and certification under CESG‟s Commercial Product Assurance (CPA) scheme.

A. Product Aims

2. IP filtering firewall products are intended to protect network boundaries or specific areas of networks by permitting only traffic from certain hosts to reach certain

destinations and vice versa.

3. “IP Filtering Firewall” as referred to in this security characteristic refers to a

physical device that acts as a packet filtering device (with multiple network interfaces) and the software running within it, whether that is completely custom-built or based on a commercial / open source operating system.

4. Any packets that do not conform to the firewall ruleset are dropped by default.

B. Typical Use Case(s)

5. Firewalls are used as part of many network architectures to provide control over which network devices or hosts may connect to which destinations and vice versa at the IP level (Layer 3). The firewall may also provide functionality at higher layers, which is out of the scope of this characteristic.

 “Routed” Mode (Layer 3 mode)

6. A firewall may be deployed as an extra hop in a network and act as a basic router to protect systems and hosts behind it.

 “Transparent” Mode (Layer 2 mode)

7. A firewall may be deployed as a “bump in the wire” essentially operating at layer 2 and will not appear as an extra hop in a traffic path.

C. Expected Operating Environment

8. Firewalls are crucial components in a large proportion of network designs and architectural patterns. Due to the availability of firewalls with various different feature sets to support different speeds and types of network, they may be found in many different environments, ranging from ISP-level networks through corporate, to SMEs and home users, where logically separating areas of a network or protecting certain hosts is deemed necessary. For more information, consult Good Practice Guide No. 35 [c].

(6)

D. Compatibility

9. An IP filtering firewall must support the widely deployed Internet Protocol. Compatibility with various types of physical network implementations (e.g. fibre-based, copper-based and various line speeds) will depend on manufacturer support. Firewalls are typically available in various levels of complexity and size (e.g. support for high-bandwidth connections and number of interfaces) to accommodate different market segments.

E. Interoperability

10. A firewall solely concerned with Layer 3 operation should interoperate with all protocols that sit above it in higher layers.

F. High Level Functional Components

11. Rules Configuration: The rules which are set or configured by the administrator to protect the red network from attack.

12. Device Configuration: The settings which allow the device to successfully interact on the network, such as network interface settings.

13. Packet Engine: The element which allows the IP Filtering Firewall to inspect packets and apply rules.

14. Logging: Recording security related events and the review of logs.

15. Network Interface: The network interfaces which allow the device to connect to the red network, the black network, and the management network.

Physical Boundary Packet Engine Management Network Interfaces Rules Configuration Logging Device Configuration

(7)

G. Evaluation Notes

16. The evaluation team must observe the guidance contained within Appendix A of this document when examining the Verification Mitigations.

H. Future Enhancements

17. CESG welcomes feedback and suggestions on possible enhancements to this security characteristic

18. Likely future enhancements to this Security Characteristic are:  Layer 4 Firewalls

(8)

II. SECURITY CHARACTERISTIC FORMAT

19. All CPA Security Characteristics contain a list of mitigations which are split into three categories: development, verification and deployment. Within each of these sets the mitigations can be grouped based on areas of the product (as illustrated in the High Level Functional Component Diagram above), such as bulk encryption or authentication, or they may be overarching requirements which apply to the whole product. Reference [a] describes how evaluation teams should interpret Security Characteristics.

20. The three types of mitigations are denominated as follows:

 DEV – Development mitigations are included by the developer during the

design or implementation of the product. These are validated via a review of the product‟s design or implementation during a CPA evaluation.

 VER – Verification mitigations are specific items that the evaluator must test during the evaluation of the product.

 DEP – Deployment mitigations are points that must be considered by users or administrators during the deployment of the product. These mitigations are incorporated into the Security Procedures which are published by CESG for the product.

21. Each mitigation includes:

 Informational text in italics, describing the threat to be mitigated.  One or more specific mitigations, which describe what must be done.  Optional additional explanatory text which expands upon the requirement. 22. In the mitigations listed below, the following terminology is used:

 „Must‟, „Mandatory‟ and “Required” are used to express a mitigation that is essential. All mitigations and detailed mitigations are mandatory unless there is an explicit caveat, such as „if supported by the product‟.

 „Should‟ and „Strongly Recommended‟ are used whenever a requirement is highly desirable, but is not essential. These are likely to become mandatory in future iterations of the Security Characteristic.

 „Could‟ and „Recommended‟ are used to express a non-mandatory requirement that may enhance security or functionality.

23. For example:

DEV.M1: [A mitigation]

This mitigation is required to counter [a threat]

At Foundation the product must [do something].

(9)

III. REQUIREMENTS

A. Design Mitigations

DEV.M22: Update signing

This mitigation is required to counter installing compromised software using the update process

At Foundation Grade the product is required to use cryptographically signed updates and verify their signatures before installation, if an update mechanism is present.

Updates to the product must be verified using a hardcoded manufacturer's public key built-in to the product. The digital signature algorithm must be ECDSA-256 or DSA-1536/192 or higher, the hash algorithm must be SHA-256.

DEV.M41: Crash reporting

This mitigation is required to counter exploitation of a software implementation error

At Foundation Grade the product is required to ensure crashes are logged

Where it is possible that sensitive data may end up in the crash data, this must be handled as red data and must only be available to an administrator. Crash data from both the product and the underlying operating system must be considered.

DEV.M42: Heap hardening

At Foundation Grade the product is required to use the memory management provided by the operating system, products should not implement their own heap

DEV.M43: Stack protection

At Foundation Grade the product is required to be compiled with support for stack protection in all libraries, where the tool chain supports it

If more recent versions of the toolchain support it for the target platform then they should be used in preference to a legacy toolchain.

DEV.M46: User least privilege

This mitigation is required to counter taking advantage of existing user privilege

At Foundation Grade the product is required to operate correctly from a standard account without elevated privileges

DEV.M159: Update product

This mitigation is required to counter exploitation of a software logic error

At Foundation Grade the product should support the use of software updates

DEV.M321: Data Execution Protection

At Foundation Grade the product is required to support Data Execution

Protection (DEP) when enabled on its hosting platform and must not opt out of DEP

(10)

If the product is to be specifically deployed on a platform that does not support either Software DEP or Hardware-enforced DEP, there is no requirement for DEP compatibility.

DEV.M340: Address Space Layout Randomisation

At Foundation Grade the product is required to be compiled with full support for ASLR, including all libraries used

ASLR may be disabled for specific aspects of the product, provided there is justification of why this is required.

DEV.M353: Store manufacturer's public key securely

This mitigation is required to counter modification of the manufacturer's public key on device

At Foundation Grade the product is required to ensure there are no methods to gain unauthorised access to keys on the device

DEV.M357: Retain data on power loss

This mitigation is required to counter exploitation of incorrect operations of firewall

At Foundation Grade the product is required to ensure that operationally important data is not lost from power loss

This includes important data such as: Firewall configuration

Logging / auditing data Firewall rulesets

DEV.1 - Design >> Rules Configuration

DEV.1.M350: Configuration only by Administrators

This mitigation is required to counter modification of rules without valid admin credentials

This mitigation is required to counter inserting a firewall rule to continue compromise

At Foundation Grade the product is required to ensure that only an authenticated administrator can change device configuration settings

DEV.2 - Design >> Packet Engine DEV.2.M41: Crash reporting

At Foundation Grade the product is required to ensure crashes are logged

Where it is possible that sensitive data may end up in the crash data, this must be handled as red data and must only be available to an administrator. Crash data from both the product and the underlying operating system must be considered.

DEV.2.M42: Heap hardening

At Foundation Grade the product is required to use the memory management provided by the operating system, products should not implement their own heap

(11)

DEV.2.M43: Stack protection

At Foundation Grade the product is required to be compiled with support for stack protection in all libraries, where the tool chain supports it

If more recent versions of the toolchain support it for the target platform then they should be used in preference to a legacy toolchain.

DEV.2.M159: Update product

At Foundation Grade the product should support the use of software updates

DEV.2.M321: Data Execution Protection

At Foundation Grade the product is required to support Data Execution

Protection (DEP) when enabled on its hosting platform and must not opt out of DEP

If the product is to be specifically deployed on a platform that does not support either Software DEP or Hardware-enforced DEP, there is no requirement for DEP compatibility.

DEV.2.M340: Address Space Layout Randomisation

At Foundation Grade the product is required to be compiled with full support for ASLR, including all libraries used

ASLR may be disabled for specific aspects of the product, provided there is justification of why this is required.

DEV.2.M360: Drop packets that do not conform to ruleset

At Foundation Grade the product is required to only allow packets which adhere to firewall rules to traverse the device

DEV.2.M361: Ensure firewall denies traffic on start up

At Foundation Grade the product is required to only allow packets to traverse the firewall when the device is fully operational

The device may take time to load rules and configuration data at start up, therefore the firewall shouldn't process traffic until these are loaded. This also applies to re-starting/rebooting of device.

DEV.2.M362: Raise alerts

This mitigation is required to counter use of malformed/unusual traffic

At Foundation Grade the product is required to raise alerts on unusual events

Unusual events could be high traffic volumes, audit logs reaching maximum capacity amongst others.

Alerts could also be raised when an event exceeds an administrator defined threshold.

(12)

DEV.2.M364: Log unusual traffic

This mitigation is required to counter use of malformed/unusual traffic This mitigation is required to counter high valid traffic volumes

At Foundation Grade the product is required to record unusual traffic to a log

Malformed traffic is traffic which the firewall is not capable of dealing with correctly.

High valid traffic volumes are volumes of traffic, at which the firewall will be unable to operate correctly.

DEV.2.M365: Drop erroneous or excess packets

This mitigation is required to counter high valid traffic volumes

At Foundation Grade the product is required to discard packets if the functionality of the device is at risk

If the firewall cannot process any more packets, the packets must be

discarded. For example, dropping excess incoming packets until the firewall is able to handle further incoming packets.

Malformed packets must be dropped and not be processed further. DEV.2.M366: Ensure product fails securely

This mitigation is required to counter high valid traffic volumes

At Foundation Grade the product is required to handle any failures in a secure manner

The firewall must not allow packets to traverse the firewall if the device has failed.

DEV.2.M367: Control allowed sources of dynamic updates

This mitigation is required to counter injecting spoofed routing information

At Foundation Grade the product is required to ensure that untrusted source IPs cannot influence the routing table

DEV.3 - Design >> Logging

DEV.3.M369: Protect access to logs

This mitigation is required to counter sanitisation of illegitimate access from logs This mitigation is required to counter modification of logging generation

At Foundation Grade the product is required to ensure that only an authenticated administrator can manage logs

At Foundation Grade the product is required to ensure that all logs are time stamped

Timestamps must be accurate and the deployment must take measures to ensure this.

Such measures could be NTP synchronisation or a manual process.

At Foundation Grade the product is required to provide ability to automatically push logs to external device

At Foundation Grade the product is required to not overwrite logs without alerting the administrator

(13)

DEV.4 - Design >> Device Configuration

DEV.4.M13: Passphrase length and complexity enforcement

This mitigation is required to counter dictionary and exhaustion attacks

This mitigation is required to counter exploitation of poor passphrase complexity

At Foundation Grade the product is required to support administrator configurable passphrase complexity and length settings

A product must support passphrases with a length of at least 6 characters. A password length of 5 characters or less will not be suitable for network authentication purposes.

Refer to the Network Authentication Passphrase and Password Security Characteristic for further information regarding passphrase length and complexity requirements.

Use of machine generated passwords is recommended.

DEV.4.M266: Ensure product configuration can only be altered by an authenticated system administrator

This mitigation is required to counter unauthorised alteration of product's configuration

At Foundation Grade the product is required to ensure that a change of product settings requires an authenticated administrator or privileged user on the operating system

The only security enforcing setting a user should be able to change is their passphrase.

DEV.4.M267: Provide an automated configuration tool to enforce required settings This mitigation is required to counter exploitation of an accidental

misconfiguration

At Foundation Grade the product is required to be provided with a

configuration tool, or other method, for an administrator to initially set it up into a suitable configuration

If the product requires more than 12 options to be changed or set by an administrator to comply with these Security Characteristics, the developer must supply a tool or policy template which helps the administrator to achieve this in fewer steps

DEV.4.M278: Approved passphrase hashing algorithm

This mitigation is required to counter capture of passphrase stored in the clear

At Foundation Grade the product is required to use at least 1 round of SHA-256 as the passphrase hashing algorithm

DEV.4.M279: Disable old passphrase as soon as a new passphrase is enabled This mitigation is required to counter use of a user's old passphrase

At Foundation Grade the product is required to ensure old passphrases do not authenticate the user

DEV.4.M282: Initial passphrase is changed on first use

This mitigation is required to counter use of system default passphrases

At Foundation Grade the product is required to ensure passphrase is changed on first logon

The system must force users to use an initial passphrase once only, i.e. forces the passphrase to change on first logon.

It is strongly recommended that initial passphrases have a limited lifetime between generation and first use that is as short as is practicable.

(14)

DEV.4.M289: Approved passphrase salting mechanism

At Foundation Grade the product should allow the use of passphrase salting

It is strongly recommended that passphrases are salted, but this is not mandatory.

DEV.4.M294: Account lock-out

At Foundation Grade the product is required to lock the account after five or fewer consecutive failed authentication attempts

The number of attempts that may be made before the user account is locked should be configurable by the administrator.

DEV.4.M295: Inform user of account activity

At Foundation Grade the product should display recent authentication history

It is recommended that on login the user be notified of the date and time of the last successful login and any failed login attempts since the last

successful login.

If recent authentication history is displayed, it is strongly recommended that users are told what to do, preferably on the screen, if the history is not what is expected.

DEV.4.M298: Enforce regular changes of the passphrase

At Foundation Grade the product is required to enforce change of the passphrase every three months

The system must enforce changes to passphrases after an administrator configured duration.

It is recommended that the system warns users that their passphrase is about to expire.

DEV.4.M342: Passphrases are not displayed on screen in the clear while being entered

This mitigation is required to counter shoulder surfing

At Foundation Grade the product is required to ensure the passphrase is never visible in the clear on the screen

DEV.4.M344: Effective user account revocation

This mitigation is required to counter use of a previous user's credentials

At Foundation Grade the product is required to provide the ability to revoke user accounts

The product must ensure that once a user account has been revoked it does not continue to function.

DEV.4.M345: Replaying network traffic will not allow access This mitigation is required to counter replay attack

At Foundation Grade the product is required to ensure that replaying authentication sequences does not grant access

DEV.4.M347: Lock an account if the account is not used for a pre-defined period This mitigation is required to counter use of a dormant account

At Foundation Grade the product is required to lock user accounts

DEV.4.M349: Lock an account if the passphrase is not changed by the expiry date This mitigation is required to counter use of a user's old passphrase

(15)

B. Verification Mitigations

VER.M80: Protocol robustness testing

This mitigation is required to counter discovery of a vulnerability in the implementation of the protocol

At Foundation Grade the evaluator will perform testing using commercial fuzzing tools

Fuzz testing is described in more detail in the Process for Performing Foundation Grade Evaluations.

VER.M358: Ensure data is not lost on power loss

At Foundation Grade the evaluator will ensure that operationally important data is not lost from power loss

This includes important data such as: Firewall configuration

Logging / auditing data Firewall rulesets

VER.1 - Verify >> Device Configuration

VER.1.M343: Evaluation/Cryptocheck of the passphrase hashing algorithm

This mitigation is required to counter capture of passphrase stored in the clear

At Foundation Grade the evaluator will ensure all cryptographic algorithms employed for security functionality have been validated as per the

"Cryptographic Validation" section in the CPA Foundation Process document

VER.2 - Verify >> Packet Engine

VER.2.M359: Verify correct operation of ruleset

At Foundation Grade the evaluator will perform testing to ensure packets are processed correctly for a given ruleset. Packets which do not conform should be dropped.

Verification can be achieved by creating a sample ruleset and then testing against that ruleset. The device will conform to this mitigation if the expected outcomes are observed during testing.

VER.2.M361: Ensure firewall denies traffic on start up

At Foundation Grade the evaluator will ensure that no packets traverse the firewall until the device is fully operational

The device may take time to load rules and configuration data at start up, therefore the firewall shouldn't process traffic until these are loaded. This also applies to re-starting/rebooting of device.

VER.3 - Verify >> Rules Configuration

VER.3.M356: Product allows Deny-All default

This mitigation is required to counter exploitation of omission/error in rule configuration

At Foundation Grade the evaluator will ensure that the product provides the ability to enforce "Default Deny" on rulesets

(16)

C. Deployment Mitigations

DEP.M26: Physical tamper evidence

This mitigation is required to counter installation of hardware-level malware

At Foundation Grade the deployment is required to educate users to regularly check that tamper labels are intact

At Foundation Grade the deployment is required to provide administrators with advice on the tamper threat

Advice should include looking for possible damage to tamper evident seals. In the event of tampering, the event should be reported as soon as possible and the product must be removed from use immediately. Any product that shows evidence of tampering must not be returned to service.

At Foundation Grade the deployment is required to place tamper evident seals over access points on product

Use tamper evidence (e.g. stickers) to make entry to system internals detectable by physical inspection. Tamper stickers should be uniquely identifiable to prevent an attacker successfully replacing it with a new, undamaged sticker.

DEP.M39: Audit log review

At Foundation Grade the deployment is required to regularly review audit logs for unexpected entries

DEP.M46: User least privilege

This mitigation is required to counter taking advantage of existing user privilege

At Foundation Grade the deployment is required to ensure all user accounts have the fewest privileges required to enable business functionality

DEP.M159: Update product

At Foundation Grade the deployment is required to update to the latest version where possible

DEP.M340: Address Space Layout Randomisation

At Foundation Grade the deployment is required to enable ASLR in the host Operating System where available

DEP.M351: Physical security controls

This mitigation is required to counter modification of the manufacturer's public key on device

This mitigation is required to counter physically destroying device This mitigation is required to counter compromising physical security surrounding device

At Foundation Grade the deployment is required to store the device in an appropriately secured area

(17)

DEP.1 - Deploy >> Device Configuration

DEP.1.M12: Passphrase is set to suitable size and complexity

At Foundation Grade the deployment is required to configure passphrase complexity and length settings

The passphrase length is determined by the deployment of the passphrase system. Longer passphrase lengths may be required based on the

deployment of the passphrase system, or the character set used.

Refer to the Network Authentication Passphrase and Password Security Characteristic for further information regarding passphrase length and complexity requirements.

IA Standard No.7 also provides some guidance regarding password complexity

DEP.1.M38: Use automated configuration tool

This mitigation is required to counter exploitation of an accidental misconfiguration

At Foundation Grade the deployment is required to be configured using automated tools if provided

DEP.1.M277: User guidance on social engineering

This mitigation is required to counter a social engineering attack on the user

At Foundation Grade the deployment should educate users about social engineering methods used by attackers

DEP.1.M280: Distribute initial credentials out of band

This mitigation is required to counter interception of initial passphrase during distribution

At Foundation Grade the deployment is required to ensure that credentials are sent separately to the product that they will be protecting

DEP.1.M281: Only administrators can modify passphrase settings

This mitigation is required to counter modification of passphrase settings

At Foundation Grade the deployment is required to ensure only system administrators have access to passphrase settings

DEP.1.M283: User guidance on passphrase management

This mitigation is required to counter exploitation of poor management of passphrases by the user

At Foundation Grade the deployment is required to provide user training on passphrase management

Users should be provided with guidance regarding the secure handling of passphrases which allow access to sensitive systems. Users must be taught never to disclose passphrases, even to their superiors.

Users must also be made aware of the risks of using protectively marked devices in public or untrusted areas. Passphrases should not be entered in areas where others could see them being entered.

DEP.1.M285: Secure storage of user passphrases

This mitigation is required to counter poor passphrase storage

At Foundation Grade the deployment is required to ensure any hardcopies of passphrases are stored securely

(18)

DEP.1.M293: Use of passphrases in scripts/batch files in security related areas is carefully considered

This mitigation is required to counter passphrase captured in clear

At Foundation Grade the deployment should ensure that the risk of using passphrases for this purpose has been accepted

It is recommended that passphrases are not held in a macro or batch file. However this may be acceptable for authentication with low impact systems. If in doubt then please contact CESG for advice.

DEP.1.M341: User guidance on passphrase selection

This mitigation is required to counter dictionary and exhaustion attacks This mitigation is required to counter obtaining and using a user passphrase from a different system

At Foundation Grade the deployment is required to provide user training on passphrase selection

Users must be provided with guidance regarding the selection of passphrases which allow access to sensitive systems.

Passphrases must be unique per device to prevent compromise of multiple systems.

DEP.1.M346: Lock an account if the account remains unused for a pre-defined period

This mitigation is required to counter use of a dormant account

At Foundation Grade the deployment is required to lock user accounts after a pre-defined period

The locking of account will be determined by the deployment's account policy. DEP.1.M348: Lock an account if the passphrase is not changed by the expiry date

This mitigation is required to counter use of a user's old passphrase

At Foundation Grade the deployment is required to lock user accounts after a pre-defined period

The locking of account will be determined by the deployment's account policy. DEP.1.M352: Control access to device management

This mitigation is required to counter attacking management protocol

At Foundation Grade the deployment is required to restrict which network interfaces can be used for device management

If a local console port or dedicated management interface is available, it must be possible to configure the other network interfaces to not have

management services accessible on them.

Similarly, it must also be possible to restrict which network interfaces have management services enabled on them.

DEP.2 - Deploy >> Packet Engine DEP.2.M39: Audit log review

At Foundation Grade the deployment is required to regularly review audit logs for unexpected entries

(19)

DEP.2.M159: Update product

At Foundation Grade the deployment is required to update to the latest version where possible

DEP.2.M340: Address Space Layout Randomisation

At Foundation Grade the deployment is required to enable ASLR in the host Operating System where available

DEP.2.M363: Take action on receiving alerts

This mitigation is required to counter use of malformed/unusual traffic This mitigation is required to counter high valid traffic volumes

At Foundation Grade the deployment is required to assess impact of alerts and follow organisational procedures for incident resolution

DEP.3 - Deploy >> Rules Configuration

DEP.3.M354: Administrators Guidance on ruleset management

At Foundation Grade the deployment is required to ensure administrators are educated on how to configure the ruleset

DEP.3.M355: Adopt Deny-All default rule set

At Foundation Grade the deployment is required to automatically enforce "Default Deny" rule at the end of every ruleset

DEP.4 - Deploy >> Logging

DEP.4.M368: Log all relevant actions

This mitigation is required to counter modification of logging generation

At Foundation Grade the deployment is required to configure the product to log capture all actions deemed of interest

Ensure that log data is detailed enough to allow forensic investigation during any incident management.

At Foundation Grade the deployment is required to automatically export logs to management/red side device

(20)

IV. GLOSSARY

24. The following definitions are used in this document:

Term Meaning

ASLR Address Space Layout Randomisation

Black side (of network) The less trustworthy network

CA Certificate Authority

CPA Commercial Product Assurance

DSA Digital Signature Algorithm

ECDSA Elliptic Curve Digital Signature Algorithm HTTPS Hypertext Transport Protocol Secure

IP Internet Protocol

ISP Internet Service Provider

JTAG Joint Test Action Group

Red side (of network) The network which is more trustworthy

Ruleset The set of rules that determine how a packet is handled by the firewall

Security Characteristic A standard which describes necessary mitigations which must be present in a completed product, its evaluation or usage, particular to a type of security product

SHA Secure Hash Algorithm

SNMPv3 Simple Network Management Protocol version 3

SME Small-Medium Enterprise

(21)

V. APPENDIX A - GUIDANCE FOR THE TESTING OF VERIFY

MITIGATIONS

The following guidance ensures that VERIFY mitigations within this Security Characteristic are sufficiently tested:

The evaluator is required to implement a test network, including a firewall configured with a lab-generated standard ruleset. The test environment should be a network with at least 12 machines connected between two simulated RED and BLACK networks.

The test ruleset must have the minimum complexity settings of:

1. Rules which explicitly block certain source addresses from accessing destination addresses from either side of the firewall.

2. Rules which explicitly allow certain source addresses to access destination addresses on both sides of the firewall.

3. No explicit block/allow rules between specific source addresses and specific destination addresses from either side of the firewall. Test traffic traversing the firewall must use different combinations of source/destination IP addresses to exercise the ruleset.

The expected outcomes of each of these types of test are as follows: 1. Explicit blocking – The firewall must drop packets that should not

traverse the firewall.

2. Explicit Allowing – The firewall must allow packets authorised to traverse the firewall to reach the intended recipient.

3. No Explicit Allow/Block – The firewall must implement a “default deny” and block packets that do not conform to any explicit rule within the ruleset.

(22)