12686381 CPA SECURITY CHARACTERISTIC IP FILTERING FIREWALLS Version 1.1 Crown Copyright 2011 All Rights Reserved
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: cpa@cesg.gsi.gov.uk The CPA Authority may review, amend, update, replace or issue new Scheme Documents as may be required from time to time. Page ii
CPA Security Characteristics for IP Filtering firewalls 26/07/2011 CONTENTS REFERENCES... 1 I. OVERVIEW... 2 A. Product Aims... 2 B. Typical Use Case(s)... 2 C. Expected Operating Environment... 2 D. Compatibility... 3 E. Interoperability... 3 F. High Level Functional Components... 3 G. Future Enhancements... 4 II. SECURITY CHARACTERISTIC FORMAT... 5 III. REQUIREMENTS... 6 A. Design Mitigations... 6 B. Verification Mitigations... 12 C. Deployment Mitigations... 13 IV. GLOSSARY... 17 V. APPENDIX A - GUIDANCE FOR THE TESTING OF VERIFY MITIGATIONS... 18 Page iii
REFERENCES [a] [b] The Process for Performing Foundation Grade CPA Evaluations, v1.3, August 2011, CESG 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] [d] Appendix A Guidance for the testing of VERIFY mitigations Page 1
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]. Page 2
D. Compatibility 9. An IP filtering firewall must support the widely deployed Internet Protocol. Compatibility with various types of physical network implementations (e.g. fibrebased, 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 Physical Boundary Management Rules Configuration Device Configuration Packet Engine Logging Network Interfaces 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. Page 3
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 Page 4
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]. This can be achieved by [explanatory comment]. Page 5
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 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 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 Page 6
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 Page 7
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 This mitigation is required to counter exploitation of a software logic 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 This mitigation is required to counter exploitation of incorrect operations of firewall 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 This mitigation is required to counter exploitation of incorrect operations of firewall 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. Page 8
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 This mitigation is required to counter use of malformed/unusual traffic 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 This mitigation is required to counter use of malformed/unusual traffic 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 Page 9
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. Page 10
DEV.4.M289: Approved passphrase salting mechanism This mitigation is required to counter dictionary and exhaustion attacks 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 This mitigation is required to counter dictionary and exhaustion attacks 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 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 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 This mitigation is required to counter dictionary and exhaustion attacks 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 At Foundation Grade the product is required to lock user accounts Page 11
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 This mitigation is required to counter exploitation of incorrect operations of firewall 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 This mitigation is required to counter exploitation of incorrect operations of firewall 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 This mitigation is required to counter exploitation of incorrect operations of firewall 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/ in rule configuration At Foundation Grade the evaluator will ensure that the product provides the ability to enforce "Default Deny" on rulesets Page 12
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 This mitigation is required to counter exploitation of a software logic 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 This mitigation is required to counter exploitation of a software logic 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 This applies to both operational and non-operational storage. Page 13
DEP.1 - Deploy >> Device Configuration DEP.1.M12: Passphrase is set to suitable size and complexity This mitigation is required to counter exploitation of poor passphrase 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 Page 14
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 This mitigation is required to counter exploitation of a software logic At Foundation Grade the deployment is required to regularly review audit logs for unexpected entries Page 15
DEP.2.M159: Update product This mitigation is required to counter exploitation of a software logic 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 This mitigation is required to counter exploitation of omission/ in rule configuration 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 This mitigation is required to counter exploitation of omission/ in rule configuration 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 Page 16
IV. GLOSSARY 24. The following definitions are used in this document: Term ASLR Black side (of network) CA CPA DSA ECDSA HTTPS IP ISP JTAG Red side (of network) Ruleset Security Characteristic SHA Meaning Address Space Layout Randomisation The less trustworthy network Certificate Authority Commercial Product Assurance Digital Signature Algorithm Elliptic Curve Digital Signature Algorithm Hypertext Transport Protocol Secure Internet Protocol Internet Service Provider Joint Test Action Group The network which is more trustworthy The set of rules that determine how a packet is handled by the firewall 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 Secure Hash Algorithm SNMPv3 Simple Network Management Protocol version 3 SME SSH Small-Medium Enterprise Secure Shell Page 17
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. Page 18
THIS PAGE IS INTENTIONALLY LEFT BLANK Page 19