chrisbst48/IT-Grundschutz-Compendium_2022_EN huggingface dataset:
SYS.4.3.A12 Selection of a Trustworthy Supplier and Logistics Chain and a Qualified Manufacturer for Embedded Systems [Procurement Department] (H)
Effective controls SHOULD be carried out in the logistics chain to ensure the following: • Embedded systems do not include any manipulated, falsified, or replaced components. • Embedded systems meet the respective specifications and no hidden functions have been implemented during manufacture. • Confidential information on embedded systems cannot be accessed by unauthorised persons. The companies involved SHOULD be demonstrably qualified.
SYS.4.3.A13 Use of a Certified Operating System [Developer, Planner, Procurement Department] (H)
The operating system in use SHOULD be evaluated at an adequate level according to a recognised standard.
SYS.4.3.A14 Secured and Authenticated Boot Process for Embedded Systems [Developer, Planner, Procurement Department] (H)
The boot process of an embedded system SHOULD be secured by the boot loader based on its ability to check the integrity of the operating system and only load it when it is classified as correct. By the same token, the operating system SHOULD also check the integrity of the boot loader. A multi-stage boot concept SHOULD be used that can check the individual steps in a cryptographically secure manner. Secure hardware trust anchors SHOULD also be used. ARM Secure Boot SHOULD be used in ARM-based embedded systems. Secure Boot SHOULD be used with a Unified Extensible Firmware Interface (UEFI).
SYS.4.3.A15 Storage Protection in Embedded Systems [Developer, Planner, Procurement Department] (H)
Memory protection mechanisms SHOULD be considered right from the design of embedded systems. The type of storage protection and the number and size of the protected areas SHOULD be appropriate for this purpose.
SYS.4.3.A16 Tamper Protection for Embedded Systems [Planner] (H)
A tamper protection concept SHOULD be developed for embedded systems. Adequate mechanisms SHOULD be established to detect, record, and prevent tampering. Adequate guidelines SHOULD also be established on how to respond to tampering.
SYS.4.3.A17 Automatic Monitoring of Assembly Functions [Planner, Procurement Department] (H)
All the assemblies of an embedded system with higher availability and integrity requirements SHOULD be equipped with integrated self-testing equipment (built-in self-test, BIST). Tests SHOULD check the integrity of the system when it is turned on and at adequate intervals during its operation. Where possible, the self-test functions SHOULD also check assemblies' security functions and properties. The integrity of the memory and I/O components SHOULD be checked regularly within the framework of the BIST. Existing BIST functions SHOULD be supplemented by the functions required if possible.
SYS.4.3.A18 Resistance of Embedded Systems to Side-Channel Attacks [Developer, Procurement Department] (H)
To make embedded systems resistant to side-channel attacks, appropriate precautions SHOULD be taken against non-invasive and (semi-) invasive side-channel attacks.
SYS.4.3.A2 Disabling Unused Interfaces and Services of Embedded Systems [Developer] (B)
It MUST be ensured that only required interfaces can be accessed. Only the required services MAY be activated. Access to application interfaces MUST be protected by means of secure authentication.
SYS.4.3.A3 Logging Security-Relevant Events in Embedded Systems (B)
Security breaches MUST be logged (see OPS.1.1.5 Logging). If electronic logging is not feasible or only possible to a very limited extent, alternative organisational rules SHOULD be created and implemented.
SYS.4.3.A4 Creating Procurement Criteria for Embedded Systems [Procurement Department] (S)
Before an embedded system is procured, a requirements list MUST be drawn up that can be used to evaluate the systems or components available on the market. The requirements list SHOULD include the following security-relevant aspects at minimum: • Aspects of material security • Requirements for hardware security properties • Requirements for software security properties • Support for a Trusted Platform Module (TPM) through the operating system • Security aspects of the development environment • Organisational security aspects
SYS.4.3.A5 Protecting Embedded Systems Against Damaging Environmental Influences [Developer, Planner] (S)
It SHOULD be ensured that embedded systems are adequately protected from harmful environmental influences according to their intended use and location. The requirements for this SHOULD be analysed right from the planning phase. It SHOULD also be ensured that the precautions taken to protect individual components from dust and contamination are compatible with the requirements of the overarching system at hand.
SYS.4.3.A6 Preventing Debugging Options for Embedded Systems [Developer] (S)
Possible debugging options SHOULD be removed from embedded systems as completely as possible. If on-chip debugging is used, it MUST be ensured that debugging functions cannot be used or activated by unauthorised persons. It SHOULD also be ensured that no input interfaces for test signals or measuring points for connecting analysers can be activated or used by unauthorised persons. All hardware debugging interfaces SHOULD also be disabled.
SYS.4.3.A7 Hardware Realisation of the Features of Embedded Systems [Developer, Planner, Procurement Department] (S)
If embedded systems are developed in-house, security aspects SHOULD be taken into account when taking decisions on hardware and software design. Security aspects SHOULD also be taken into account when deciding to implement a particular hardware technology.
SYS.4.3.A8 Using a Secure Operating System for Embedded Systems [Developer, Planner, Procurement Department] (S)
The operating system used and the configuration of an embedded system SHOULD be suitable for its intended operation. The operating system SHOULD thus have sufficient security mechanisms for the task at hand. The required services and functions SHOULD be activated. The operating system SHOULD support the use of a Trusted Platform Module (TPM).
SYS.4.3.A9 Use of Cryptographic Processors or Coprocessors in Embedded Systems [Developer, Planner, Procurement Department] (S)
If an additional microcontroller is used for cryptographic calculations, its communication with the system microcontroller SHOULD be adequately secured. The required trust anchors SHOULD be realised for the embedded system in question. A chain of trust SHOULD also be implemented.
SYS.4.4 General IoT Devices
Target Object: IT system / Order: R2
SYS.4.4.A1 Criteria for Using IoT Devices (B)
IoT devices MUST have update functions. The respective manufacturers MUST provide an update process. The devices MUST allow for appropriate authentication. Hard-coded access data MUST NOT be present in the devices.
SYS.4.4.A10 Secure Installation and Configuration of IoT Devices (S)
The framework conditions applicable to the installation and configuration of IoT devices SHOULD be defined. IoT devices SHOULD only be installed and configured by authorised persons (persons in charge of IoT devices, administrators, or service providers bound by contracts) in accordance with a defined process. All installation and configuration steps SHOULD be documented such that they can be understood and repeated by a qualified third party based on the documentation. The basic settings of IoT devices SHOULD be checked and, where necessary, adapted to the specifications of the security policy in question. If possible, IoT devices SHOULD only be connected to data networks after installation and configuration are complete.
SYS.4.4.A11 Using Encrypted Data Transmission (S)
IoT devices SHOULD only transfer encrypted data.
SYS.4.4.A13 Deactivation and Uninstallation of Unnecessary Components (S)
Once IoT devices have been installed, the protocols, applications, and other tools that have been installed and enabled on them SHOULD be checked. Protocols, services, user IDs, and interfaces that are not required SHOULD be disabled or uninstalled entirely. The use of wireless interfaces that are not needed SHOULD be prevented. If this is not possible using the device itself, services that are not required SHOULD be restricted using the corresponding firewall. The decisions taken SHOULD be documented such that the configurations selected for IoT devices can be determined.
SYS.4.4.A15 Restrictive Granting of Access Rights (S)
Access authorisations for IoT devices SHOULD be granted as restrictively as possible. If this is not possible using IoT devices themselves, it SHOULD be considered via the network.
SYS.4.4.A16 Elimination of Malware on IoT Devices (S)
The IT Operation Department SHOULD regularly obtain information as to whether the IoT devices used could become infected with malware and how it can be removed. Malware SHOULD be eliminated immediately. If the cause of an infection cannot be eliminated or a new infection cannot be effectively prevented, the affected IoT devices SHOULD no longer be used.
SYS.4.4.A17 Monitoring Network Traffic on IoT Devices (S)
Whether IoT devices or sensor systems communicate only with IT systems that are necessary for their operation SHOULD be monitored.
SYS.4.4.A18 Logging Security-Relevant Events on IoT Devices (S)
Security-relevant events SHOULD be logged automatically. If this is not possible using IoT devices themselves, routers and logging mechanisms of other IT systems SHOULD be used. The log data SHOULD be evaluated appropriately.
SYS.4.4.A19 Protection of Administration Interfaces (S)
Depending on whether IoT devices are administered locally; directly using the respective network; or using central, network-based tools, appropriate security precautions SHOULD be taken. Access to the administration interfaces of IoT devices SHOULD be restricted as follows: • Network-based administration interfaces SHOULD be limited to authorised IT systems or network segments. • Preference SHOULD be given to local administration interfaces on IoT devices or administration interfaces via local networks. The methods used for administration SHOULD be defined in the corresponding security policy. IoT devices SHOULD be administered according to this security policy.
SYS.4.4.A2 Authentication (B)
Appropriate authentication MUST be activated. IoT devices MUST be integrated into the corresponding organisation's identity and access management system.
SYS.4.4.A20 Controlled Decommissioning of IoT Devices (S)
There SHOULD be an overview of the data stored in each location on IoT devices. A checklist which can be completed when decommissioning IoT devices SHOULD be created. This checklist SHOULD, at minimum, include aspects of backing up data that is still needed and the subsequent secure deletion of all data.
SYS.4.4.A21 Operational Environment and Power Supply [Building Services] (H)
It SHOULD be clarified whether IoT devices may be operated in the intended operational environment (i.e. taking the protection needs of other IT systems and data protection into account). IoT devices SHOULD be protected against theft, destruction, and manipulation in their operational environment. It SHOULD be clarified whether an IoT device has certain requirements regarding its physical operational environment (e.g. humidity, temperature, energy supply). If required, additional safeguards SHOULD be implemented regarding the infrastructure at hand. If IoT devices are operated using batteries, a procedure SHOULD be specified for regular functional testing and replacement of the batteries. IoT devices SHOULD be protected against dust and pollution in accordance with their intended type and place of use.
SYS.4.4.A22 System Monitoring (H)
IoT devices SHOULD be integrated into an appropriate system monitoring concept. This concept SHOULD continuously monitor the system status and functionality of the IoT devices in use and report error states and threshold violations to the respective operating personnel. Whether the devices used meet the availability requirements at hand SHOULD be checked. Alternatively, it SHOULD be checked whether further safeguards are required, such as setting up a cluster or procuring standby devices.
SYS.4.4.A23 Auditing of IoT Devices (H)
All IoT devices in use SHOULD be checked at regular intervals.
SYS.4.4.A24 Secure Configuration and Usage of an Embedded Web Server (H)
Web servers integrated into IoT devices SHOULD be configured as restrictively as possible. Whenever possible, a web server of this kind SHOULD NOT be operated using a privileged account.
SYS.4.4.A5 Restriction of Network Access (B)
The network access of IoT devices MUST be restricted to the required minimum. This SHOULD be monitored regularly. The following aspects should be taken into consideration in this regard: • For traffic control at network gateways (e.g. by means of rules on firewalls and access control lists (ACLs) on routers), the incoming and outgoing connections permitted MUST be defined in advance. • Routings on IoT devices and sensors SHOULD be configured restrictively, especially with regard to the suppression of default routes. • IoT devices and sensors SHOULD be operated in a separate network segment that is only allowed to communicate with the network segment for management. • Virtual private networks (VPNs) between networks with IoT devices, sensor networks, and management networks SHOULD be configured restrictively. • The UPnP feature MUST be disabled on all routers.
SYS.4.4.A6 Integration of IoT Devices into Organisation Security Policies (S)
Requirements for IoT devices SHOULD be specified in organisations' general security policies. This policy SHOULD be known to all persons who procure and operate IoT devices and be integral to their work. The implementation of the rules required by the policy SHOULD be reviewed regularly and the results documented in a sensible way.
SYS.4.4.A7 Planning the Use of IoT Devices (S)
To ensure secure operation of IoT devices, where and how these devices should be used SHOULD be planned in advance. Besides addressing aspects usually associated with information security in the traditional sense, this planning SHOULD also consider normal operational aspects that entail requirements in the area of security. All decisions taken in the planning phase SHOULD be documented appropriately.
SYS.4.4.A8 Procurement Criteria for IoT Devices [Procurement Department] (S)
The CISO SHOULD also be involved in procuring IoT devices that do not have any obvious IT functionality. Prior to procuring IoT devices, the security requirements they must meet SHOULD be specified. When procuring IoT devices, aspects of material security and requirements regarding the security characteristics of the devices' software SHOULD be sufficiently considered. A requirements list SHOULD be drawn up that can be used to evaluate the products available on the market.
SYS.4.4.A9 Controlling the Use of IoT Devices (S)
A person SHOULD be put in charge of the operation of every IoT device. The persons in charge SHOULD be appropriately informed about handling their IoT devices.
SYS.4.5 Removable Media
Target Object: IT system / Order: R2
SYS.4.5.A1 Raising Staff Awareness of Secure Handling of Removable Media (B)
All employees MUST be made aware of how to handle removable media in a secure manner. Employees MUST be specifically advised on how to handle removable media to prevent loss and theft and ensure longevity. An organisation MUST inform its staff that they are not allowed to connect removable media from unknown sources to their systems.
SYS.4.5.A10 Encryption of Storage Media (B)
If removable media is used or transported outside a secure area and contains confidential data, it MUST be encrypted using a secure method.
SYS.4.5.A11 Protecting Integrity Using Checksums or Digital Signatures (H)
A procedure SHOULD be in place to protect against accidental or intentional alterations and thereby ensure the integrity of confidential information. Procedures designed to prevent such changes SHOULD conform to the current state of the art.
SYS.4.5.A12 Protection Against Malware [User] (B)
Data MUST be checked for malware before being transferred to removable media. Data from removable media MUST also be scanned for malware before being processed.
SYS.4.5.A13 Appropriate Labelling of Storage Media for Shipping [User] (S)
Users SHOULD mark storage media to be sent in such a way that the sender and recipient can immediately identify them. The labelling of the media or their packaging SHOULD be unambiguous for the recipient. The labelling of storage media containing sensitive information SHOULD ensure that third parties cannot draw any conclusions regarding the type or contents of the information.
SYS.4.5.A14 Secure Shipping and Packaging (H)
Organisations SHOULD review how confidential information can be adequately protected during shipping. Users SHOULD utilise secure shipping material for storage media that makes tampering immediately apparent. The sender SHOULD inform all the employees involved of the types of shipping and packaging that are required.
SYS.4.5.A15 Certified Products (H)
Organisations SHOULD only use removable media that are certified. This certification SHOULD take particular account of a given medium's ability to preserve the integrity of data and any encryption that may be in place.
SYS.4.5.A16 Use of Dedicated Systems for Data Scanning (H)
Organisations SHOULD use dedicated systems such as data locks in which data is transferred from one removable storage device to another and scanned for malware.
SYS.4.5.A2 Reporting Losses / Tampering [User] (B)
Users MUST immediately report a removable storage device that has been stolen or become a suspected target of tampering. In such reports, users MUST specify the information stored on device in question. There SHOULD be clear reporting paths and contact persons in every organisation for this purpose.
SYS.4.5.A4 Drawing Up a Policy for the Secure Handling of Removable Media (S)
A policy on the proper handling of removable media SHOULD be established. The following fundamental aspects SHOULD be taken into account: • Which removable media can be used and by whom • Which data may be stored on removable media • How data stored on removable media will be protected against unauthorised access, tampering, and loss • How data on removable media is to be deleted • Whether and how private storage media are allowed to be used • The external employees or service providers with whom storage media may be exchanged and which security regulations are to be observed • How storage media are to be sent • How to prevent the spread of malware via removable media An organisation SHOULD also specify the conditions in which storage media are to be stored in its security policy. In particular, it SHOULD specify that only authorised users have access to the storage media described. It SHOULD also specify that the respective manufacturers' instructions on handling media should be taken into account. Regular checks SHOULD be carried out to ensure that the security specifications for handling removable media are still up to date.
SYS.4.5.A5 Rules on the Transport of Removable Media (S)
There SHOULD be clear written rules on whether, how, and on what occasions removable media may be transported. These SHOULD specify which media may be taken off-site, by whom, and what security safeguards are to be observed.
SYS.4.5.A6 Storage Media Management [Process Owner] (S)
Management procedures SHOULD be in place for removable media. Storage media SHOULD be labelled in a uniform manner. The storage media management concept in place SHOULD ensure that removable media are handled and stored appropriately and used and transported properly.
SYS.4.5.A7 Secure Deletion of Storage Media Before and After Use [Process Owner] (S)
Before rewritable media are passed on, reused, or discarded, they SHOULD be erased in an appropriate manner.