chrisbst48/IT-Grundschutz-Compendium_2022_EN huggingface dataset:
APP.4.6.A17 No Client-Dependent Execution of Functions (S)
ABAP programs SHOULD NOT be programmed in a client-dependent manner—that is, so that they can only be executed by a particular client. Should this be absolutely necessary, however, it SHOULD be documented in detail. In addition, further security safeguards SHOULD then be taken, such as a manual code review or a quality assurance check of the corresponding client.
APP.4.6.A18 Avoiding Open SQL Injection Vulnerabilities (S)
Dynamic Open SQL SHOULD NOT be used. If database access with dynamic SQL conditions is necessary, user input SHOULD NOT be transferred in the respective query. If this is nevertheless the case, the user input MUST be checked (output encoding).
APP.4.6.A19 Protection Against Cross-Site Scripting (S)
Custom-developed HTML in Business Server Page (BSP) applications or HTTP handlers SHOULD be avoided whenever possible.
APP.4.6.A2 Formally Correct Evaluation of Authorisation Checks (B)
Each authorisation check in code MUST be evaluated by querying the return value SY-SUBRC.
APP.4.6.A20 No Access to Data from Another Client (S)
Automatic client separation SHOULD NOT be bypassed. Data from other clients SHOULD NOT be accessed using EXEC SQL or the Open SQL option CLIENT SPECIFIED.
APP.4.6.A21 Ban on Hidden ABAP Source Code (S)
The source code of an ABAP program created in-house SHOULD always be readable. Techniques that prevent this (obfuscation) SHOULD NOT be used.
APP.4.6.A22 Use of ABAP Code Analysis Tools (H)
An ABAP code analysis tool SHOULD be used to automatically check ABAP code for security relevant programming errors, functional and technical errors, and quality vulnerabilities.
APP.4.6.A3 Authorisation Check Before Starting a Transaction (B)
If developers use the CALL TRANSACTION command, a start authorisation check MUST always be performed before the command is executed.
APP.4.6.A4 No Proprietary Authorisation Checks (B)
Each authorisation check MUST be carried out using the AUTHORITY CHECK command provided for this purpose. Proprietary authorisation checks (e.g. based on user names) MUST NOT be used.
APP.4.6.A5 Drawing Up a Policy for ABAP Development (S)
A policy SHOULD be drawn up for the development of ABAP programs. In addition to naming conventions, the policy SHOULD contain specifications for ABAP elements that may or may not be used. The requirements from this module SHOULD be included in the policy. The policy SHOULD be binding for developers.
APP.4.6.A6 Complete Execution of Authorisation Checks (S)
During an authorisation check in ABAP code (AUTHORITY-CHECK ), it SHOULD be ensured that all fields are checked for the relevant authorisation object. If individual fields are not actually required, they SHOULD be marked as DUMMY. The reason for the exception SHOULD also be documented in the field.
APP.4.6.A7 Authorisation Check During Input Processing (S)
The function codes and screen elements of ABAP Dynpro applications SHOULD be consistent. If a screen element has been disabled, an application SHOULD NOT react to the events of this element without adequate authorisation checks. If certain entries in a Dynpro menu are hidden or individual buttons are disabled, the corresponding function codes SHOULD also not be executed.
APP.4.6.A8 Protection Against Unauthorised or Manipulative Access to the File System (S)
If access to files on an SAP server depends on user input, this input SHOULD be validated before access is granted.
APP.4.6.A9 Authorisation Check in Remote-Enabled Function Modules (S)
It SHOULD be ensured that all remote-enabled function modules in program code explicitly check whether the initiator is authorised to execute the corresponding business logic.
APP.5.2 Microsoft Exchange and Outlook
Target Object: Application / Order: R2
APP.5.2.A1 Planning the Use of Exchange and Outlook (B)
Before implementing Exchange and Outlook, an organisation MUST plan their use carefully. It MUST consider at least the following points: • Design of the e-mail infrastructure • Clients and/or server systems to be connected • Use of functional extensions • The protocols to be used
APP.5.2.A10 Secure Configuration of Outlook (S)
The IT Operation Department SHOULD create a separate Outlook profile with user-specific settings for each user. The IT Operation Department SHOULD configure Outlook so that only necessary information is transmitted to other users. The IT Operation Department SHOULD inform users regarding information that is automatically transmitted to other users. Read receipts and information that offers insights into the internal structure of the organisation at hand SHOULD NOT be transmitted to external users.
APP.5.2.A11 Protection of Communications Between Exchange Systems (S)
The IT Operation Department SHOULD decide on the protection mechanisms that are to be used to secure communications between Exchange systems in a comprehensible way. In particular, the IT Operation Department SHOULD determine how communication to the following interfaces is secured: • Administration interfaces • Client-server communications • Existing interfaces for web-based distributed authoring and versioning (WebDAV) • Server-to-server communication • Public key infrastructure on which Outlook's e-mail encryption is based
APP.5.2.A12 Using Outlook Anywhere, MAPI over HTTP, and Outlook on the Web (S)
The IT Operation Department SHOULD configure Outlook Anywhere, MAPI over HTTP, and Outlook on the Web in line with its organisation’s security requirements. Access to Exchange through the Internet SHOULD be restricted to the necessary users.
APP.5.2.A17 Encryption of Exchange Database Files (H)
The IT Operation Department SHOULD create a concept for encrypting PST and Information Store files. The organisation in question SHOULD inform users about the protection mechanisms used to encrypt PST files and how these mechanisms work. Additional aspects of local PST files that SHOULD be taken into consideration when encrypting Exchange system databases include: • Proprietary encryption functions • Degrees of encryption • Mechanisms for securing the data in a PST file Mechanisms such as the Encrypting File System or Windows BitLocker drive encryption SHOULD be used to secure PST files.
APP.5.2.A2 Selecting an Exchange Infrastructure (B)
Based on the planning of the deployment of Exchange, the IT Operation Department MUST decide on the systems, application components, and hierarchical gradation with which the Exchange infrastructure will be realised. When selecting an infrastructure, it MUST also be decided whether the systems are to be operated in the cloud or as a local service.
APP.5.2.A3 Access Management and Access Rights (B)
In addition to its general access control policy, an organisation MUST create, adequately document, and apply an access control policy for the systems in its Exchange infrastructure. The IT Operation Department MUST use server-side user profiles for computer-independent user access to Exchange data. It MUST adapt the default NTFS authorisations for the Exchange directory so that only authorised administrators and system accounts are allowed to access the data in this directory.
APP.5.2.A5 Backing Up Exchange (B)
Exchange servers MUST be backed up prior to any installations and configuration changes, as well as at cyclical intervals. In particular, the Exchange server databases MUST be backed up. Deleted Exchange objects SHOULD only be removed from the database after some time.
APP.5.2.A7 Migration of Exchange Systems (S)
The IT Operation Department SHOULD thoroughly plan and document all migration steps. The IT Operation Department SHOULD consider mailboxes, objects, security policies, Active Directory concepts, and connections to other e-mail systems. It SHOULD also take into account the functional differences between different versions of Exchange. The new system SHOULD be tested in a separate testing network prior to being installed.
APP.5.2.A9 Secure Configuration of Exchange Servers (S)
The IT Operation Department SHOULD install and configure Exchange servers as specified in the respective organisation's security policy. Connectors SHOULD be configured securely. The IT Operation Department SHOULD enable logging of the Exchange system. A corresponding concept SHOULD be created for existing user-specific customisations. When using functional extensions, it SHOULD be ensured that the requirements defined to maintain confidentiality, integrity, and availability are still being met.
APP.5.3 General E-Mail Clients and Servers
Target Object: Application / Order: R2
APP.5.3.A1 Secure Configuration of E-Mail Clients (B)
An organisation MUST specify a secure configuration for its e-mail clients. The e-mail clients MUST be pre-configured when provided to users. The organisation MUST ensure that the security-relevant aspects of the configuration cannot be changed by users. If this is not possible, the organisation MUST inform the users that they are not permitted to change the configuration on their own. Before file attachments from e-mails are opened, they MUST be checked for malware by a protection program on the client, if this is not already done on the e-mail server. E-mail clients MUST be configured in such a way that they do not automatically interpret any HTML code or other active content in e-mails. Preview functions for file attachments MUST be configured so that they do not automatically interpret files. E-mail filtering rules and uncontrolled automatic forwarding of e-mails MUST be limited to necessary application scenarios. E-mail clients MUST use secure transport encryption for communications with e-mail servers across untrusted networks.
APP.5.3.A10 End-to-End Encryption (H)
An organisation SHOULD use end-to-end encryption and signatures for e-mails. Only protocols that comply with the current state of the art SHOULD be used for encryption and signatures.
APP.5.3.A11 Deployment of Redundant E-Mail Servers (H)
An organisation SHOULD operate several redundant e-mail servers. The redundant e-mail servers SHOULD be stored with appropriate priority in the DNS information of the domains concerned. The organisation SHOULD determine how e-mails are to be synchronised among its e-mail servers.
APP.5.3.A12 Monitoring Public Blacklists (H)
The IT Operation Department SHOULD regularly check if its organisation's e-mail servers are listed on public spam or blacklists.
APP.5.3.A13 TLS Reporting (H)
An organisation SHOULD use TLS reporting. It SHOULD be determined whether TLS reports are to be sent to other organisations.
APP.5.3.A2 Secure Operation of E-Mail Servers (B)
The IT Operation Department MUST implement protection mechanisms against denial-of service (DoS) attacks. E-mail servers MUST offer secure transport encryption for receiving e mails and accessing e-mail clients via public data networks. If e-mail servers send e-mails on their own, they SHOULD also use secure transport encryption for this purpose. An organisation MUST specify all the e-mail protocols and services it permits. In addition, the IT Operation Department MUST configure e-mail servers so that they cannot be misused as spam relays. If messages are stored on an e-mail server, the IT Operation Department MUST configure and document an appropriate size limit for the server-side mailbox.
APP.5.3.A3 Data Backup and Archiving of E-Mails (B)
The IT Operation Department MUST back up its e-mail servers regularly. To this end, the corresponding organisation MUST regulate how the sent and received e-mails of e-mail clients and the e-mails on the servers are backed up. With regard to archiving, the organisation SHOULD also consider that e-mails may only be stored locally on clients.
APP.5.3.A4 Spam and Virus Protection on E-Mail Servers (B)
The IT Operation Department MUST ensure that incoming and outgoing e-mails on e-mail servers, and particularly their attachments, are checked for spam characteristics and harmful content. The introduction and use of e-mail filtering programs MUST be coordinated with the Data Protection Officer, Employee Representatives, and Users. The organisation MUST specify how encrypted e-mails are to be dealt with if they cannot be decrypted by the virus protection program in use.
APP.5.3.A5 Establishing Deputising Rules for E-Mail Use [Supervisor] (S)
An organisation should establish deputising rules for the handling of e-mails. If e-mails are forwarded, the deputising users SHOULD at least be informed. Data protection aspects MUST be taken into account when forwarding e-mails. An organisation SHOULD establish regulations for autoreply functions in e-mail programs that describe how these functions can be used securely. When employees use the autoreplyfunctions, no internal information SHOULD be disclosed.
APP.5.3.A6 Defining a Security Policy for E-Mail (S)
An organisation SHOULD establish and regularly update a security policy for the use of e-mail. The organisation SHOULD inform all users and administrators of new or changed security requirements for e-mail applications. The organisation's e-mail security policy SHOULD comply with its generally applicable security policies. The organisation SHOULD check that the security policy is being applied correctly. The e-mail security policy for users SHOULD specify the following: • How these communications can be secured • What user access rights exist • How e-mails are checked for forged senders • How to secure transmitted information • How to check the integrity of e-mails • Which open e-mail distribution lists may be used • Whether private e-mail use is permitted • How to deal with e-mails and mailboxes of employees who leave the company • Whether and how webmail services may be used • Who is responsible for group mailboxes • How file attachments should be handled • How e-mails in HTML format should be handled by users The e-mail security policy SHOULD also include the configuration options of the e-mail applications for administrators, as well as the specifications for possible access to an e-mail server from other servers. Information on authorised points from which an e-mail server may be accessed SHOULD also be included in the policy. The e-mail security policy SHOULD regulate the handling of newsgroups and mailing lists.
APP.5.3.A7 User Training on the Security Mechanisms of E-Mail Clients (S)
An organisation SHOULD educate users on the risks of using e-mail applications and how to use e-mail safely. This SHOULD take place in addition to general training and awareness raising. The organisation SHOULD make users aware of the possible dangers of opening e-mail attachments. Training SHOULD also address how users can recognise e-mails from fake senders. The organisation SHOULD warn users not to participate in e-mail chain letters or subscribe to a large number of mailing lists.
APP.5.3.A8 Training Users to Deal with Spam [User] (S)
As a matter of principle, all users SHOULD ignore and delete all spam e-mails. Users SHOULD NOT answer unsolicited e-mails. They SHOULD NOT click links in these e-mails. If an organisation has a central spam management solution, users SHOULD forward spam e-mails to it and then delete them.
APP.5.3.A9 Extended Security Safeguards on E-Mail Servers (S)
An organisation's e-mail servers SHOULD check incoming e-mails using the Sender Policy Framework (SPF) and DomainKeys. The organisation SHOULD also use DomainKeys and SPF to authenticate the e-mails it sends. If SPF is used, it SHOULD be clearly specified how e-mails are to be handled. The softfail parameter (~) SHOULD only be used for testing purposes. The organisation SHOULD use Domain-based Message Authentication, Reporting and Conformance (DMARC) to specify how e-mails it sends should be verified by the receiving e-mail server. DMARC reports SHOULD be evaluated regularly. The organisation SHOULD determine whether DMARC reports on received e-mails are sent to other organisations. The organisation SHOULD secure its e-mail communications via DANE and MTA-STS.
APP.6 General Software
Target Object: Application / Order: R2
APP.6.A1 Planning Software Use [Process Owner] (B)
Before an organisation introduces (new) software, it MUST take the following decisions: • What the software will be used for and what information it will process • How users should be involved in the requirements analysis and supported in the implementation process • How the software will be connected to other applications and IT systems, and via which interfaces • The IT systems on which the software should be run and what resources are required • Whether the organisation will become dependent on a manufacturer if it uses the software in question Security aspects MUST be considered in this regard. In addition, the organisation MUST clarify and define the responsibilities for technical supervision, approval, and operational administration in advance. The responsibilities MUST be documented and updated as needed.
APP.6.A10 Establishing a Security Policy for Software Use (S)
An organisation SHOULD summarise the regulations that determine how software is to be used and operated in a security policy. The policy SHOULD be known to all the relevant people in charge and employees of the organisation and SHOULD represent the basis for their actions and work. In terms of content, the policy should also include a user handbook that explains how software should be used and managed. Random and regular checks SHOULD carried out on whether employees are complying with the policy. The policy SHOULD be updated at regular intervals.
APP.6.A11 Using Plug-ins and Extensions (S)
Plug-ins and extensions SHOULD be restricted to those that are absolutely necessary. If extensions are used, the corresponding software SHOULD offer the option to configure and disable them.
APP.6.A12 Orderly Decommissioning of Software [Process Owner] (S)
If software is to be decommissioned, the IT Operation Department SHOULD regulate this procedure with the Process Owners. The process for informing users in this regard this SHOULD also be regulated. This SHOULD clarify whether the functional requirements in question continue to exist (e.g. for business processes). If this is the case, the manner in which the required functions of the software to be decommissioned will continue to be available SHOULD be regulated.
APP.6.A13 Uninstallation of Software (S)
If software is uninstalled, all files created and no longer needed SHOULD be removed. All entries in system files that were made for the product and are no longer needed SHOULD be reversed.
APP.6.A14 Using Certified Software (H)
When purchasing software, it SHOULD be determined whether the assurances of the manufacturer, distributor, and provider regarding the security functions implemented can be considered to be sufficiently trustworthy. If this is not the case, certification of the application (e.g. according to Common Criteria) SHOULD be factored into the selection process. If several products are available, security certificates SHOULD be considered, particularly if the evaluated scope of functions includes the minimum functions (or most of them) and the strength of the corresponding mechanisms matches the protection needs at hand.
APP.6.A2 Drawing Up a Requirements Catalogue for Software [Process Owner] (B)
Based on the results of corresponding planning, the software requirements at hand MUST be collated in a requirements catalogue. The requirements catalogue MUST include the basic functional requirements. In addition, the non-functional requirements, and particularly the security requirements, MUST be integrated into the requirements catalogue. In this regard, the requirements of both the Process Owners and the IT Operation Department MUST be taken into account. In particular, the legal requirements arising from the context of the data to be processed MUST also be considered. The requirements catalogue SHOULD be finalised in consultation with all the departments involved.
APP.6.A3 Secure Procurement of Software [Procurement Department] (B)
During the procurement process, suitable software MUST be selected based on the requirements catalogue. The selected software MUST be procured from a trusted source. The trusted source SHOULD provide a means of verifying the integrity of the software. Furthermore, the software SHOULD be procured with a suitable maintenance contract or a comparable commitment from the manufacturer or software provider. In particular, these contracts or commitments SHOULD guarantee that any vulnerabilities and weaknesses that emerge in the software will be promptly remedied throughout the period of use.
APP.6.A4 Regulation of Software Installation and Configuration [Process Owner] (B)
The installation and configuration of software MUST be regulated by the IT Operation Department in order to achieve the following: • The software is installed and executed with the smallest functional scope necessary • The software is executed with the fewest authorisations possible • Settings pertaining to the processing of personal data are configured to store as little data as possible • All relevant security updates and patches are installed before the software is used productively Dependent components (including runtime environments, libraries, interfaces, and other programs) MUST also be considered. In coordination with the Process Owner, the IT Operation Department MUST determine who is allowed to install the software and how. Ideally, software SHOULD always be installed centrally by the IT Operation Department. If it is necessary to install software (or parts thereof) manually, the IT Operation Department MUST create installation instructions that clearly regulate the intermediate steps required for installation and what configurations are to be made. In addition, the IT Operation Department MUST define how the integrity of installation files is to be checked. If digital signatures or checksums are available for an installation package, they MUST be used to verify its integrity. If required, the IT Operation Department SHOULD define a secure default configuration for the software in question. The default configuration SHOULD be documented.
APP.6.A5 Secure Installation of Software (B)
Software MUST be installed in line with the applicable rules on installations in IT systems. Unmodified versions of the approved software MUST be used. If there is any deviation from these instructions, this MUST be approved by the Supervisor and IT Operation Department and documented accordingly.
APP.6.A6 Consideration of Recommended Security Requirements (S)
An organisation SHOULD consider the following security requirements in the requirements catalogue for the software at hand: • The software SHOULD include general security functions that are required in the application context in question, such as logging and authentication. • The software SHOULD make it possible to use the hardening functions of the operational environment. In particular, the hardening capabilities of the intended operating system and execution environment SHOULD be considered. • If the software transmits information over unsecured public networks, it SHOULD use secure encryption functions that reflect the state of the art. In addition, the transmitted data SHOULD be checked for integrity using checksums or digital signatures. • If the software uses certificates, it SHOULD offer the option to display the certificates transparently. It SHOULD also be possible to block certificates, withdraw trust from them, or add the organisation's own certificates. The functions of the software that pertain to the security requirements at hand SHOULD be used in operation.
APP.6.A7 Selection and Assessment of Potential Software [Process Owner, Procurement Department] (S)
The requirements catalogue SHOULD be used to evaluate the products available on the market. They SHOULD be compared with each other using an assessment scale. Whether the products on the short list actually meet the requirements of the organisation in question SHOULD then be examined. If there are several product alternatives, user acceptance and the additional effort required for aspects such as training or migration SHOULD also be considered. The Process Owners SHOULD select a suitable software product together with the IT Operation Department based on the assessments and test results.