chrisbst48/IT-Grundschutz-Compendium_2022_EN huggingface dataset:
NET.1.2.A10 Limitation of SNMP Communication (B)
In principle, insecure versions of the Simple Network Management Protocol (SNMP) MUST NOT be used in network management. If insecure protocols are nevertheless used and not secured via other secure network protocols (e.g. VPN or TLS), a separate management network MUST be used. As a matter of principle, SNMP SHOULD ONLY be used for access with the minimum access rights required. The access authorisations SHOULD be limited to dedicated management servers.
NET.1.2.A11 Definition of a Security Policy for Network Management (S)
For network management, a security policy SHOULD be drawn up and continuously maintained. All persons involved in network management SHOULD be familiar with the security policy. The security policy SHOULD form the basis of their work. Regular and transparent reviews SHOULD be conducted to ensure that the policy's requirements are being implemented. The results SHOULD be appropriately documented. The security policy SHOULD define which areas of network management are to be implemented using central management tools and services. It SHOULD also define the extent to which tasks in the network management of the organisation in question are to be implemented automatically. In addition, framework conditions and specifications SHOULD be specified for network separation, access control, logging, and communication protection. Framework conditions and specifications SHOULD also be specified for the network management tools used and for the basic operational rules of network management.
NET.1.2.A12 Current Inventory and Documentation of Network Management (S)
Documentation SHOULD be drawn up that describes the management infrastructure of the network in question. It SHOULD include an initial inventory and all changes made in network management. In particular, it SHOULD document which network components are administered using which management tools. Furthermore, all IT workstations and end devices used for network management, as well as all information and management data available on network management operations, SHOULD be included. Ultimately, all interfaces to applications and services outside of the network management system at hand SHOULD be documented The resulting documentation of the actual status of the management infrastructure SHOULD be compared against the network infrastructure documentation (see module NET.1.1 Network Architecture and Design). The documentation SHOULD be complete and up to date at all times.
NET.1.2.A13 Drawing Up a Network Management Concept (S)
Based on the security policy drawn up for network management, a network management concept SHOULD be established and consistently maintained. In doing so, the following minimum aspects SHOULD be taken into account as required: • Methods, techniques, and tools for network management • Protection of access and communication • Network separation, in particular the assignment of network management components to zones • The scope of monitoring and alerts for each network component • Logging • Automation (particularly of the central distribution of configuration files to switches) • Reporting chains in the event of malfunctions and security incidents • Provisioning of network management information for other areas of the organisation in question • Integration of network management into contingency planning
NET.1.2.A14 Detailed and Implementation Planning (S)
Detailed and implementation planning SHOULD be drawn up for network management infrastructure. It SHOULD consider all the items addressed in the respective security policy and network management concept.
NET.1.2.A15 Concept for Secure Operation of Network Management Infrastructure (S)
A concept for secure operation of network management infrastructure SHOULD be drawn up based on the relevant security policy for network management and the network management concept. This concept SHOULD take into account the application and system operations for the network management tools in use. The manner in which the performance of other operative units can be integrated and controlled SHOULD also be checked.
NET.1.2.A16 Setup and Configuration of Network Management Solutions (S)
Network management solutions SHOULD be established, configured securely, and put into operation based on the security policy, the specified requirements (see NET1.2.A2 Specification of Network Management Requirements), and the detailed and implementation plan in the case at hand. Afterwards, the specific processes for network management SHOULD be set up.
NET.1.2.A17 Regular Gap Analysis within the Framework of Network Management (S)
The extent to which the network management solution in use corresponds to the target state SHOULD be checked regularly and transparently. In so doing, whether the existing solution still complies with the relevant security policy and requirements specification SHOULD be checked. The extent to which the management structure implemented and the processes used comply with the current status SHOULD also be checked. A comparison SHOULD also be made to determine whether the management infrastructure is up to date.
NET.1.2.A18 Training Measures for Management Solutions [Supervisor] (S)
Training measures SHOULD be developed and carried out for the network management solutions used. The measures SHOULD cover the individual circumstances at hand in terms of configuration, availability, and capacity management, as well as typical situations in the field of error management. The training SHOULD be repeated at regular intervals, but at least when there are major technical or organisational changes within the network management solution in use.
NET.1.2.A2 Specification of Network Management Requirements (B)
Based on NET.1.2.A1 Network Management Planning, requirements for the network management infrastructure and processes in question MUST be specified. In so doing, all the essential elements of network management MUST be taken into account. The network management policy at hand SHOULD also be considered.
NET.1.2.A21 Decoupling of Network Management Communication (S)
Administrators SHOULD avoid using direct management access to interface with network components from IT systems outside of their organisation's management networks. If such access is necessary without a central management tool, the communication SHOULD be decoupled. Jump servers of this kind SHOULD be integrated into the management network in question and located in a separate access segment.
NET.1.2.A22 Restriction of Management Functions (S)
The management functions enabled SHOULD be limited to those that are actually required.
NET.1.2.A24 Central Configuration Management for Network Components (S)
It SHOULD be possible to automatically distribute, install, and activate software, firmware, configuration data, and network components over a given network without interrupting operations. The information required for this SHOULD be securely available from a central point and integrated into version management and data backup processes. The central configuration management used for this purpose SHOULD be maintained continuously and audited regularly.
NET.1.2.A25 Status Monitoring for Network Components (S)
The basic performance and availability parameters of central network components SHOULD be monitored continuously. For this purpose, the respective threshold values SHOULD be determined in advance (baselining).
NET.1.2.A26 Alarming and Logging (S)
Important events on network components and network management tools SHOULD be automatically transmitted to a central management system and logged there (see OPS.1.1.5 Logging). In addition, the persons in charge SHOULD be informed automatically. Alerts and logging SHOULD include the following items at minimum: • Failure and non-availability of network or management components • Hardware malfunctions • Failed login attempts • Critical conditions or overloading of IT systems Event messages and log data SHOULD be transmitted to a central management system either continuously or in a bundled manner. Alarm messages SHOULD be transmitted as soon as they occur.
NET.1.2.A27 Integration of Network Management into Contingency Planning (S)
An organisation's network management solutions SHOULD be integrated into its contingency planning. To this end, network management tools and the configurations of network components SHOULD be backed up and integrated into the organisation's recovery schemes.
NET.1.2.A28 Location of Management Clients for In-Band Management (S)
Dedicated management clients SHOULD be used for administering both internal and external IT systems. To this end, one management client SHOULD be located in the external network area (for administering IT systems connected to the Internet) and another in the internal area (for administering internal IT systems).
NET.1.2.A29 Using VLANS in the Management Network (S)
If management networks are separated by VLANs, it SHOULD be ensured that the external packet filter and the devices connected to this filter are located in their own sub-network. It MUST also be ensured that the ALG is not bypassed in this process.
NET.1.2.A30 Implementing Management Solutions for High Availability (H)
Central management solutions SHOULD be operated in manner that ensures high availability. To this end, the servers and tools involved (including their network connections) SHOULD be designed redundantly. The individual components SHOULD also be provided in a highly available manner.
NET.1.2.A31 Basic Use of Secure Protocols (H)
Only secure protocols SHOULD be used for network management. All the security features of these protocols SHOULD be used.
NET.1.2.A32 Physical Separation of the Management Network [Planner] (H)
An organisation's management network SHOULD be separated physically from its productive networks.
NET.1.2.A33 Physical Separation of Management Segments [Planner] (H)
At minimum, physically separated zones SHOULD be established for managing LAN components, security components, and components for external connections.
NET.1.2.A35 Specifications for Securing Evidence (H)
Collected log data SHOULD be archived for forensic analysis in a legally compliant and audit-compliant manner (see also DER.2.2 Provisions for IT Forensics).
NET.1.2.A36 Integration of Network Management Logging into an SIEM Solution (H)
Network management logging SHOULD be integrated into a security information and event management (SIEM) solution. For this purpose, the requirements catalogues used to select network management solutions SHOULD be adapted to reflect the support required for interfaces and transmission formats (see NET.1.2.A2 Specification of Network Management Requirements).
NET.1.2.A37 Time Synchronisation Across Locations (H)
Time synchronisation SHOULD be ensured across all of an organisation's sites. A common reference time SHOULD be used for this purpose.
NET.1.2.A38 Specification of Forms of Emergency Operations for Network Management Infrastructure (H)
In order to quickly recover the target software or firmware status and configure the components of network management infrastructure, replacement solutions of a sufficient quality SHOULD be specified.
NET.1.2.A6 Regular Backups (B)
In terms of network management backups, the system data for integrating the components or objects to be managed, event messages, statistical data, and stored data for configuration management MUST be backed up at minimum.
NET.1.2.A7 Basic Logging of Events (B)
The following events MUST be logged at minimum: • Unauthorised access or access attempts • Performance or availability fluctuations of the network in question • Errors in automatic processes (e.g. during configuration distribution) • Restricted accessibility of network components
NET.1.2.A8 Time Synchronisation (B)
All network management components, including the integrated network components, MUST be synchronised. The time SHOULD be synchronised by means of the NTP service at every location within the local network in question. If a separate management network has been established, an NTP instance SHOULD be positioned within it.
NET.1.2.A9 Protection of Network Management Communication and Access to Network Management Tools (B)
Whenever network management communication takes place via production infrastructure, secure protocols MUST be used. If this is not possible, a dedicated administration network (out-of-band management) MUST be used (see NET.1.1 Network Architecture and Design). If network management tools are accessed from a network outside the management networks in question, authentication and encryption methods that are considered secure MUST be implemented.
NET.2.1 WLAN Operation
Target Object: Network / Order: R2
NET.2.1.A1 Definition of a Strategy for WLAN Usage (B)
Before WLANs are used in an organisation, the organisation's general strategy for communication through WLANs MUST be specified. In particular, the organisational units in which WLANs will be used, the applications and purposes they will be used for, and the information that may be transmitted MUST be clarified and defined. The WLAN coverage area MUST also be determined. Furthermore, it MUST be defined right from the planning phase who will be responsible for the administration of the various WLAN components, which interfaces will be in place between the persons in charge who are involved in WLAN operations, and when specific information must be exchanged among the persons in charge.
NET.2.1.A10 Drawing Up a Security Policy for WLAN Operation (S)
Based on the general security policy of the organisation in question, essential core aspects SHOULD be specified for the secure use of WLANs. The policy SHOULD be known to all persons in charge who are involved in establishing and operating WLANs. It SHOULD form the basis of their work. The implementation of the policy's requirements SHOULD be checked at regular intervals. If the contents of the policy are not implemented, there MUST be a suitable response. The results SHOULD be documented appropriately.
NET.2.1.A11 Selection of Suitable WLAN Components (S)
Based on the results of the planning phase, a requirements list SHOULD be drawn up that can be used to help evaluate the products available on the market. When procuring WLAN components, data protection and the intercompatibility of the components SHOULD be taken into account along with security.
NET.2.1.A12 Use of a Suitable WLAN Management Solution (S)
A central management solution SHOULD be used. The functional range of the solution used SHOULD be in accordance with the requirements of the WLAN strategy at hand.
NET.2.1.A13 Regular Security Checks of WLANs (S)
WLANs SHOULD be checked regularly for security vulnerabilities. In addition, the WLANs provided SHOULD be searched regularly for access points that have been installed without authorisation. Their performance and coverage SHOULD also be measured. The results of security checks SHOULD be documented transparently and compared against the target condition. Deviations SHOULD be investigated.
NET.2.1.A14 Regular Audits of WLAN Components (S)
All components of WLAN infrastructure SHOULD be checked regularly to ensure that all the specified security safeguards have been implemented and all the components have been configured correctly. Access points mounted in public areas SHOULD be checked randomly at regular intervals to determine whether there have been attempts to open or manipulate them by force. The results of such audits SHOULD be documented transparently and compared against the target condition. Deviations SHOULD be investigated.
NET.2.1.A15 Using a VPN to Secure WLANs (H)
A VPN SHOULD be used to achieve additional protection of WLAN communications.
NET.2.1.A16 Additional Protection When Connecting WLANs to a LAN (H)
If a WLAN infrastructure is connected to a LAN, the transition between WLANs and the LAN SHOULD be secured in line with the applicable increased protection needs.
NET.2.1.A17 Protecting Communication Between Access Points (H)
Communication between access points via the wireless interface and the LAN SHOULD be encrypted.
NET.2.1.A18 Use of Wireless Intrusion Detection / Wireless Intrusion Prevention Systems (H)
Wireless intrusion detection or prevention systems SHOULD be used.
NET.2.1.A2 Selection of a Suitable WLAN Standard [Planner] (B)
Within the framework of WLAN planning, there MUST be an initial determination of which of the devices operated by the organisation in question (e.g. microwave ovens, Bluetooth devices) radiate into the ISM band at 2.4 GHz and into the 5 GHz band. In addition, the security mechanisms available in the individual WLAN standards MUST be compared. In general, it MUST be ensured that only authentication and encryption methods that are generally considered secure will be used. The organisation MUST document its reasons for choosing a particular WLAN standard. Devices that need to fall back on insecure methods from recognised secure methods MUST NOT be used.
NET.2.1.A3 Selection of Suitable Crypto Methods for WLAN [Planner] (B)
Communication via the air interface MUST be completely secure in cryptographic terms. Cryptographic methods that are less secure than WPA2 MUST NOT be used. If WPA2 is used with pre-shared keys (WPA2-PSK), a complex key with a minimum length of 20 characters MUST be used.
NET.2.1.A4 Suitable Location of Access Points [Building Services] (B)
Access points MUST be mounted such that they cannot be accessed or stolen. If they are set up, the required areas MUST be adequately covered. Furthermore, it MUST be ensured to the greatest extent possible that the radio waves are not emitted into areas not designated for WLAN coverage. Outside installations MUST be protected appropriately against weather and electrical discharges.
NET.2.1.A5 Secure Basic Configuration of Access Points (B)
Access points MUST NOT be used in their default configuration. Pre-set SSIDs (service set identifiers), passwords, and cryptographic keys MUST be changed prior to productive use. In addition, insecure administration access MUST be disabled. Access points MUST ONLY be administered via a suitably encrypted connection.
NET.2.1.A6 Secure Configuration of WLAN Infrastructure (B)
It MUST be ensured that WLAN communication is not used to couple security zones or bypass established protection safeguards.
NET.2.1.A7 Setting Up a Distribution System [Planner] (B)
Before a wired distribution system is established, a basic decision MUST be made as to whether separation will be performed physically or logically through VLANs on the access switches of the wired LAN in question.
NET.2.1.A8 Codes of Conduct in the Event of WLAN Security Incidents (B)
If a security incident occurs, the IT Operation Department MUST initiate appropriate countermeasures: • At the point where WLAN communication enters the internal LAN in question, communication SHOULD be blocked selectively for every SSID and access point—or even for the entire WLAN infrastructure—in the event of an attack. • If access points have been stolen, defined security safeguards MUST be implemented to prevent any misuse of the access points or the information stored on them. • If WLAN clients have been stolen and central certificate-based authentication is being used, the client certificates MUST be blocked. The possibility of using stolen devices without authorisation in order to access the network of a given organisation MUST be ruled out.
NET.2.1.A9 Secure Connection of WLANs to a LAN [Planner] (S)
If WLANs are connected to a LAN, the transition between the WLANs and the LAN SHOULD be protected—for example, with the help of a packet filter. The access point SHOULD be integrated in line with the requirements of NET.2.1.A7 Setting Up a Distribution System.
NET.2.2 WLAN Usage
Target Object: IT system / Order: R2
NET.2.2.A1 Creating a User Policy for WLAN [IT Operation Department] (B)
The essential core aspects of secure WLAN usage MUST be specified in a WLAN user policy based on the general security policy of the organisation in question. This user policy MUST describe the particularities of WLAN usage, such as whether, how, and with what devices hotspots may be used. The policy MUST contain information on which data may be used and transmitted over a WLAN and which may not. It MUST describe how to handle client-side security solutions. The user policy MUST contain a clearly stated ban on connecting unauthorised access points to the network of the respective organisation. Moreover, the policy MUST state that WLAN interfaces must be disabled if they are not used for a longer period. There MUST be regular checks to ensure that the policy's requirements have been implemented correctly. If this is not the case, there MUST be an appropriate response. The results SHOULD be appropriately documented.
NET.2.2.A2 Awareness and Training of WLAN Users [Supervisor, IT Operation Department] (B)
The users of WLAN components (mainly WLAN clients) MUST be made aware of and trained on the safeguards stated in the corresponding user policy. Suitable training MUST be identified and established for this purpose. What WLAN-specific security settings mean and why they are important MUST be explained in detail to users. In addition, users MUST be informed of the threats that result from bypassing or disabling these security settings. The training content in question MUST always be adapted to the respective operational scenarios. In addition to training on WLAN security mechanisms, users MUST be given a copy of their organisation's WLAN security policy and made aware of the measures it contains. Users MUST also be made aware of the possible dangers posed by unfamiliar WLANs.
NET.2.2.A3 Safeguarding WLAN Usage in Hotspots [IT Operation Department] (B)
If the use of external hotspots is permitted, the following MUST be implemented: • Every user of a hotspot MUST know the security requirements and then decide if and under which conditions hotspot usage is allowed. • If hotspots are used, it SHOULD be ensured that the connection between the hotspot access point and the user’s IT system is cryptographically secured according to the state of the art. • WLANs that are only used sporadically SHOULD be deleted from users' histories. • The option to log into WLANs automatically SHOULD be disabled. • If possible, separate user accounts with a secure basic configuration and restrictive authorisations SHOULD be used. • It SHOULD be ensured that users with administrator authorisations can never log into external WLANs from their clients. • In order to transmit sensitive data, all the necessary security safeguards (especially appropriate encryption) MUST be activated on the clients involved. • If a WLAN interface is not used over an extended period of time, it MUST be disabled. • When using publicly available WLANs, users MUST use a virtual private network (VPN) to access internal resources of their organisation.
NET.2.2.A4 Codes of Conduct in the Event of WLAN Security Incidents (S)
In case of WLAN security incidents, users SHOULD act as follows: • Users SHOULD save their work. • They should terminate their WLAN connection and disable the WLAN interface on their client. • Users SHOULD document any error messages and deviations as precisely as possible. Users SHOULD also document what they were doing before and during the security incident. • Users SHOULD notify the IT Operation Department via a suitable escalation level (e.g. the user help desk). If the WLAN interface in question is not used for a longer period of time, it MUST be disabled. • When using publicly available WLANs, users MUST use a virtual private network (VPN) to access internal resources of their organisation.
NET.3.1 Routers and Switches
Target Object: IT system / Order: R2