NET.3.2 Firewall

A specific security policy for firewalls MUST be drawn up based on the general security policy of the organisation in question. The specific policy MUST transparently describe the requirements and specifications for securely operating firewalls. The policy MUST be known to all employees in charge in firewalls and be integral to their work. If the policy is changed or deviations from the requirements are allowed, this MUST be coordinated with the CISO and documented. The correct implementation of the policy MUST be regularly reviewed. The results MUST be documented in an appropriate manner.

All communications between two given networks MUST pass through a firewall. It MUST be ensured that no unauthorised connections from the outside can be established with a protected network. In addition, unauthorised connections MUST NOT be established from a protected network.

Unambiguous rules MUST be defined for a firewall that specify which communication links and data streams are allowed. Any other connections MUST be prevented by the firewall (whitelist approach). The communication relationships with connected service servers that are routed through the firewall MUST be taken into consideration in its rules.

Persons in charge MUST be appointed to develop, implement, and test filter rules. In addition, it MUST be clear who is allowed to change filter rules. The decisions taken and the relevant information and reasons for them MUST be documented.

Based on the firewall rules from NET.3.2.A2 Definition of Firewall Rules, appropriate filter rules must be defined and configured for the packet filter.

A packet filter MUST be configured to discard any invalid TCP flag combinations. As a matter of principle, filtering MUST always be performed in a stateful manner. Stateful filter rules MUST also be configured for the connectionless protocols UDP and ICMP. A firewall MUST filter the ICMP and ICMPv6 protocols restrictively.

Before a firewall is used, it MUST be configured securely. All configuration changes MUST be documented transparently. The integrity of the configuration files MUST be protected appropriately. Before access passwords are stored, they MUST be secured using an up-to-date cryptographic method (see CON.1 Crypto Concept). A firewall MUST be configured in such a way that only the services absolutely required are available. If functional extensions are used, the security policies of the organisation in question MUST continue to be met. The use of such extensions MUST also be justified and documented. Any unnecessary (information) services and functional extensions MUST be disabled or uninstalled completely. Information on internal configurations and operating statuses MUST be hidden from third parties whenever possible.

All administration and management access to firewalls MUST be restricted to individual source IP addresses or address ranges. It MUST be ensured that it is not possible to access administration interfaces from untrustworthy networks.

Only secure protocols MUST be used to manage or monitor firewalls. Alternatively, a dedicated administration network (out-of-band management) MUST be used. Appropriate time limits MUST be specified for the user interfaces.

It MUST always be possible to access a firewall directly in order to manage it locally, even if the entire network has failed.

Dynamic routing MUST be disabled in the settings of a firewall unless the packet filter is being used as a perimeter router in accordance with module NET.3.1 Routers and Switches.

Firewalls MUST be configured to log the following events at minimum:

• rejected network connections (source and destination IP addresses, source and destination ports or ICMP/ICMPv6 type, dates, times)
• failed attempts to access system resources due to improper authentication, lack of authorisation, lack of resources
• error messages from firewall services
• general system error messages
• configuration changes (automatically whenever possible)

If security proxies are used, security breaches and violations of access control lists (ACLs or access lists) MUST be logged in a suitable manner. The types of protocol violations or ACL violations, source and destination IP addresses, source and destination ports, services, dates and times and, if necessary, the duration of connections MUST be logged at minimum.

When a user provides authentication to a security proxy, either the authentication data or solely the information on a failed authentication attempt MUST also be logged.

Protection mechanisms MUST be enabled on packet filters in order to fend off IPv4 and IPv6 fragmentation attacks.

The operational tasks of a firewall MUST be documented in a transparent manner. All configuration changes and security-relevant tasks MUST be documented—in particular, changes made to the system services and the rule set of the firewall. This documentation MUST be protected against unauthorised access.

Prior to procuring a firewall, a requirements list MUST be drawn up that can be used to evaluate the products available on the market. It SHOULD be ensured that the desired security level of the organisation in question can be achieved with the firewall it selects. Hence, the procurement process MUST be based on the requirements of the organisation's security policy.

If IPv6 is used, the packet filter MUST check IPv6 extension headers. Furthermore, it MUST be possible to configure IPv6 adequately for IPv4.

A "packet filter – application level gateway – packet filter" (P-A-P) structure SHOULD be used. It MUST consist of several components, each with appropriate hardware and software. Application layer security proxies SHOULD be available for the main protocols used. For other services, at least generic security proxies for TCP and UDP SHOULD be used. The security proxies SHOULD also be executed in a secured runtime environment of the operating system in use.

If IPv4 or IPv6 protocol is not required in a given network segment, it SHOULD be disabled at the respective firewall network access point (e.g. at the corresponding firewall interface). If IPv4 or IPv6 protocol is not required or used, it SHOULD be disabled completely on the firewall.

Firewalls SHOULD only be administered using a separate management network (out-of-band management). Any administration interface available via the actual data network at hand (in-band) SHOULD be disabled. Communication in a management network SHOULD be limited to a few management protocols with well-defined origins and destinations via management firewalls (see NET.1.1 Network Architecture and Design). The available security mechanisms of the management protocols used for authentication, integrity assurance, and encryption SHOULD be activated. All insecure management protocols SHOULD be disabled (see NET.1.2 Network Management).

On packet filters protecting server services that are available from untrustworthy networks, a suitable limit SHOULD be configured for semi-open and open connections.

On packet filters protecting server services that are available from untrustworthy (or less trustworthy) networks, rate limits SHOULD be set for UDP data streams.

On outer packet filters, the random generation of initial sequence numbers (ISN) SHOULD be enabled for outgoing TCP connections unless this is already implemented by security proxies.

The protocols HTTP, SMTP, and DNS (including their encrypted versions) SHOULD be routed via protocol-specific security proxies.

Encrypted connections to untrusted networks SHOULD be decrypted temporarily in order to verify the protocol and check the data for malware. In so doing, the relevant legal framework conditions SHOULD be taken into consideration.

The component that temporarily decrypts data traffic SHOULD prevent the use of outdated encryption options and cryptographic algorithms.

The TLS proxy SHOULD also be able to check whether certificates are trustworthy. If a certificate is not trustworthy, it SHOULD be possible to reject the respective connection. It SHOULD be possible to subsequently integrate proprietary certificates in order to be able to configure and check “internal” root certificates, as well. Pre-configured certificates SHOULD be checked and removed if they are not required.

A firewall's system time SHOULD be synchronised with a Network Time Protocol (NTP) server. Firewalls SHOULD not permit external time synchronisation.

Firewalls SHOULD be integrated into an appropriate system monitoring concept. Whether a firewall itself and the services operated on it are working properly SHOULD be constantly monitored. Should errors occur or thresholds be exceeded, the appropriate operational personnel SHOULD be alerted. Furthermore, alarm messages SHOULD be generated automatically for defined events. Log data or status messages SHOULD ONLY be transmitted using secure communication paths.

Firewall structures SHOULD be checked for known security issues at regular intervals. Regular penetration tests and audits SHOULD be performed.

Diagnosis and troubleshooting SHOULD be planned and prepared in advance. Appropriate actions SHOULD be defined for typical failure scenarios and updated at regular intervals.

Contingency planning for firewalls SHOULD be coordinated with an organisation's overall incident and emergency preparedness. It SHOULD be based on the general contingency planning concept at hand (see DER.4 Business Continuity Management). It SHOULD be ensured that contingency planning documentation and the instructions it contains are available in paper form. The procedure described in the contingency planning concept SHOULD be tested regularly.

When restoring a firewall that has crashed, it SHOULD be ensured that no legacy or incorrect configurations (among other things, access lists) are used. This SHOULD also apply if an attacker manages to restart a firewall.

Functional extensions of firewalls SHOULD be outsourced to dedicated hardware and software.

In a multi-tier firewall architecture, different operating systems and products SHOULD be used for the outer and inner firewalls.

Active content SHOULD be filtered in a centralised manner according to the security objectives of the organisation in question. To this end, the encrypted data traffic SHOULD also be decrypted. The required security proxies SHOULD support the filtering of active content.

Packet filters and application level gateways SHOULD be designed to ensure high availability. Furthermore, there SHOULD be two independent options for accessing external networks (e.g. Internet access through two different providers). Internal and external routers and any other active components involved (e.g. switches) SHOULD also be designed to ensure high availability.

Even after an automatic failover, firewall structures SHOULD comply with the requirements of the security policy at hand (e.g. "fail safe" or "fail secure").

This function SHOULD be monitored on the basis of multiple parameters. Function monitoring SHOULD not be based on a single criterion. The log files and warnings of high-availability solutions SHOULD be checked at regular intervals.

In order to ensure bandwidth management for critical applications and services, packet filters with a corresponding bandwidth management function SHOULD be used at network gateways and at the gateways between different security zones.

Firewalls with a Common Criteria security evaluation of at least level EAL4 SHOULD be used.