chrisbst48/IT-Grundschutz-Compendium_2022_EN huggingface dataset:
NET.3.1.A1 Secure Basic Configuration of a Router or Switch (B)
Prior to using a router or switch, it MUST be configured securely. All configuration changes SHOULD be documented in a transparent manner. 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). Routers and switches MUST be configured in such a way that only absolutely necessary services, protocols, and functional extensions are used. Services, protocols, and functional extensions that are not required MUST be disabled or uninstalled completely. Unused interfaces on routers and switches MUST also be disabled. If possible, unused network ports MUST be disabled or at least assigned to an unassigned VLAN set up for this purpose. If functional extensions are used, the security policies of the organisation in question MUST still be met. The use of such extensions SHOULD also be justified and documented. Information on internal configurations and operating statuses MUST be hidden from third parties. Unnecessary information services MUST be disabled.
NET.3.1.A10 Creating a Security Policy(S)
A specific security policy MUST be drawn up for routers and switches based on the general security policy of the organisation in question. This security policy SHOULD transparently describe the requirements and specifications for the secure operation of routers and switches. The policy SHOULD be known to all administrators and be integral to their work. If the policy is changed or deviations from the agreed requirements are allowed, this SHOULD be coordinated with the CISO and documented. It SHOULD be checked regularly whether the policy is still properly implemented. The results SHOULD be documented appropriately.
NET.3.1.A11 Procurement of a Router or Switch (S)
Prior to procuring routers and switches, a requirements list SHOULD be drawn up based on the relevant security policy 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 devices to be procured. The procurement process SHOULD thus be based on the requirements of the aforementioned security policy.
NET.3.1.A12 Drawing Up a Configuration Checklist for Routers and Switches (S)
A configuration checklist SHOULD be created that can be used to check the most important security-relevant settings on routers and switches. Since secure configurations strongly depend on the purpose at hand, the different requirements of these devices SHOULD be taken into consideration within the framework of the configuration checklist.
NET.3.1.A13 Administration Using a Separate Management Network (S)
Routers and switches SHOULD only be administered via a separate management network (out-of-band management). If one exists, the administration interface via the actual data network at hand (in-band) SHOULD be disabled. 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.
NET.3.1.A14 Protection Against Misuse of ICMP Messages (S)
The protocols ICMP and ICMPv6 SHOULD be filtered restrictively.
NET.3.1.A15 Bogon and Spoofing Filtering (S)
Attackers SHOULD be prevented from entering routers and switches with the help of forged, reserved, or unassigned IP addresses.
NET.3.1.A16 Protection Against “IPv6 Routing Header Type-0” attacks (S)
When using IPv6, mechanisms SHOULD be used to detect and prevent attacks on the type-0 routing header.
NET.3.1.A17 Protection Against DoS and DDoS Attacks (S)
Mechanisms SHOULD be used that detect and fend off high-volume attacks and TCP state exhaustion attacks.
NET.3.1.A18 Configuration of Access Control Lists (S)
Access to routers and switches SHOULD be defined with the help of access control lists (ACLs). Based on the security policy of the organisation in question, the ACL SHOULD define which IT systems or networks (and corresponding methods) may be used to access a router or switch. If there are no specific rules, a restrictive whitelist approach SHOULD be preferred as a matter of principle.
NET.3.1.A19 Protection of Switch Ports (S)
The ports of a switch SHOULD be protected against unauthorised access.
NET.3.1.A20 Security Aspects of Routing Protocols (S)
Routers SHOULD authenticate themselves when exchanging routing information or transmitting updates for routing tables. Only routing protocols that support this SHOULD be used. Dynamic routing protocols SHOULD only be used in secure networks. They MUST NOT be used in demilitarised zones (DMZs). In DMZs, static routes SHOULD be entered instead.
NET.3.1.A21 Identity and Authorisation Management in Network Infrastructure (S)
Routers and switches SHOULD be connected to a central identity and authorisation management system (see ORP.4 Identity and Access Management).
NET.3.1.A22 Contingency Planning for Routers and Switches (S)
There SHOULD be planning and preparation for the errors in routers or switches that can be diagnosed in an emergency. There SHOULD also be planning and preparation regarding how to remedy the errors identified. Appropriate instructions SHOULD be defined for typical failure scenarios and updated at regular intervals. The contingency planning for routers and switches SHOULD be coordinated with overarching fault and contingency planning. The contingency planning SHOULD be based on the general contingency planning concept at hand (see DER.4 Business Continuity Management). It SHOULD be ensured that the contingency planning documentation and the instructions they contain are available in paper form. The procedure described in the contingency planning concept SHOULD be tested regularly.
NET.3.1.A23 Audits and Penetration Tests (S)
Routers and switches SHOULD be checked for known security issues at regular intervals. Audits SHOULD also be performed regularly. This SHOULD include checking whether the actual situation corresponds to the basic configuration defined as secure. The results SHOULD be clearly documented and compared against the target situation. Deviations SHOULD be investigated.
NET.3.1.A24 Use of Network Access Controls (H)
Port-based access control according to IEEE 802.1x SHOULD be implemented on the basis of EAP-TLS. Implementations according to the standards IEEE 802.1x-2001 and IEEE 802.1x-2004 SHOULD NOT be performed.
NET.3.1.A25 Advanced Integrity Protection for Configuration Files (H)
If a router or switch crashes, it SHOULD be ensured that no legacy or incorrect configurations (including ACLs) are used when recovering and restarting the device.
NET.3.1.A26 High Availability (H)
The implementation of a high-availability solution SHOULD NOT impair the operation of routers and switches or their security features, or reduce the level of security. Routers and switches SHOULD be designed redundantly. In so doing, it SHOULD be ensured that the security policy of the organisation in question is observed.
NET.3.1.A27 Bandwidth Management for Critical Applications and Services (H)
Routers and switches SHOULD include and use features that can detect applications and prioritise bandwidths.
NET.3.1.A28 Use of Certified Products (H)
Routers and switches with a Common Criteria security evaluation of at least EAL4 SHOULD be used.
NET.3.1.A4 Protection of Administration Interfaces (B)
All administration and management access to routers and switches MUST be restricted to individual source IP addresses or address ranges. It MUST be ensured that it is not possible to access the administration interfaces directly from untrusted networks. Suitably encrypted protocols SHOULD be used to administer and monitor routers and switches. If unencrypted protocols are nevertheless used, a separate administration network (out-of-band management) MUST be used for administration. The management interfaces and administration connections MUST be protected by means of a separate firewall. Appropriate time limits MUST be specified for the interfaces (e.g. for timeouts). All services not required for management interfaces MUST be disabled. If a network component has a dedicated hardware interface, any unauthorised access to this interface MUST be prevented appropriately.
NET.3.1.A5 Protection Against Fragmentation Attacks (B)
Protection mechanisms MUST be enabled on routers and layer 3 switches in order to fend off IPv4 and IPv6 fragmentation attacks.
NET.3.1.A6 Emergency Access to Routers and Switches (B)
Administrators MUST always be capable of directly accessing routers and switches to ensure continuous administration even if an entire network fails.
NET.3.1.A7 Logging on Routers and Switches (B)
A router or switch MUST be configured in such a way that it logs the following events, among others: • Configuration changes (automatically whenever possible) • Reboots • System errors • Status changes for each interface, system, and network segment • Login errors
NET.3.1.A8 Regular Backups (B)
The configuration files of routers and switches MUST be backed up at regular intervals. The backup copies MUST be created in such a way that they can be accessed in an emergency.
NET.3.1.A9 Operational Documentation (B)
The most important operational tasks of a router or switch MUST be documented appropriately. All configuration changes and security-relevant tasks SHOULD be documented. The documentation SHOULD be protected against unauthorised access.
NET.3.2 Firewall
Target Object: IT system / Order: R2
NET.3.2.A1 Creating a Security Policy (B)
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.
NET.3.2.A10 Protection Against Fragmentation Attacks on the Packet Filter (B)
Protection mechanisms MUST be enabled on packet filters in order to fend off IPv4 and IPv6 fragmentation attacks.
NET.3.2.A14 Operational Documentation (B)
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.
NET.3.2.A15 Procuring a Firewall (B)
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.
NET.3.2.A16 Creation of a “P-A-P” structure (S)
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.
NET.3.2.A17 Disabling IPv4 or IPv6 (S)
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.
NET.3.2.A18 Administration Using a Separate Management Network (S)
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).
NET.3.2.A19 Protection Against TCP SYN Flooding, UDP Packet Storms, and Sequence Number Guessing on the Packet Filter (S)
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.
NET.3.2.A2 Definition of Firewall Rules (B)
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.
NET.3.2.A20 Protection of Fundamental Internet Protocols (S)
The protocols HTTP, SMTP, and DNS (including their encrypted versions) SHOULD be routed via protocol-specific security proxies.
NET.3.2.A21 Temporary Decryption of Data Traffic (S)
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.
NET.3.2.A22 Secure Time Synchronisation (S)
A firewall's system time SHOULD be synchronised with a Network Time Protocol (NTP) server. Firewalls SHOULD not permit external time synchronisation.
NET.3.2.A23 System Monitoring and Evaluation (S)
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.
NET.3.2.A24 Audits and Penetration Tests (S)
Firewall structures SHOULD be checked for known security issues at regular intervals. Regular penetration tests and audits SHOULD be performed.
NET.3.2.A25 Advanced Integrity Protection for Configuration Files (H)
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.
NET.3.2.A26 Outsourcing of Functional Extensions to Dedicated Hardware (H)
Functional extensions of firewalls SHOULD be outsourced to dedicated hardware and software.
NET.3.2.A27 Use of Different Firewall Operating Systems and Products in Multi-Layer Firewall Architecture (H)
In a multi-tier firewall architecture, different operating systems and products SHOULD be used for the outer and inner firewalls.
NET.3.2.A28 Central Filtering of Active Content (H)
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.
NET.3.2.A29 Use of High-Availability Solutions (H)
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.
NET.3.2.A3 Configuring Appropriate Filter Rules on the Packet Filter (B)
Based on the firewall rules described in NET.3.2.A2 Definition of Firewall Rules, appropriate filter rules for packet filters MUST be defined and configured. 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.
NET.3.2.A30 Bandwidth Management for Critical Applications and Services (H)
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.
NET.3.2.A31 Use of Certified Products (H)
Firewalls with a Common Criteria security evaluation of at least level EAL4 SHOULD be used.
NET.3.2.A32 Firewall Contingency Planning (S)
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.
NET.3.2.A4 Secure Firewall Configuration (B)
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.
NET.3.2.A6 Protection of Administration Interfaces (B)
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.
NET.3.2.A7 Emergency Access to the Firewall (B)
It MUST always be possible to access a firewall directly in order to manage it locally, even if the entire network has failed.
NET.3.2.A8 Prevention of Dynamic Routing (B)
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.
NET.3.2.A9 Logging (B)
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.
NET.3.3 VPN
Target Object: IT system / Order: R2
NET.3.3.A1 Planning the Use of VPNs (B)
The introduction of a VPN MUST be planned carefully. The responsibilities for operating the VPN MUST be defined. User groups and their authorisations MUST also be planned for the VPN. Moreover, it MUST be defined how access authorisations that are granted, changed, or withdrawn are to be documented.
NET.3.3.A10 Secure Operation of a VPN (S)
An operational concept SHOULD be created for VPNs. This SHOULD include the aspects of quality management, monitoring, maintenance, training, and authorisation.
NET.3.3.A11 Secure Integration of an External Network (S)
It SHOULD be ensured that VPN connections are ONLY created between the intended IT systems and services. The tunnel protocols used for this SHOULD be suitable for such use.
NET.3.3.A12 User and Access Management for Remote Access VPNs (S)
In cases involving remote access VPNs, central and consistent user and access management SHOULD be ensured.
NET.3.3.A13 Integration of VPN Components into a Firewall (S)
VPN components SHOULD be integrated into a firewall. This SHOULD be documented.
NET.3.3.A2 Selection of an Appropriate VPN Service Provider (B)
If a VPN service provider is to be used, service level agreements (SLAs) MUST be negotiated and documented in writing. The VPN service provider's compliance with the agreed SLAs MUST be checked regularly.