chrisbst48/IT-Grundschutz-Compendium_2022_EN huggingface dataset:
SYS.2.3.A9 Secure Use of Passwords in the Command Line [User] (S)
Passwords SHOULD NOT be transferred to programs as parameters.
SYS.2.4 macOS Clients
Target Object: IT system / Order: R2
SYS.2.4.A1 Planning the Secure Use of macOS (B)
The introduction of macOS MUST be planned carefully. A decision MUST be taken as to where and how data will be stored. Organisations MUST make plans regarding how backups can be integrated into their overarching backup concepts. The systematic installation of updates related to security and other aspects of macOS and applications MUST be planned. When switching to macOS, the applications required MUST be determined. If a Mac is operated on a data network, the network protocols to be used MUST also be taken into account.
SYS.2.4.A10 Activating the Personal Firewall in macOS (S)
The personal firewall integrated into macOS SHOULD be appropriately activated and configured.
SYS.2.4.A11 Disposing of Macs (S)
When disposing of a Mac, the NVRAM (Non-Volatile Random Access Memory) and SMC (System Management Controller) should be reset.
SYS.2.4.A12 Firmware Password and Boot Protection on Macs [User] (H)
On older Macs, the request for a secure firmware password SHOULD be activated in command mode to prevent unauthorised booting from another boot drive. It SHOULD be checked whether a password should be requested for every startup process via full mode. On Macs with a T2 security chip, a firmware password SHOULD be set via the Startup Security Utility. The option Secure startup: Full security SHOULD be activated. The option Do not allow startup from external media SHOULD be activated.
SYS.2.4.A2 Using the Security Functions Integrated into macOS (B)
The integrated macOS protection mechanisms System Integrity Protection (SIP), Xprotect, and Gatekeeper MUST be activated. Unless unsigned programs are absolutely necessary, Gatekeeper MUST ONLY allow signed programs to run.
SYS.2.4.A3 Use of Suitable User Accounts [User] (B)
The administrator account created during the initial configuration of macOS MUST ONLY be used for administrative purposes. A standard user account MUST be created for normal Mac use. If a Mac is used by several users, a separate user account MUST be created for every user. The guest user account MUST be disabled.
SYS.2.4.A4 Use of Hard Drive Encryption (S)
Hard drives SHOULD be encrypted, particularly for portable Macs (e.g. MacBooks). If the FileVault function integrated into macOS is used for this, the key material MUST NOT be stored online at Apple. The recovery keys produced by FileVault MUST be stored in a secure place. Whether an organisational recovery key should be used for FileVault SHOULD be checked.
SYS.2.4.A5 Disabling Security-Critical Functions in macOS (S)
The location services integrated into macOS SHOULD be disabled. Downloaded data SHOULD NOT be opened automatically. Content from optical and other media SHOULD NOT run automatically.
SYS.2.4.A6 Using Up-To-Date Mac Hardware (S)
If new Macs are to be purchased, current models SHOULD be selected. Macs already in use SHOULD be regularly checked to determine whether the installed operating systems still receive security updates from Apple. If Macs are no longer supported by Apple, they SHOULD NOT be used.
SYS.2.4.A7 Two-Factor Authentication for Apple IDs [User] (S)
Two-factor authentication SHOULD be activated for Apple ID accounts.
SYS.2.4.A8 No iCloud Use for Confidential Data [User] (S)
The synchronisation of confidential data among multiple devices via iCloud services SHOULD be prevented. Data SHOULD only be synchronised using self-operated services. Sensitive data SHOULD NOT be stored in iCloud. Draft copies (e.g. of e-mails or documents) SHOULD NOT be stored automatically in iCloud.
SYS.2.4.A9 Using Additional Protection Programs in macOS (S)
If required (such as when operating a Mac in a heterogeneous network), virus protection solutions from third parties SHOULD be used in addition to the integrated protection mechanisms of macOS.
SYS.3.1 Laptops
Target Object: IT system / Order: R2
SYS.3.1.A1 Rules for Mobile Laptop Use (B)
The aspects employees must consider when making mobile use of laptops MUST be clearly defined. In particular, the laptops available for mobile use, who is allowed to use them, and what basic security safeguards should be followed MUST be specified. The users MUST be informed of these rules.
SYS.3.1.A10 Synchronisation of Stored Data on Laptops [User] (S)
The way in which data is transferred from laptops to the corresponding organisation’s information domain SHOULD be regulated. If a synchronisation tool is used, care SHOULD be taken to ensure that synchronisation conflicts can be resolved. The synchronisation process SHOULD be logged. Users SHOULD also be instructed to check the synchronisation logs.
SYS.3.1.A11 Securing the Power Supply for Laptops [User] (S)
All users SHOULD receive information as to how they can best guarantee their laptop's power supply during mobile use. Spare batteries SHOULD be stored and transported in suitable cases.
SYS.3.1.A12 Reporting the Loss of Laptops [User] (S)
If a laptop is lost or stolen, the user SHOULD report this immediately. Organisations SHOULD have clear reporting channels for this purpose. If a lost laptop resurfaces, there SHOULD be an investigation into whether it could have been manipulated. The software used on it, including the operating system, SHOULD be completely reinstalled.
SYS.3.1.A13 Encryption of Laptops (S)
Storage media installed in laptops, such as hard disks or SSDs, SHOULD be encrypted.
SYS.3.1.A14 Suitable Storage of Laptops [User] (S)
All users SHOULD be advised on how to store laptops securely outside their organisation. Depending on the level of protection required for the data stored on them, laptops SHOULD also be secured against theft or kept in a locked location when not in use on the respective organisation's premises.
SYS.3.1.A15 Appropriate Selection of Laptops [Procurement Department] (S)
Before laptops are purchased, the persons in charge SHOULD carry out a requirements analysis. All possible devices SHOULD be assessed on the basis of the results. The decision on which laptops to procure SHOULD be agreed with the IT Operation Department.
SYS.3.1.A16 Central Administration and Administration of Laptops (H)
A suitable regulation for the central administration of laptops SHOULD be defined. A tool for central laptop management SHOULD support all the operating systems used to the greatest extent possible.
SYS.3.1.A17 Pooled Storage of Laptops (H)
Unused laptops SHOULD be stored in an appropriately secured room. The room used for this SHOULD meet the requirements of INF.5 Room or Cabinet for Technical Infrastructure.
SYS.3.1.A18 Use of Anti-Theft Devices (H)
The anti-theft devices to be used for laptops SHOULD be regulated. In the context of mechanical devices, care SHOULD be taken to ensure that they have a good lock.
SYS.3.1.A3 Use of Personal Firewalls (B)
A personal firewall MUST be activated on all laptops if they are to be used outside of an organisation's network. The filter rules for personal firewalls MUST be configured as restrictively as possible. They MUST be tested regularly. Personal firewalls MUST be configured to avoid pestering users with warnings they are not able to interpret.
SYS.3.1.A66 Security Guidelines for Laptops (S)
Security policies that govern how laptops may be used SHOULD be established. Users SHOULD be made aware of the protection needs for laptops and the data stored on them. They SHOULD also be made aware of the specific threats at hand and the corresponding requirements for use. Furthermore, they SHOULD be informed of the types of information they may process on laptops.
SYS.3.1.A7 Orderly Issue and Return of Laptops [User] (S)
If different people take turns using the same laptops, secure methods of issuing laptops to employees SHOULD be defined. Their safe return SHOULD also be regulated. When a laptop changes users, any sensitive data SHOULD be securely deleted. If a laptop is not reset upon changing users, care SHOULD be taken to ensure that there is no malware on the corresponding IT system or any storage media connected to it. When they are issued a laptop, employees SHOULD also receive an information sheet on secure handling of the device.
SYS.3.1.A8 Secure Connection of Laptops to Data Networks [User] (S)
Secure methods SHOULD be defined for connecting laptops to internal or external data networks and the Internet. Only authorised laptops SHOULD be able to log on to the respective organisation's internal network.
SYS.3.1.A9 Secure Remote Access with Laptops (B)
When using publicly available networks, users MUST ONLY access their organisation's internal network through secure communication channels.
SYS.3.2.1 General Smartphones and Tablets
Target Object: IT system / Order: R2
SYS.3.2.1.A1 Definition of a Policy for Using Smartphones and Tablets (B)
Before smartphones or tablets are provided, operated, or used by an organisation, a general policy for the use and control of such devices MUST be defined. In so doing, it MUST, amongst other things, be specified who may access which information within the organisation using smartphones.
SYS.3.2.1.A11 Storage Encryption (S)
The non-volatile storage of mobile devices SHOULD be encrypted. Sensitive data on additional storage media in use (such as SD cards) SHOULD be encrypted.
SYS.3.2.1.A12 Use of Non-Personalised Device Names (S)
Device names SHOULD not include any information regarding the respective users or organisation.
SYS.3.2.1.A13 Rules Regarding Screen Sharing and Casting (S)
A decision SHOULD be taken on whether and how functions should be used to transmit screen content and audio or video content (screen sharing or casting). These functions SHOULD be regulated in organisational or technical terms. To this end, a corresponding agreement SHOULD be established with users.
SYS.3.2.1.A16 Disabling Unused Communication Interfaces [User] (S)
Communication interfaces SHOULD only be activated when needed and in suitable environments. If an MDM system is used, the interfaces SHOULD be managed centrally via this system.
SYS.3.2.1.A18 Use of Biometric Authentication (S)
If a biometric procedure is used for authentication (e.g. based on a fingerprint sensor), it SHOULD be checked whether similarly high or higher protection can be achieved compared to using a device password. If this is unclear or if the level of protection is actually lower, the biometric procedure SHOULD NOT be used. Users SHOULD be made aware that biometric features can be falsified.
SYS.3.2.1.A19 Use of a Voice Assistant (S)
Voice assistants SHOULD only be used when they are necessary. Otherwise, they SHOULD be disabled. In general, it SHOULD not be possible to use a voice assistant when a device is locked.
SYS.3.2.1.A2 Drawing Up a Strategy for Cloud Usage (B)
An organisation MUST define a general policy for cloud use and the protection and control of information in relation to smartphones and tablets. The permitted use of cloud services in connection with the organisation's information MUST be clarified and defined. Whether and to what extent cloud services are allowed for private use of devices MUST be determined. Users MUST be regularly made aware of the issues regarding the use of such cloud services.
SYS.3.2.1.A22 Integrating Mobile Devices into Internal Infrastructure via VPN (S)
Mobile end devices SHOULD only be integrated into an organisation's infrastructure through a VPN. An appropriate method SHOULD be selected and used for this purpose. Instead of passwords, devices SHOULD authenticate themselves to internal infrastructure via certificates.
SYS.3.2.1.A25 Use of Separate Work Environments (H)
If employees are permitted to use work-related devices privately as well, solutions for isolated working environments SHOULD be used on these end devices. If possible, only certified products (e.g. those in accordance with Common Criteria) SHOULD be purchased for this purpose. Work-related data SHOULD remain exclusively in the environment of the organisation in question.
SYS.3.2.1.A26 Use of PIM Containers (H)
Information on mobile devices SHOULD be encapsulated (e.g. in a PIM container). In addition, this data SHOULD be secured by separate authentication and a form of data and transport encryption that is independent from the operating system in use.
SYS.3.2.1.A27 Use of Specially Secured End Devices (H)
Depending on the protection needs at hand, organisations SHOULD use specially secured mobile devices that are certified for processing information in line with statutory information protection classifications.
SYS.3.2.1.A28 Using the Filter Option for Websites (S)
If an organisation already uses a reputation service or a corresponding proxy server, this SHOULD be stored as a global HTTP proxy for all the installed browsers in use. If such a proxy is only accessible within the internal network in question, end devices SHOULD be integrated (either permanently or based on the apps used) using a VPN connection. If mobile devices are not integrated into an organisation's existing proxy or reputation infrastructure, filtering options based on whitelists or blacklists or third-party content filters SHOULD be used for web browsers.
SYS.3.2.1.A29 Use of an Organisation-Related APN (H)
It SHOULD be checked whether an organisation-related access point to mobile networks (an access point name, APN) can be used to limit the pool of permitted devices. The mobile service provider in question SHOULD assign an IP address range coordinated with the respective organisation to all the devices that use this APN. For authentication, a complex password with a maximum of 64 characters SHOULD be agreed with the mobile service provider. When using an organisation-related APN, authentication SHOULD take place on the basis of the CHAP protocol.
SYS.3.2.1.A3 Secure Basic Configuration for Mobile Devices (B)
All mobile devices MUST be configured to meet the required level of protection. To this end, an appropriate basic configuration of security mechanisms and settings MUST be established and documented. Functions that are not required SHOULD be disabled. The activation of communication interfaces MUST be regulated and reduced to the minimum required for work-related purposes. Unused interfaces SHOULD be disabled.
SYS.3.2.1.A30 Restricted App Installation Using a Whitelist (H)
In case of increased protection needs, the users of mobile end devices SHOULD only be able to install approved and tested apps. If an MDM system is used, it SHOULD prevent other apps from being installed; alternatively, it SHOULD immediately remove apps that are installed without authorisation.
SYS.3.2.1.A31 Regulation of Mobile Payments (S)
Whether mobile payments are allowed with work-related smartphones and tablets SHOULD be regulated.
SYS.3.2.1.A32 MDM Usage (S)
Smartphones and tablets SHOULD be managed by an MDM system.
SYS.3.2.1.A33 Selection and Installation of Security Apps (S)
All mobile end devices SHOULD be protected against malware. Appropriate security apps SHOULD be selected for end devices if possible. The security apps SHOULD be installed automatically—for example, via an MDM system.
SYS.3.2.1.A34 Configuration of the DNS Server Used (S)
Default gateway entries, such as the DNS servers of the manufacturer or developer in question, SHOULD be replaced by those of the provider or the organisation at hand. If the provider offers DNS-over-HTTPS (DoH), this SHOULD be used. If this is not yet offered, it SHOULD be disabled.
SYS.3.2.1.A35 Using a Firewall (H)
A firewall SHOULD be installed and activated on smartphones and tablets.
SYS.3.2.1.A4 Use of an Access Control Mechanism [User] (B)
Smartphones and tablets MUST be protected with an appropriately complex device lock code. Screen locking MUST be used. The display of confidential information on lock screens MUST be disabled. All mobile devices MUST automatically activate their screen lock after a reasonably short period of time. This time period MUST be related to the required level of protection. After each failed attempt to unlock a device, the user SHOULD be required to wait longer before trying again. The number of device lock codes after which a code may be repeated SHOULD be specified. After several failed attempts to unlock a mobile device's screen, the device SHOULD perform a factory reset. The data or encryption keys at hand SHOULD be deleted securely in this process. When changing their passwords, users SHOULD avoid choosing a new password that they have used recently.
SYS.3.2.1.A5 Operating System and App Updates (B)
When selecting mobile devices to be procured, an organisation MUST ensure that the manufacturer specifies the period of time for which it plans to provide security updates for the devices. Older devices that are no longer provided with updates MUST be disposed of and replaced with devices supported by the respective manufacturer. In addition, apps SHOULD NOT be used if they are no longer supported by the manufacturer.
SYS.3.2.1.A6 Privacy Settings and Authorisations (B)
App and operating system access to data and interfaces MUST be restricted appropriately. The related data protection settings MUST be configured as restrictively as possible. In particular, access to camera, microphone, location, and health/fitness data MUST be checked for compliance with an organisation's internal data protection and security requirements. This access MUST be configured restrictively or disabled. Security-relevant authorisation settings MUST be set so that they cannot be changed by users or apps. If this is not technically possible, the authorisation settings MUST be regularly checked and reset. In particular, this MUST be done after updates are installed.
SYS.3.2.1.A7 Code of Conduct in the Event of Security Incidents [User] (B)
If devices are lost or unauthorised changes to devices and their software are detected, the respective users MUST immediately inform the persons in charge.
SYS.3.2.1.A8 Installation of Apps (B)
An organisation MUST regulate whether, how, and which apps users are allowed to install themselves on their devices. Users SHOULD only be allowed to install approved apps. An organisation MUST define the sources from which apps may be installed. The installation of apps from unapproved sources MUST be prevented.
SYS.3.2.1.A9 Restrictive Use of Functional Extensions (S)
Functional extensions SHOULD only be used restrictively. If possible, functional extensions SHOULD not be used at all. Functional extensions SHOULD NOT have any automatic access to sensitive information. They SHOULD NOT be able to circumvent or change the specified basic configurations.
SYS.3.2.2 Mobile Device Management (MDM)
Target Object: IT system / Order: R2
SYS.3.2.2.A1 Determining a Strategy for Mobile Device Management (B)
An organisation MUST develop a strategy which determines how its employees may use mobile devices and how the devices are to be integrated into its IT structures. The protection needs of the information to be processed MUST be a fundamental consideration in this regard. The strategy MUST cover at least the following aspects: • Can the MDM system be operated as a cloud service? • Should the MDM system be operated by the organisation itself? • Should the MDM system provide all the necessary apps, or can users install apps themselves? What restrictions does the organisation want to impose on the apps it provides or those that are installed by users? • Should the MDM system be integrated into a broader infrastructure? • What support and response requirements does the MDM provider need to fulfil? • What compliance requirements must be implemented? • Which mobile devices and which operating systems does the MDM system need to support? • Does the MDM solution need to be multi-client-capable? Does it guarantee the necessary separation of clients? • Do cloud services need to be incorporated? • Do document management systems need to be incorporated? • Does the MDM system need to incorporate and manage peripheral devices, as well? • What will the operating model involve: private end devices (bring your own device, BYOD), personalised end devices (owned by the organisation), or non-personalised end devices (owned by the organisation and used jointly)? The strategy MUST be specified in writing and approved by the CISO.
SYS.3.2.2.A12 Protection of the MDM Operating Environment (S)
The MDM system in use SHOULD itself be secured using technical safeguards in order to satisfy the protection needs of the information it stores or processes. The underlying operating system SHOULD be hardened.
SYS.3.2.2.A14 Use of External Reputation Services for Apps (H)
If the administrators of an organisation cannot select the admissible apps and users are able to install apps on their devices themselves, a reputation service SHOULD be used. The MDM system in use SHOULD then use information from the reputation service to at least limit the installation of apps.
SYS.3.2.2.A17 Monitoring the Use of Mobile Devices (H)
Appropriate criteria SHOULD be defined and used as a basis for monitoring devices without violating legal or internal provisions. In particular, jailbreaks and attempts at rooting SHOULD be recognised.
SYS.3.2.2.A19 Using Geofencing (H)
A geofencing policy SHOULD ensure that devices with sensitive information cannot be used outside a pre-defined geographical area. If a user leaves this geographical area, the information designated for deletion on their device (or the device itself) SHOULD be wiped completely. Before the device is selectively or completely deleted, the administrators in charge, the security management personnel in question, and the user SHOULD be informed. The device SHOULD only be selectively or completely deleted after an appropriate time delay. The areas in which these additional security safeguards are necessary SHOULD be identified. The security safeguards SHOULD then be implemented in compliance with the relevant legal and internal provisions.
SYS.3.2.2.A2 Defining Admissible Mobile Devices (B)
The mobile devices and operating systems that are permitted in an organisation MUST be specified. All authorised devices and operating systems MUST satisfy the requirements of the MDM strategy at hand and fully comply with the organisation’s security requirements. The organisation's MDM system MUST be configured such that only approved devices can access the organisation’s information. The procurement of mobile devices MUST be restricted to those approved by the organisation.
SYS.3.2.2.A20 Regular Review of the MDM System (B)
Security settings MUST be checked regularly. For new operating system versions of mobile devices, it MUST be checked in advance whether the MDM system in use fully supports them and whether the configuration profiles and security settings are still effective and sufficient. Deviations MUST be corrected. The access rights assigned to users and administrators MUST be checked regularly to ensure that they are still appropriate (minimum principle).
SYS.3.2.2.A21 Administration of Certificates (S)
Certificates for the use of services on mobile devices SHOULD be installed, uninstalled, and updated centrally via the MDM system in use. The installation of untrusted and unverifiable (root) certificates by users SHOULD be prevented by the MDM system. The MDM system SHOULD support mechanisms that verify the validity of certificates.
SYS.3.2.2.A22 Remote Deletion and Decommissioning of End Devices (S)
The MDM system in use SHOULD ensure that all business data on mobile devices can be deleted remotely (remote wipes for existing data connections). If external storage devices are being used in a mobile device, the system SHOULD check whether these should also be deleted in a remote wipe. This function SHOULD be supported by the MDM system. The process for decommissioning mobile devices (unenrollment) SHOULD ensure that no sensitive data remains on devices or their integrated storage media. This SHOULD particularly apply if the unenrollment is to be carried out remotely.