Applications

Introduction

Office products primarily comprise applications that are used to create, edit or view documents. They include the free LibreOffice applications and the proprietary Microsoft Office applications used in many organisations. For the majority of organisations, Office products are necessary basic IT equipment. Among other things, they comprise word processing, spreadsheets, presentation creation, and drawing programs, as well as simple database systems.

Objective

The objective of this module is to protect the information processed and used by means of Office products. Achieving this involves special requirements with regard to how the components of Office products function. The module thus illustrates preconditions that should be met in order to protect Office products against specific threats.

Scoping and Modelling

Module APP.1.1 Office Products applies to every Office product used to view, edit or create documents.

This module considers the use of Office products from the perspective of an IT operation department and provides information for users as to how Office products should be used. As a supplement to this module, the requirements of the generic module APP.6 General Software must also be implemented. E-mail applications are not considered in this module. The relevant requirements are covered in module APP.5.3 General E-Mail Clients and Servers. When using integrated database systems such as Base in LibreOffice or Access in Microsoft Office, module APP.4.3 Relational Database Systems must be considered. This module also does not include any pure cloud office applications, such as the Docs and Sheets applications in Google's G Suite. Requirements for cloud applications are defined in module OPS.2.2 Cloud Usage.

Useful Resources

The BSI has published the following documents on the secure configuration of Microsoft Office 2013/2016/2019 in “BSI Publications on Cyber Security”:

• BSI-CS 135: Secure Configuration of Microsoft Office 2013/2016/2019
• BSI-CS 136: Secure Configuration of Microsoft Excel 2013/2016/2019
• BSI-CS 137: Secure Configuration of Microsoft PowerPoint 2013/2016/2019
• BSI-CS 138: Secure Configuration of Microsoft Word 2013/2016/2019
• BSI-CS 139: Secure Configuration of Microsoft Outlook 2013/2016/2019
• BSI-CS 140: Secure Configuration of Microsoft Access 2013/2016/2019
• BSI-CS 141: Secure Configuration of Microsoft Visio 2013/2016/2019

The International Organization for Standardization (ISO) provides specifications that apply to the operation of Office products in the ISO/IEC 27001:2013 standard (Annex A, A.9.4 System and application access control and A.12.5 Control of operational software).

Introduction

Web browsers are application programs that can access (hypertext) documents, images, video, audio, and other data formats on the Internet for processing, viewing, output, and storage on local IT systems. Web browsers can also transmit data to the Internet.

Today, stationary and mobile clients are unthinkable without web browsers because many private and business applications use corresponding content. At the same time, online content is becoming more and more diverse. Most websites use embedded videos, animated elements, and other live content. State-of-the-art web browsers cover a large spectrum of further functions through the integration of plug-ins and external libraries. In addition, there are extensions for certain functions, data formats, and content. However, the complexity of state-of-the-art web browsers also comes with a great deal of potential for serious design errors and technical vulnerabilities. It increases possible risks pertaining not only to attacks from the Internet, but to programming and operating errors, as well.

The risks to data confidentiality and integrity are also significant. Moreover, such vulnerabilities threaten the availability of entire IT systems. As a matter of principle, Internet content must thus be considered untrustworthy from a web browser perspective.

Objective

The objective of this module is to describe security requirements for web browsers used on clients—that is, on stationary and mobile IT systems, including tablets and smartphones.

Scoping and Modelling

APP.1.2 Web Browsers must be applied once to every web browser.

It includes basic security requirements to be considered and met when installing and operating web browsers to access data from the Internet.

Web browsers are some of the most commonly used applications. They access unchecked, potentially malicious data on the Internet and thus provide a gateway for attackers to spread to other parts of operating systems. In order to safeguard operating systems, the requirements of the modules in the layers SYS.2 Desktop Systems and SYS.3.2 Tablets and Smartphones should be met.

Web applications used with browsers, along with the servers that provide such applications, are addressed in the modules APP.3.1 Web Applications and Web Services and APP.3.2 Web Servers.

General requirements for the safe use of software are not covered in this module. These are included in APP.6 General Software, which should be used in addition to this module.

Useful Resources

• BSI publication on cyber security, BSI-CS 047: “Safeguarding Options When Using Web Browsers”
• Minimum standard of the BSI for the use of SSL/TLS protocol by federal authorities according to Section 8, subsection 1(1) of BSIG
• Minimum standard of the BSI for secure web browsers according to Section 8, subsection 1(1) of BSIG
• Common Criteria Protection Profile for Remote-Controlled Browsers System (ReCoBS): BSI-PP-0040

Introduction

Today, smartphones, tablets, and similar mobile devices are also widely used by public authorities and companies. Employees can use them to access their organisation's data and other information and applications at any time regardless of where they are.

Mobile applications (or "apps") are installed and executed on the operating systems used on mobile devices, such as iOS or Android. Apps are usually obtained from app stores. These are operated and maintained by the manufacturers of the operating systems used on mobile devices. In professional environments, however, it is also common for an organisation to develop its own apps and install and manage them on end devices using mobile device management (MDM) solutions. Compared to applications on desktop operating systems, iOS or Android apps are subject to special framework conditions, such as the authorisation management ensured by the operating system.

There is now a large selection of available apps for different mobile operating systems. There are also standardised libraries and development environments that enable apps to be developed quickly compared to conventional applications.

Objective

The objective of this module is to protect information that is processed with apps on mobile end devices. It also covers the integration of apps into existing IT infrastructure. The module defines requirements for the proper selection and secure operation of apps, regardless of whether they are obtained from an app store or installed by an organisation on its own.

Scoping and Modelling

Module APP.1.4 Mobile Applications (Apps) must be applied to all applications that are used on mobile devices.

The module covers apps on mobile operating systems such as iOS and Android. Requirements that affect the underlying operating systems are not considered here. These requirements are covered, for example, in the modules SYS.3.2.3 iOS (for Enterprise) and SYS.3.2.4 Android. Apps are often managed centrally in a mobile device management system. The requirements for such systems are covered in module SYS.3.2.2 Mobile Device Management (MDM).

Similarly, the aspects of specific apps are not discussed in this module. These are covered in the corresponding modules of the APP layer (Applications), such as APP.1.2 Web Browsers.

Apps often rely on back-end systems or server/application services. For cases in which an organisation operates these back-end systems or servers on its own, please refer to the corresponding modules of the IT-Grundschutz Compendium for security recommendations. These include, for example, APP.3.1 Web Applications and Web Services and APP.4.3 Relational Database Systems. Modules dealing with general aspects of applications, such as OPS.1.1.6 Software Tests and Approvals or APP.6 General Software, should also be considered, as these aspects are not covered in this module. The requirements of module CON.8 Software Development should be considered when developing in-house apps.

Useful Resources

Germany’s digital association, Bitkom, has published a decision-making aid for apps and mobile services in companies in the guide entitled “Apps & Mobile Services – Tipps für Unternehmen” [Apps & Mobile Services - Tips for Companies] (2nd edition, 2014).

The Information Security Forum (ISF) has published a paper entitled “Securing Mobile Apps – Embracing Mobile, Balancing Control” (2018).

“NIST Special Publication 800-163: Vetting the Security of Mobile Applications” (2015) also provides extensive information on apps.

Introduction

A data network's directory service provides information on various types of objects in a defined manner. Associated attributes can be stored in an object—the first and last name, personnel number, and the name of the IT system pertaining to a particular user ID, for example. This data can then be used by various applications. A directory service and its data are normally administered from a central location.

Some typical areas of application of directory services include:

• Administration of address books, e.g. for telephone numbers, e-mail addresses, and certificates for electronic signatures
• Resource administration, e.g. for IT systems, printers, scanners, and other peripheral devices
• User administration, e.g. for user accounts and user authorisations
• Authentication, e.g. for logging into operating systems or applications

Directory services are optimised for read-only access because data is typically retrieved. Write access for creating, changing, or deleting entries is needed less often.

This type of directory service is especially useful in networks where the number of clients used in the network makes local administration difficult, for example. Without a directory service, it would no longer be possible to ensure that local settings, such as those pertaining to security policies, are being configured reliably due to the considerable effort involved. Administrative tasks within a network—changing passwords, creating accounts, and assigning access rights, for instance—can also be performed more efficiently using a directory service.

Objective

The objective of this module is to ensure the secure operation of general directory services and the appropriate protection of information processed using such services.

Scoping and Modelling

Module APP.2.1 General Directory Service must be applied to all directory services used.

This module examines general security aspects of directory services. The IT-Grundschutz Compendium includes additional modules for product-specific security aspects that should also be applied to the particular directory service in use. Modules on the server operating systems on which directory services are usually operated can be found in the layer SYS.1 Servers.

Directory services should always be included as part of the modules ORP.4 Identity and Access Management, OPS.1.1.3 Patch and Change Management, CON.3 Backup Concept, OPS.1.2.2 Archiving, OPS.1.1.5 Logging, and OPS.1.1.2 Proper IT Administration.

Useful Resources

No further information is available for module APP.2.1 General Directory Service.

Introduction

Active Directory (AD) is a directory service developed by Microsoft that was introduced for the first time with the Windows 2000 Server operating system. Based on the Active Directory functions available in Microsoft Windows 2000 Server, additional key functions have been added to the service in every release of the Windows Server family of operating systems.

Active Directory is mainly used in networks with Microsoft components. An AD stores information about objects within a network, such as users or IT systems. It makes it easier for users and administrators to provide, organise, use, and monitor this information. Since Active Directory is an object-based directory service, it facilitates the administration of objects and their mutual relationships, which is what constitutes an actual network environment. Active Directory thus provides central control and monitoring capabilities for a given network.

Objective

This module is designed to help secure Active Directory in normal operations in organisations that use it to administer their infrastructure of Windows systems (client and server).

Scoping and Modelling

Module APP.2.2 Active Directory must be applied to all directory services that are based on Microsoft Active Directory.

This module examines the threats and requirements that apply specifically to Active Directory. General security recommendations for directory services can be found in module APP.2.1 General Directory Service. The general requirements described therein are explained in detail and complemented by this module. This module does not repeat the requirements for securing the operating systems of servers and clients used to operate and administrate AD; these are covered, for example, in SYS.1.2.2 Windows Server 2012 and SYS.2.2.3 Windows 10 Clients. This module does not revisit the requirements of the underlying network infrastructure either.

Active Directory should always be included when considering the modules ORP.4 Identity and Access Management, OPS.1.1.3 Patch and Change Management, CON.3 Backup Concept, OPS.1.1.2 Archiving, OPS.1.1.5 Logging and OPS.1.1.2 Proper IT Administration.

Useful Resources

The website “Active Directory Security” (https://adsecurity.org) contains a great deal of further information about AD security.

Microsoft itself provides additional information about Active Directory and its security aspects:

• Enhanced Security Administrative Environment: https://docs.microsoft.com/de-de/windows-server/identity/securing-privileged-access/securing-privileged-access
• Privileged Access Workstations: http://download.microsoft.com/download/9/3/9/9392A4D2-D530-4344-8447-4A7CF1C01AEE/Privileged%20Access%20Workstation_Datasheet.pdf
• Einstiegspunkt Active Directory für Windows Server 2012 (R2): https://technet.microsoft.com/en-us/library/dn283324.aspx
• Introduction to Active Directory for Windows Server 2008 R2: https://technet.microsoft.com/en-us/library/dd378801.aspx

Introduction

OpenLDAP is a freely available directory service that provides information on any objects, such as users or IT systems, in a defined manner within a data network. The information can include simple attributes—the names or numbers of objects, for example—but also complex formats such as photos or certificates for electronic signatures. The typical application scenarios include address books and user administration systems.

OpenLDAP is a reference implementation for a server service within the framework of the Lightweight Directory Access Protocol (LDAP). Since it is open-source software, OpenLDAP can be installed on a variety of operating systems and is one of the most widely used directory services. Overlays are a special feature of OpenLDAP. Overlays add numerous functions to OpenLDAP and are also used for basic functions such as logging, replication, and maintaining integrity.

Objective

The objective of this module is to facilitate the secure operation of directory services based on OpenLDAP and appropriate protection of the information processed using these services.

Scoping and Modelling

Module APP.2.3 OpenLDAP must be applied to every OpenLDAP directory.

This module examines the threats and requirements that apply specifically to OpenLDAP. It does so based on version 2.4 of OpenLDAP. General security recommendations for directory services can be found in module APP.2.1 General Directory Service. These must also be taken into consideration. The requirements described therein are explained in detail and expanded upon in this module.

OpenLDAP should always be considered as part of the modules ORP.4 Identity and Access Management, OPS.1.1.3 Patch and Change Management, CON.3 Backup Concept, OPS.1.1.2 Archiving, OPS.1.1.5 Logging and OPS.1.1.2 Proper IT Administration.

Useful Resources

No further information is available for module APP.2.3 OpenLDAP.

Introduction

Web applications provide users with particular functions and dynamic (changing) content. For this purpose, such applications use the Internet protocols HTTP (Hypertext Transfer Protocol) or HTTPS. With HTTPS, connections are cryptographically secured by the TLS (Transport Layer Security) protocol. Web applications make documents and user interfaces available on a server (in the form of input masks, for example) and deliver them on request to corresponding programs on clients such as web browsers.

Web services are applications that use the HTTP(S) protocol to provide data to other applications. As a rule, they are not directly controlled by users.

Several components are usually required to operate a web application or web service. Web servers are usually required to deliver data, as are application servers to run the actual application or service. Additional background systems are also needed, which are often connected as data sources via different interfaces (e.g. databases or directory services).

Web applications and web services are used in both public data networks and organisations' local networks (intranets) to provide data and further applications. As a rule, users must authenticate themselves in order to access a web application or a web service.

Objective

The aim of this module is to ensure the secure use of web applications and web services and to protect the information they process.

Scoping and Modelling

This module must be applied to every web application and web service that is used in the information domain in question.

It does not cover requirements for web servers or the editorial planning of a web presence. These can be found in module APP.3.2 Web Servers. The development of web applications is covered in module CON.10 Development of Web Applications.

Web service interfaces are often created using Representational State Transfer (REST) or Simple Object Access Protocol (SOAP). This module only considers REST-based web services. It focuses on the operational phase of the lifecycle. Security requirements resulting from planning and design or from decommissioning and business continuity planning are not considered in this module; these must be included in a separate risk analysis.

Finally, general requirements for the selection of software are covered in module APP.6 General Software.

Useful Resources

On its website, the Open Web Application Security Project (OWASP) provides guidance on securing web applications and web services.

The Federal Office for Information Security (BSI) provides guidance on the use of cryptographic procedures in the document “Cryptographic Mechanisms: Recommendations and Key Lengths: BSI TR-02102”.

Introduction

A web server is a key component of any website. It accepts requests from clients and delivers the corresponding content back to them. The data is typically transmitted via the Hypertext Transfer Protocol (HTTP) or HTTP Secure (HTTPS), which is a version encrypted with Transport Layer Security (TLS). Since web servers offer a simple interface between server applications and users, they are also frequently used for internal information and applications in organisations' own networks (intranets).

Web servers are usually available directly on the Internet and are thus exposed to attacks. That is why they must be protected by appropriate security safeguards.

Objective

The aim of this module is to protect web servers and the information they provide and process.

Scoping and Modelling

This module must be applied to all web servers in the information domain in question.

The term “web server” is used for both the software that responds to HTTP requests and the IT systems used to run such software. This module mainly addresses web server software. Security aspects of the IT systems on which web server software is installed are addressed in the corresponding modules of the SYS IT Systems layer (see SYS.1.1 General Server, as well as SYS.1.3 Linux and Unix Servers and SYS.1.2.2 Windows Server 2012).

Recommendations for integrating web servers into network architecture and protecting them with firewalls are included in modules NET.1.1 Network Architecture and Design and NET.3.2 Firewall.

The present module covers fundamental aspects that are important for the provision of web content. It does not address dynamic content provided by web applications or web services. This is dealt with in module APP.3.1 Web Applications and Web Services.

This also applies to web browsers; corresponding requirements are included in module APP.1.2 Web Browsers.

Connections to web servers are usually encrypted. Module CON.1 Crypto Concept describes how cryptographic keys can be managed in a secure manner.

In cases in which web servers are managed by a hosting provider instead of being operated in-house, module OPS.2.1 Outsourcing for Customers must be observed.

Authentication mechanisms are often used for web servers. Additional requirements for these mechanisms can be found in module ORP.4 Identity and Access Management.

Useful Resources

The Federal Office for Information Security has published the following additional documents that may be relevant for the operation of web servers:

• “Migration auf TLS 1.2 – Handlungsleitfaden” [Migration to TLS 1.2 – BSI Action Guidelines]
• “Sicheres Webhosting: Handlungsempfehlung für Webhoster” [Secure Web Hosting: Recommendations for Web Hosts]
• “Sicheres Bereitstellen von Webangeboten (ISi-Webserver)” [Secure Provisioning of Websites (ISi Series for Web Servers)]

In the document “Guidelines on Securing Public Web Servers", the National Institute of Standards and Technology (NIST) also provides advice on web server security.

Introduction

A file server is a network server that provides files centrally from internal or networked hard drives for all users or clients with corresponding access authorisation. Authorised users can thus share data without having to transport it to removable media or distribute it by e-mail, for example. Because the data is stored centrally, it can be structured and provided in various directories and files. With file servers, access rights to files can also be assigned centrally. Furthermore, storing all data in a central location simplifies the creation of backups.

A file server mainly manages mass-storage devices connected via interfaces such as SCSI (Small Computer System Interface) or SAS (Serial Attached SCSI). The storage memory itself is either located directly within the server's casing or connected externally. The latter is often referred to as ‘directly attached storage’ (DAS). A file server can be operated on conventional server hardware or a dedicated appliance. For large data volumes, central storage area network (SAN) devices can also be connected via host bus adapters (HBA) in the server, as well as to SAN switches.

Objective

This module describes the main threats specific to file servers and the resulting requirements for the secure operation of such servers.

Scoping and Modelling

Module APP.3.3 File Servers must be applied once to each file server in the information domain in question.

This module includes basic specifications which must be observed and met when operating file servers. The general and operating-system-specific aspects of a server are not included in this module. These aspects are addressed in module SYS1.1 General Server and in the relevant operating-system-specific modules of the IT Systems layer, e.g. SYS.1.3 Linux and Unix Servers or SYS.1.2.2 Windows Server 2012. Requirements for network-based storage systems or storage networks are not described. These are discussed in module SYS.1.8 Storage Solutions. Dedicated services for operating a file server (e.g. Samba) are also not addressed. The Samba service is covered in module APP.3.4 Samba.

When securing a file server, it is important to assign rights to files in a restrictive manner. Further requirements in this regard can be found in module ORP.4 Identity and Access Management. Furthermore, this module does not cover methods of securing the information stored on a file server. On this topic, the requirements of module CON.3 Backup Concept must be met.

Useful Resources

No further information is available for module APP.3.3 File Servers.

Introduction

Samba is a freely available and full-featured Active Directory Domain Controller (ADDC) that is able to provide authentication, file, and print services as a means of facilitating interoperability between Windows and Unix. Samba combines many different protocols and technologies, including the Server Message Block (SMB) protocol. The term “Samba server” refers to servers running Samba. These are usually Unix servers.

If the use of Samba is designed properly and suitably configured, it will interact with a Windows client or server as if it were a Windows system itself.

Objective

The aim of this module is to show how organisations can use Samba in a secure manner and how information provided by Samba can be protected.

Scoping and Modelling

Module APP.3.4 Samba must be applied to every Samba server within the information domain under consideration.

This module deals with Samba as an authentication, file, and print service. As Samba is usually used on Unix servers, where it provides familiar services from the world of Windows servers, the security aspects of the modules SYS.1.1 General Server and SYS.1.3 Linux and Unix Servers must be considered.

When securing a Samba server, it is important to assign rights to files in a restrictive manner. More detailed information on identity and access management is provided in module ORP.4 Identity and Access Management.

General security requirements for printers, file servers, or directory services are also not part of this module. These are described in the modules SYS.4.1 Printers, Copiers, and All-in-One Devices, APP.3.3 File Servers, APP.2.1 General Directory Service, and APP.2.3 OpenLDAP.

Useful Resources

No further information is available for module APP.3.4 Samba.

Introduction

A domain name system (DNS) is a network service used to resolve the host names of IT systems into IP addresses. A DNS can be compared to a telephone book that resolves names into IP addresses rather than telephone numbers. A DNS usually searches for the IP address that corresponds to a given host name (forward resolution). Searching for a host name based on a known IP address, on the other hand, is referred to as reverse resolution.

The associations between host names and IP addresses are managed in the domain name space. The domain name space has a hierarchical structure and is provided by DNS servers. While the term “DNS server” actually refers to the software used, it is mostly also used as a synonym for the IT system on which this software is run.

DNS servers manage the domain name space on the Internet, but are often also used within an organisation’s internal network. Resolvers are installed as standard components on users’ IT systems. Requests are made to DNS servers via the resolver. In response, the DNS servers return information about the domain namespace.

DNS servers can be differentiated by the tasks they perform. There are basically two different types: advertising DNS servers and resolving DNS servers. Advertising DNS servers are usually responsible for processing requests from the Internet. Resolving DNS servers process requests from an organisation's internal network.

A DNS server failure may have severe consequences for the operation of IT infrastructure. While a failed DNS system is not a major problem in itself, it does result in restricted DNS-based services. Web servers or e-mail servers may no longer be available, or remote maintenance may no longer function. Since DNS is required by a very large number of network applications, RFC 1034 specifies that at least two authoritative DNS servers (advertising DNS servers) must be operated for every zone.

Objective

This module describes the threats specific to DNS servers and the related requirements that ensure their secure operation.

Scoping and Modelling

Module APP.3.6 DNS Servers must be applied to each DNS server used in the information domain under consideration.

This module includes basic specifications to be considered and met when an organisation uses a DNS server. The focus here is on the availability of DNS servers and the integrity of the information transferred. This module also covers problems that can occur in the use of DNS servers.

General and operating-system-specific aspects of a server are not included in this module. These are covered in module SYS1.1 General Server and in the corresponding operating-system-specific modules of the SYS IT Systems layer, e.g. SYS.1.3 Linux and Unix Servers or SYS.1.2.2 Windows Server 2012.

Useful Resources

The BSI has published the following additional documents related to DNS:

• BSI publication on cyber security BSI-CS 055: “Sichere Bereitstellung von DNS-Diensten: Handlungsempfehlungen für Internet-Service-Provider (ISP) und große Unternehmen” [Secure Provision of DNS Services: Recommendations for Internet Service Providers (ISPs) and Large Companies]
• BSI publication on cyber security BSI-CS 121: “Umsetzung von DNSSEC: Handlungsempfehlungen zur Einrichtung und zum Betrieb der Domain Name Security Extensions” [Use of DNSSEC: Recommendations for Setting up and Operating the Domain Name Security Extensions]
• Secure connection of local networks to the Internet (ISi-LANA)

The National Institute of Standards and Technology (NIST) provides recommendations on using DNS in the NIST Special Publication 800-81-2, “Secure Domain Name System (DNS)— Deployment Guide”.

RFC 1034, “Domain Names—Concepts and Facilities”, provides additional information on DNS.

Introduction

Enterprise resource planning systems from SAP are used to automate and technically support internal and external business processes. SAP ERP systems typically process confidential information, which means that all their components and data must be appropriately protected.

SAP ERP systems are currently available under the product names SAP Business Suite and SAP S/4HANA. An SAP ERP system is made up of various modules that can be used to map the structure of an organisation. The modules of a given SAP ERP system may cover areas such as accounting, human resources, and logistics. The core components of the SAP ERP system are SAP NetWeaver (application server middleware) and SAP HANA (application server and database). SAP NetWeaver enables clients to integrate SAP ABAP and SAP Java applications and control processes throughout the system. SAP HANA can analyse large amounts of data for all business units in real time.

Objective

This module describes the risks to be considered with regard to SAP ERP systems and how these systems can be securely installed, configured, and operated. It is geared towards Chief Information Security Officers and administrators who are in charge of planning and implementing SAP ERP systems.

Scoping and Modelling

Module APP.4.2 SAP ERP Systems must be applied to every SAP ERP system.

This module is limited to the core installation of an SAP ERP system and focuses on the specific characteristics of the underlying SAP NetWeaver application server. It does not describe all the available SAP products in detail. The following descriptions are limited to the configuration of the SAP Basis and do not address the configuration of modules or applications.

Requirements for developing ABAP programs can be found in module APP.4.6 SAP ABAP Programming. No adjacent IT systems, operating systems, or databases are considered in detail. On these subjects, specific modules such as SYS1.2.2 Windows Server 2012, SYS.1.3 Linux and Unix Servers, APP.4.3 Relational Database Systems should be applied. This module also does not deal with SAP HANA. Current product names are deliberately omitted, as these change frequently.

Useful Resources

The SAP Help Portal (https://www.help.sap.com/viewer/index) is the central entry point to support from SAP. It offers extensive information and instructions on a wide range of subjects. A selection of topics of interest in the context of SAP ERP systems is listed below:

• SAP Audit Management, https://help.sap.com/saphelp_fra110/helpdata/de/ab/ce1b52bd543c3ae10000000a441470/ frameset.htm und https://help.sap.com/saphel_erp60_sp/helpdata/de/f9/558f40f3b19920e10000000a1550b0/ content.htm
• User Management of SAP NetWeaver AS for Java, https://help.sap.com/saphelp_nw73/helpdata/de/45/b90177cf2252f8e10000000a1553f7/co ntent.htm?no_cache=true
• Central User Administration, https://help.sap.com/doc/erp2005_ehp_07/6.07/de-DE/8d/270bea613d2443bad6ce0524f08ca0/frameset.htm

Detailed best-practice recommendations on audits of SAP ERP systems are provided in the auditing guide SAP ERP 6.0: Best Practice—Recommendations of the German-speaking SAP User Group (DSAG).

Introduction

Database systems (DBS) are often used as auxiliary resources in organising, creating, modifying, and managing large data collections with the help of IT. A DBS consists of a database management system (DBMS) and one or more databases. A database is a collection of data and corresponding descriptions (metadata) that is continuously stored in a database system. Since database systems often play a central role in IT infrastructure, they have to meet essential security requirements. The core processes of an organisation typically depend on information from databases. This results in corresponding availability requirements. Additionally, there are often high requirements regarding the confidentiality and integrity of the information stored in databases.

Objective

The objective of this module is to demonstrate the secure operation of relational database systems and the appropriate protection of the information processed and stored in databases. It thus describes requirements that can be used to securely plan, implement, and operate database systems and reduce threats.

Scoping and Modelling

APP.4.3 Relational Database Systems must be applied once to each relational database system in use.

This module describes requirements for relational database systems. Security requirements for non-relational database systems are not covered here.

In order to continuously protect the information in databases, security requirements for the design of database tables and access to databases should have been considered during the corresponding application development process. However, this module does not cover these issues.

It also does not address the threats and requirements that affect the operating system and hardware on which a database system is installed. These aspects are covered in the corresponding operating system-specific modules of the IT Systems layer, e.g. SYS.1.3 Linux and Unix Servers or SYS.1.2.2 Windows Server 2012.

Relational database systems should always be considered as part of modules OPR.4 Identity and Access Management, OPS.1.1.3 Patch and Change Management, CON.3 Backup Concept, OPS.1.2.2 Archiving, OPS.1.1.5 Logging, and OPS.1.1.2 Proper IT Administration.

Useful Resources

The BSI has published the following partner contributions on the topic of database security within the framework of the Alliance for Cyber Security:

• Oracle: Datenbank-Sicherheit – Grundüberlegungen [Oracle: Database Security – Basic Considerations]
• McAfee: Datenbanksicherheit in Virtualisierungs- und Cloud-Computing-Umgebungen [McAfee: Database Security in Virtualisation and Cloud Computing Environments]

The Deutsche Telekom Group has published the document "Sicherheitsanforderung Datenbanksysteme" [Security Requirements for Database Systems] as part of its Privacy and Security Assessment (PSA) process.

Section BA2.3, "Protection of Databases" of “The Standard of Good Practice for Information Security” (published by the Information Security Forum, ISF) provides guidelines for the protection of relational database systems.

Introduction

Kubernetes has established itself as the de facto standard for the orchestration of containers in public and private clouds. Kubernetes is also used for IoT and other applications; with K3S, for example, there is an edition that is intended for very small servers such as single-board computers. The cloud native stack, which consists of many different components, is also built on the standard established by Kubernetes.

The term "container" refers to a technique in which a host system runs applications in parallel in separate environments (virtualisation at the operating system level). In most cases, the monitoring, starting and stopping, and further administration of containers is carried out by management software, which thus takes over the orchestration. Kubernetes combines one or more related containers in a pod. Since the focus of this module is Kubernetes, it only considers pods and not individual containers. The orchestration is mostly carried out in groups of jointly managed Kubernetes nodes in one or more “clusters”.

Several products that have established themselves as ways to operate and manage the orchestration of pods make it possible to manage very large environments, as well. At their core, however, they are all based on Kubernetes. When considering such products, a distinction must be made between the runtime, which runs the processes on Kubernetes nodes, and the orchestration, which controls the runtimes on multiple Kubernetes nodes.

In addition to these two central components, the operation of Kubernetes usually consists of a specialised infrastructure that includes things like registries, code versioning and storage, automation tools, management servers, storage systems, or virtual networks.

The terms below are defined as follows for this module:

• Application means a collection of multiple programs that perform a task together
• Cluster means operating environments for containers with multiple nodes
• Containers are processes started from an image that run within operating system namespaces
• Container Network Interface (CNI) is the interface for managing the virtual networks in a cluster
• Container Storage Interface (CSI) is the interface to the mostly external storage systems that Kubernetes can provide to pods
• Control plane refers to all applications used for the management (i.e. orchestration) of nodes, runtimes, and clusters
• Images are all software packages that comply with the Open Container Initiative (OCI); these include both base images for custom images and images that are used unchanged
• Node refers to a server that is installed and optimised for the operation of a runtime
• Pod refers to a collection of several containers running within the same operating system namespace
• Registry is the generic term for code management and image storage
• Runtime is the software that runs the software in an image as a container

Objective

The objective of this module is to protect information that is processed, provided, or transmitted via Kubernetes clusters.

Scoping and Modelling

APP.4.4 Kubernetes should always be used in conjunction with module SYS.1.6 Containerisation. In terms of the focus of this module, the container runtime used or the additional applications that are part of the control plane are not relevant.

The module contains basic requirements for setting up, operating, and orchestrating with Kubernetes, as well as for the specialised infrastructure required for related operations. The latter includes registries, CSI/CNI, nodes, and automation software insofar as they interact directly with the cluster. The requirements for these applications mostly relate to the interfaces, but also include requirements that affect the operation of the applications to the extent that they directly affect the security of the respective cluster. Other services common in the Kubernetes environment, such as automation for CI/CD pipelines and code management (e.g. in Git) are not covered in depth in this module.

This module provides comprehensive modelling of a cluster. In this context, the applications of the control plane, services for automation, and nodes should be seen and treated as one group.

Security requirements for services operated in Kubernetes clusters, such as web servers (APP.3.2 Web Servers) or e-mail servers (see APP.5.3 General E-Mail Clients and Servers), are the subject of separate modules.

Useful Resources

For more information about threats and security safeguards with regard to containers, see the following publications, among others:

• NIST 800-190 https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-190.pdf
• CIS Benchmark Kubernetes https://www.cisecurity.org/benchmark/kubernetes/
• OCI – Open Container Initiative https://www.opencontainers.org/
• CNCF – Cloud Native Computing Foundation https://www.cncf.io/

Introduction

In-house or custom software development are often programmed in SAP systems. Such developments enable an organisation to adapt individual business processes or reporting requirements to its needs, for example. It is also possible to create special functions that are not available out-of-the-box.

Custom developments may be programmed by an organisation's in-house developers or by those it commissions. ABAP (Advanced Business Application Programming) is often used for this in the SAP environment.

ABAP is a proprietary, platform-independent programming language from the company SAP. It was developed for programming commercial applications in the SAP environment, and its basic structure bears a slight resemblance to the COBOL language. Its important features are:

• Integration of an authentication, role, and authorisation concept
• Use of a proprietary, database-agnostic SQL derivative (Open SQL)
• Support for communications among different SAP systems
• Integration of audit options

Objective

This module shows ABAP developers and security testers the relevant technical risks that can result from in-house or custom ABAP development. It also defines requirements that show how ABAP programs can be securely developed and used.

This module requires basic knowledge of ABAP and in-house or custom ABAP development tools.

Scoping and Modelling

Module APP.4.6 SAP ABAP Programming must be applied once to each SAP system that involves in-house or custom development created in the ABAP programming language.

This module supplements the modules CON.8 Software Development, APP.6 General Software and APP.7 Development of Individual Software with specific aspects of developing ABAP programs.

It describes the general risks of the ABAP programming language and is not a complete guide to developing ABAP programs. The module defines requirements that should be met from a security point of view when developing ABAP programs.

As web applications only make up a very small proportion of all ABAP applications in SAP implementations, web vulnerabilities are not the focus of this document.

Useful Resources

The “Best Practice Guidelines for Development – Useful Tips for ABAP Development” published by the German-speaking SAP User Group (DSAG) contains more detailed information on ABAP programming.

Further information and best practices on secure ABAP programming is available in Sichere ABAP-Programmierung [Secure ABAP Programming] by Wiegenstein, Schumacher, Schinzel, and Weidemann, which is published by SAP Press.

Introduction

Microsoft Exchange Server (hereinafter “Exchange”) is a groupware solution for medium-sized to large organisations. It can be used to electronically transmit messages and is equipped with additional services for supporting workflows. Exchange can be used to centrally manage, deliver, filter, and send messages such as e-mails. It also provides and manages typical groupware applications such as notes, contact lists, calendars, and task lists. In addition to the server service itself, client software or a web browser is necessary in order to use the functions of Exchange.

Microsoft Outlook (hereinafter “Outlook”) is a client for Exchange that is made directly available by installing the Office package from Microsoft or by integrating it into the operating systems of mobile devices. Furthermore, the “Outlook on the web” application (previously the “Outlook Web App”) makes it possible to access e-mails, contacts, the calendar, and more via a browser. This function is already included in Exchange.

The combination of Exchange servers and Outlook clients is referred to in this module as the Exchange system.

Objective

The objective of this module is to provide information on typical threats to Exchange and Outlook and show how Exchange and Outlook can be used securely in organisations.

Scoping and Modelling

The module must be applied for all Exchange systems in the information domain under consideration.

General requirements for the security of e-mail systems are included in module APP.5.3 General E-Mail Clients and Servers. This module must also be applied to any e-mail system based on Exchange or Outlook.

It includes specific threats and requirements regarding Exchange systems. Specific requirements for server platforms and operating systems are not part of this module. These can be found in the modules SYS.1.1 General Server and SYS.2.1 General Client, as well as in the respective operating-system-specific modules.

Useful Resources

Microsoft provides comprehensive information on the administration of Microsoft Exchange on the website “Microsoft Technet” (https://technet.microsoft.com/de-de).

Introduction

E-mail is one of the oldest and commonly used Internet applications. E-mails are used to send text and attached files to other people. Users require an e-mail address for this purpose.

E-mail applications require e-mail servers that can send and receive electronic messages. As a rule, e-mail clients retrieve messages intended for them from an e-mail server using the POP3 or IMAP protocols and send messages to the e-mail server using the SMTP protocol, which forwards them to another e-mail server if necessary.

Since e-mail is widely used, especially at companies and public authorities, e-mail servers are often targeted by attackers.

E-mail clients are often also a focus of attack: sending malware via e-mail is a common strategy. In addition, e-mails are often used as a tool for social engineering attacks.

For these reasons, the secure operation and use of e-mail applications is of particular importance.

Objective

The objective of this module is to protect information that is processed with e-mail clients or on e-mail servers.

Scoping and Modelling

Module APP.5.3 General E-Mail Clients and Servers must be applied to each e-mail client and server in the information domain under consideration.

The module includes requirements for general e-mail servers and clients. Requirements for server platforms, operating systems, and clients are not covered. These can be found in the modules SYS.1.1 General Server and SYS.2.1 General Client, as well as in the respective operating-system-specific modules.

Within the context of an information domain, module APP.5.3 General E-Mail Clients and Servers is mostly used in combination with another specific module of layer APP.5 E-Mail/Groupware/Communication. These must also be implemented separately. Among others, these modules include APP.5.2 Microsoft Exchange and Outlook.

Requirements for logging and backup are included in the modules OPS.1.1.5 Logging and CON.3 Backup Concept.

Groupware functions that offer features such as the administration of contact details and calendars in addition to e-mail are not covered in this module. Pure cloud solutions such as those that are part of Microsoft 365 or Google's G Suite are also not included. General requirements for this are included in module OPS.2.2 Cloud Usage.

Useful Resources

In the ISO/IEC 27001:2013 standard, the International Organization for Standardization (ISO) specifies requirements for the operation of e-mail services in section 13.2.3.

Section CF2.3.3 of “The Standard of Good Practice for Information Security” published by the Information Security Forum (ISF) provides guidelines for operating e-mail services.

In its “Guidelines on Electronic Mail Security”, the National Institute of Standards and Technology (NIST) describes how e-mail applications can be run securely.

In “BSI TR-03108 Secure E-Mail Transport”, the Federal Office for Information Security (BSI) provides information on sending e-mails securely.

Introduction

In this module, the term "general software" includes all software regardless of whether it relates to word processing, an operating system, a mobile communication app, custom-developed software, or a distributed content management system.

As a rule, all software has a lifecycle that includes planning, requirements analysis, procurement, testing (including release), installation in a production environment, training, operation, updates and change management, and decommissioning (including uninstallation). This lifecycle can vary depending on the application context at hand. As a result, specific applications can involve further individual steps, and the scope of these steps can also vary.

In the intermediate steps covered herein, however, there are recurring aspects of information security that can be applied to any type of software.

Objective

This module illustrates the security requirements that must be met to ensure that general software can be used securely throughout its lifecycle. The primary objective is to protect software and the information it processes.

Scoping and Modelling

Module APP.6 General Software must be applied to all software used in the information domain under consideration. This does not include operating systems that run on closed systems such as IoT devices, routers, printers, or embedded systems. Software is often delivered in a bundled manner (e.g. in office suites or operating systems with extensively integrated tools) or extended by things like plug-ins or add-ons. In such cases, this module can be applied once to the entire software bundle in question.

This module only deals with standardised and generic procedures in the lifecycle of software. No specific recommendations are given on the detailed configuration of software or securing it by means of individual protection mechanisms on the IT systems used. The specific modules in the APP layer should be used for these purposes.

The intermediate steps of release (including software tests) and patch and change management are also not covered in this module. They are dealt with in OPS.1.1.6 Software Tests and Approvals and OPS.1.1.3 Patch and Change Management.

If certain requirements cannot be met by a finished, ready-to-use software product (e.g. by adapting its configuration) and a custom-developed product is needed, this module should be supplemented by APP.7 Development of Individual Software.

Software and the data associated with it often need to be available in emergencies. Initial considerations in this regard are covered in module DER.4 Business Continuity Management.

Useful Resources

In the ISO/IEC 27001:2013 standard (annex A.14, “Security Requirements of Information Systems”), the International Organization for Standardization (ISO) specifies requirements for the information security of IT systems that should also be taken into account when selecting and using software.

The Common Criteria for Information Technology Security Evaluation (CC) form the basis for internationally recognised product certifications. CC certification can therefore be used as evidence of a software product's information security.

The National Institute of Standardisation and Technology formulates requirements for the acquisition of IT products, including software, in NIST Special Publication 800-53 (appendix F, “Family System and Service Acquisition”).

In “The Standard of Good Practice for Information Security”, the Information Security Forum (ISF) presents best practices for securing software in the section “Business Application Management”.

Introduction

Many organisations faced challenges that they can no longer adequately solve with unadapted software. The tasks associated with these challenges often require software solutions that are tailored to an organisation's individual needs. In this module, these software solutions are referred to as individual software. One variant involves implementing basic solutions that comprise a set of typical functions and then customising them. The basic functions are adapted to an organisation's specific purposes and supplemented by individually required functions. Common examples of this involve IT applications such as enterprise resource planning (ERP) systems, content management systems (CMS), or identity management (IDM) systems. Individual software can also be developed entirely from scratch by an organisation or third parties. This includes applications for business process control or individually adapted specialised applications, such as personnel management software or procedures for managing social data or registration data.

It is essential that the required security functions be considered during the planning and design of individual software and that information security be taken into account throughout the entire lifecycle. It can take a great deal of additional effort (or be impossible) to compensate for planning errors or missing security functions during live operations.

Individual software is usually developed as part of a project. A wide variety of process and project management models have been established for this purpose. While classic, linear process models such as the waterfall process are very well suited to projects with fixed requirements at the beginning, agile procedure models such as Scrum enable individual software to be developed iteratively and incrementally. Agile procedure models can thus adapt better to changing circumstances, especially if not all requirements are fixed at the beginning. However, they do not offer the same costing certainty as linear procedure models and in some cases do not fit the classic structures of procurement processes, which are geared towards a linear approach.

Objective

The aim of this module is to cover the basic security requirements to be considered when planning and developing individual software.

Scoping and Modelling

Module APP.7 Development of Individual Software must be applied once to each development of individual software.

Aspects of planning, designing, and using individual software, such as defining required security functions or decommissioning such software, are covered in APP.6 General Software. It should therefore always be used in conjunction with this module.

Software development very often involves a client-contractor relationship. This situation is reflected in IT-Grundschutz in that the APP.7 Development of Individual Software module deals with the client side, while CON.8 Software Development module covers the contractor side.

The release and testing of individual software are covered in module OPS.1.1.6 Software Tests and Approvals.

Useful Resources

The International Organization for Standardization (ISO) provides the following:

• An overview of all components in the software lifecycle in the norm ISO/IEC 12207:2008, “System and Software Engineering – Software Life Cycle Process”
• An overview of the options for system security in the standard ISO/IEC 15408-2:2008, “Information Technology – Security Techniques – Evaluation Criteria for IT Security – Part 2: Security Functional Components”
• Requirements for system development and operation in the standard ISO/IEC 27001:2013, “Information Technology – Security Techniques – Information Security Management Systems – Requirements” (annex A, A.14, "System Acquisition, Development and Maintenance")

In its standard "The Standard of Good Practice for Information Security", the Information Security Forum (ISF) sets requirements for the management of business applications in "Area BA Business Application Management".

In “NIST Special Publication 800-53” (appendix F-SA, “Family: System and Services Acquisition, Family: System and Communications Protection, and Family: System and Information Integrity”), the National Institute of Standards and Technology specifies further requirements for handling individual software.