IT Systems

Introduction

The term “general server” refers to IT systems running any operating system that provide services to users and other IT systems. These services can be basic services for a local or external network, for example, or those that facilitate the exchange of e-mails or make databases and printer services available. Server IT systems play a key role in information technology, and thus in the well-functioning workflows of an organisation. Servers often perform tasks in the background without direct user interaction. On the other hand, some server services interact directly with users and are not perceived as a server service at first glance. The X server on Unix is a well-known example.

Objective

The objective of this module is to protect information that is processed, offered, or transmitted by servers, along with associated services.

Scoping and Modelling

SYS.1.1 General Server must be applied to all server IT systems running any operating system.

Server systems usually run operating systems for which specific security requirements must be taken into consideration. For widely used server operating systems, separate modules that build on this module can be found in the IT-Grundschutz Compendium. SYS.1.1 General Server forms the basis for the modules on specific server systems. If a specific module exists for a given system, that module must be used in addition to SYS.1.1 General Server. If there is no specific module for the server systems in use in a particular case, the requirements of this module must be adapted in a suitable manner.

The specific services offered by a given server are not part of this module. For these server services, other modules will need to be implemented in addition to this module. These modules should be selected based on the results of the IT-Grundschutz modelling process. If interactive use by users is also planned for a server system (e.g. a terminal server) in a particular case, the associated security aspects must also be considered.

It is essential that the requirements for role and access control policies described in module ORP.4 Identity and Access Management and the requirements of module DER.4 Business Continuity Management also be considered.

Furthermore, servers should always be considered in malware protection concepts. Corresponding requirements can be found in module OPS.1.1.4 Protection Against Malware.

For servers, there are special requirements for administrators and the handling of patches and changes. Therefore, the requirements of the modules OPS.1.1.2 Proper IT Administration and OPS.1.1.3 Patch and Change Management must be observed.

Servers frequently provide services to a large number of clients, often via the Internet. For this reason, it is particularly important that they be separated from the rest of an organisation's network. Requirements for this can be found in module NET.1.1 Network Architecture and Design.

Useful Resources

NIST Special Publication 800-123, "Guide to General Server Security" (July 2008), is offered by the National Institute of Standards and Technology.

Introduction

In Windows Server 2012, Microsoft released an operating system for servers in September 2012 that featured several improvements in security compared to previous Windows versions (particularly Windows Server 2008 R2). Rather than the code base of its predecessor, Windows Server 2021 builds on that of the Windows 8 client operating system from a technical point of view. In the Windows Server 2012 R2 release in October 2013, the operating system was updated and extended to make it the server equivalent of the client-side Windows 8.1.

This module addresses the process of securing both Windows Server 2012 and Windows Server 2012 R2. If both versions are meant, the uniform term "Windows Server 2012" is used. Differences in the R2 version are mentioned separately. The expiration dates for mainstream and extended support (“end of life”, EoL) for both operating systems are 9 January 2018 and 10 January 2023, respectively.

Objective

The objective of this module is to protect information and processes that are processed and controlled on server systems running Windows Server 2012.

Scoping and Modelling

Module SYS.1.2.2 Windows Server 2012 must be applied to all server systems on which the Microsoft Windows Server 2012 operating system is used.

This module specifies and adds specific features of Windows Server 2012 to the aspects included in module SYS.1.1 General Server. Accordingly, the two modules must always be used together.

Within the framework of this module, a default integration into an Active Directory domain is assumed, as is common in organisations. The particularities of stand-alone systems are only mentioned selectively where the differences appear to be particularly relevant. Requirements related to Active Directory are covered in module APP.2.2 Active Directory.

The security requirements of possible server roles and functions, such as file servers (APP.3.3 File Servers), web servers (APP.3.2 Web Servers), or Microsoft Exchange and Outlook (APP.5.2 Microsoft Exchange and Outlook), are covered in separate modules, as is the subject of virtualisation (SYS.1.5 Virtualisation). This module is about using built-in resources to achieve basic security at the operating system level regardless of the server's intended purpose.

Useful Resources

Microsoft provides the following additional information about Windows Server 2012:

• Secure Windows (for Windows 8/8.1, but largely also applicable to Windows Server 2012 / 2012 R2): https://technet.microsoft.com/en-us/library/hh832031.aspx
• Secure Windows Server 2012 R2 and Windows Server 2012: https://technet.microsoft.com/en-us/library/hh831360.aspx
• Security and Protection: https://technet.microsoft.com/en-us/library/hh831778.aspx
• List of security events on Windows 8.1 and Windows Server 2012: https://www.microsoft.com/en-us/download/confirmation.aspx?id=50034
• Configuring Additional LSA Protection: https://docs.microsoft.com/de-de/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection
• Windows Server Guidance to Protect Against Speculative Execution: https://support.microsoft.com/en-us/help/4072698/windows-server-guidance-to-protect-against-speculative-execution

The Information Security Forum (ISF) provides specifications for the use of servers in “The Standard of Good Practice for Information Security”, in particular in Area SY1.2 ("Server Configuration").

NIST Special Publication 800-123, "Guide to General Server Security" (July 2008), is offered by the National Institute of Standards and Technology (NIST).

Introduction

The operating systems Linux and Unix are often used on server systems. Examples of classic Unix systems include the BSD series (FreeBSD, OpenBSD, and NetBSD), Solaris, and AIX. Linux, on the other hand, is a functional Unix system rather than a classic Unix system. This means that the Linux kernel is not based on the original source code from which the various Unix derivatives developed. This module considers all the operating systems in the Unix family, including Linux as a functional Unix system. Since the configuration and operation of Linux and Unix servers are similar, Linux and Unix are jointly referred to in this module as "Unix servers" and "Unix-like".

Linux is free software that is developed by the open-source community. This means anyone can use, copy, distribute, or modify it. In addition, there are providers that compile and maintain the various software components for distribution and offer further services. For Linux servers, the distributions Debian, Red Hat Enterprise Linux / CentOS, SUSE Linux Enterprise / openSUSE, or Ubuntu Server are often used. In addition, there are Linux distributions tailored to special purposes and devices, such as OpenWRT for routers.

The services offered on a Unix server are often central, which means they are particularly exposed. For this reason, Unix servers are not only critical for business processes; they are also frequently the focus of attacks. As a result, the availability and protection of Unix servers is of particular importance.

Objective

The objective of this module is to protect information that is provided and processed by Unix servers. The requirements of the module mainly apply to Linux servers, but can be generally adapted to Unix servers. Requirements are formulated on how to configure and operate these operating systems independently of the intended purpose of the server in question.

Scoping and Modelling

Module SYS.1.3 Linux and Unix Servers must be applied to all servers on which Linux- or Unix-based operating systems are used.

The module contains basic specifications for creating and operating Unix servers. It specifies and adds specific features of Unix systems to the aspects included in module SYS.1.1 General Server.

Security requirements of possible server functions such as web servers (APP.3.2 Web Servers) or e-mail servers (see APP.5.3 General E-Mail Clients and Servers) are covered in separate modules; they are not addressed here. One exception is the Unix-specific server service SSH, which is also dealt with in this module. Similarly, the topic of virtualisation is not addressed in this module, but in SYS.1.5 Virtualisation.

Useful Resources

NIST Special Publication 800-123, "Guide to General Server Security" (July 2008), is offered by the National Institute of Standards and Technology (NIST).

Introduction

When IT systems are virtualised, one or several virtual IT systems are run on a physical IT system. A physical IT system of this kind is referred to as a virtualisation server. Several virtualisation servers may be consolidated to form a virtual infrastructure. Here, the virtualisation servers themselves and the virtual IT systems operated on them may be jointly administered.

The virtualisation of IT systems provides many advantages for IT operations in an information domain. For example, cost savings are possible in the fields of hardware procurement, electricity, and air conditioning if the resources of physical IT systems are used more efficiently. However, virtualisation also poses a challenge in operating an information domain. Since the virtualisation technology used affects different areas and fields of work in an information domain, knowledge and experience is required in these areas. In addition, problems on a virtualisation server can also affect all the other virtual IT systems operated on the same server. Virtual IT systems can also interfere with each other's operations.

Objective

The objective of this module is to show how virtualisation servers in an information domain can be securely implemented and operated.

Scoping and Modelling

SYS.1.5 Virtualisation must be applied to every virtualisation server.

In addition to this module, the relevant server or client modules of the SYS IT Systems layer must also be applied to each virtualisation server. Along with the operating-system-specific modules, modules SYS.1.1 General Server and SYS.2.1 General Client must be applied, as they summarise the platform-independent security aspects for servers and clients.

This module only deals with the virtualisation of complete IT systems. Other techniques, some of which are also associated with the term “virtualisation” (e.g. application virtualisation using terminal servers, storage virtualisation and containers), are not the subject of this module.

In the field of software development, the terms "virtual machine" and "virtual machine monitor" are also used for runtime environments (e.g. when Java or Microsoft .NET are used). Runtime environments like these are not addressed in this module either.

Virtual infrastructures are normally administered using specific management systems. Since these IT systems can be used to gain comprehensive access to a virtualisation infrastructure, it is important that they be sufficiently secured. This is applicable to both the physical or virtual server used to execute the management software and the product itself.

Virtualisation environments are mostly used together with storage networks (NAS or SAN). The connection and protection of these systems are also not addressed in this module (for this, see module SYS.1.8 Storage Solutions).

When using virtualisation, an organisation must structure its networks differently. This subject is not addressed comprehensively in this module. To this end, the requirements of module NET.1.1 Network Architecture and Design must be implemented. Finally, network virtualisation is also not examined in depth in this module.

Useful Resources

In the cyber security publication BSI-CS 113, “Server-Virtualisierung” [Server Virtualisation], the BSI provides recommendations on the use of virtualisation.

The Information Security Forum (ISF) provides specifications for the operation of virtual servers in “The Standard of Good Practice for Information Security” (section SYS.1.3, "Virtual Servers").

The National Institute of Standards and Technology (NIST) provides recommendations for the use of virtualisation in NIST Special Publication 800-125, “Guide to Security for Full Virtualization Technology”.

Introduction

The term containerisation describes a concept in which resources of an operating system are partitioned to create execution environments for processes. Depending on the operating system used, techniques that differ in terms of their functional scope and security features can be employed. This is often referred to as “operating system virtualisation”. However, an operating system is not virtualised in its entirety; certain resources are made available through a shared kernel. Generally, the term container is used to describe the resulting construct.

Before building and using complex container environments without due consideration, a thorough evaluation should be made in terms of whether the effort required to create and operate a container environment is suitably proportional to the actual benefits. The proper operation of container environments is very complex and there are many requirements to consider. Containers can be used as an additional separation mechanism to harden an environment, provided that the type of container technology and the configuration undertaken are appropriate and suitable for this purpose.

Here, a distinction is made between application containers (e.g. in line with the specification of the Open Container Initiative, OCI) and system containers. System containers such as FreeBSD jails, Solaris zones, OpenVZ, LXC, and LXD are the oldest type of containers. They provide an environment that behaves similarly to a standalone operating system that can provide appropriate services and run multiple applications. Application containers, on the other hand, are specifically designed to run a single application. They follow the lifecycle of the application, but do not offer operating-system-specific services within the container. From a technical point of view, however, these two types rely on the same mechanism for separation (i.e. process isolation by the kernel).

In the example of the Linux container (LXC), the mechanisms of namespaces and cgroups are mainly used to supplement process isolation.

• Namespaces are used to control which resources a process can see. There are seven different namespaces: mount (mnt), process ID (pid), network (net), inter-process communication (ipc), UTS (uts), user ID (user), and control group (cgroup).
• cgroups are used to control which resources or which part of a resource a process can use. In particular, resources include memory, CPU, BLKIO, or PIDS.

There are many details to consider when using namespaces and cgroups. Among other things, the order in which namespaces are shared plays a decisive role. Container runtimes have been developed for this purpose, such as runc, crun, railcar, or even katacontainers. The main task of container runtimes is to create a special execution environment for processes. They communicate with the kernel and issue syscalls with the appropriate parameters or in the correct order to obtain the desired execution environment.

As with an operating system, containers usually require a file system in which the programs to be executed are stored. In the container environment, certain file formats have become established to describe these file systems. These are also called images. However, they are sometimes also referred to incorrectly as containers. Depending on the type of container used, the content of these images can range from a single statically compiled application to the complete content of an operating system, including various execution environments and other dependencies. These images are transportable, self-contained units that can be deployed in a container environment and contain all the components required for functionality.

In addition to runtimes, there are container engines such as Docker, Rocket, or CRI-O, which take on many administrative tasks. Primarily, they form the interface to the user and process transferred commands. They ensure that the required images are available and that corresponding metadata are prepared. Finally, the container engine calls the container runtime with corresponding parameters. The container engine is thus not part of the containerisation mechanism, but takes on an administrative function here.

Furthermore, there are different types of containers. These differ according to the deployment scenario and the lifecycle of the container in question. A “persistent container” is a container that is intended to be used for a longer period of time. There may well be valid reasons to store data permanently in containers. Especially in the cloud environment, however, “volatile containers” are frequently encountered. There, containers usually have a much shorter lifespan, which is also often determined by orchestration tools.

Within the OCI, efforts are being made to provide standards and reference implementations. For example, runc is the standard reference implementation of a container runtime. Other container runtimes that are compatible with the OCI standard can thus be widely exchanged and used.

Objective

The objective of this module is to protect information which is processed, provided, or transmitted from or with containers. The module deals with how containers can be secured in principle. A distinction is made between the services for operating containers (i.e. the software that is responsible for configuring and managing them) and the applications and services that are executed within containers.

Scoping and Modelling

SYS.1.6 Containerisation must always be used whenever services or applications are run in containers.

This module considers containers without regard for specific products. The requirements are based on the capabilities of implementations currently available on the market. When selecting a product, module APP.6 General Software must be taken into account.

The module supplements the aspects dealt with in the modules SYS.1.1 General Server and SYS.1.3 Linux and Unix Servers with specifics related to containerisation. The requirements of these modules should be met by the host system regardless of whether it is running on physical servers or is virtualised. Furthermore, the requirements of these modules also apply to each of the user space environments created in the context of containerisation. Other modules, such as CON.8 Software Development or the modules of the sub-layer OPS.1.1 Core IT Operation, must be considered on a regular basis. This is especially true for the creation of images.

Typically, containers communicate with each other through virtual networks on the host system. The modules of the sub-layers NET.1 Networks and NET.3 Network Components must be considered accordingly.

Security requirements of possible services, such as web servers (APP.3.2 Web Servers) or web applications (APP.3.1 Web Applications and Web Services) are the subject of separate modules that must be applied additionally. If the host system is virtualised, module SYS.1.5 Virtualisation must be followed.

If containers and their underlying infrastructure are not completely operated and used on their own, but parts of them are provided or used by third parties, additional requirements of the modules OPS.2.1 Outsourcing for Customers, OPS.2.2 Cloud Usage, and OPS.3.1 Outsourcing for Service Providers must be considered.

The present module contains basic specifications for setting up and operating containers. The other common services in the containerisation environment, such as orchestration of containers, storage systems, virtual networks, automation for CI/CD pipelines, or the operation of image registries, are not considered here. This module also does not make any statements about requirements that apply to the construction of images. For requirements regarding the orchestration of containers with Kubernetes, module APP.4.4 Kubernetes should be considered.

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 Docker https://www.cisecurity.org/benchmark/docker/
• OCI – Open Container Initiative https://www.opencontainers.org/
• CNCF – Cloud Native Computing Foundation https://www.cncf.io/
• SANS Checklist https://www.sans.org/reading-room/whitepapers/auditing/checklist-audit-docker-containers-37437
• Docker Security Guide https://docs.docker.com/engine/security/

Introduction

IBM Z type systems belong to the server systems generally referred to as mainframes. Mainframes have evolved from classic stand-alone systems with batch processing into state-of-the-art client/server systems. The Z architecture – the successor to the S/360 architecture introduced in 1964 – is often used in current mainframe installations.

Objective

The objective of this module is to protect information which is processed, provided, or transmitted via Z systems.

Scoping and Modelling

Module SYS.1.7 IBM Z must be applied to every server based on IBM’s Z architecture.

Module SYS.1.1 General Server forms a generic basis for the protection of servers. For Z systems, both the general requirements listed there and the specific requirements in this module must be met.

Different operating systems are available for the Z hardware (e.g. z/OS, z/VM, KVM, or Linux on Z). These are normally selected based on the size and purpose of the computer at hand. The recommendations of this module are essentially limited to the operating system z/OS. Select security aspects of z/VM are also addressed. For the Linux on Z operating system, please refer to module SYS.1.3 Linux and Unix Servers.

Modules ORP.4 Identity and Access Management and OPS.1.2.5 Remote Maintenance contain additional requirements that are particularly relevant for IBM Z.

An important component of the security concept of Z systems at the technical level is the security system used—for example, TopSecret, ACF2 (Access Control Facility), or RACF (Resource Access Control Facility). To simplify the information presented, only RACF is discussed below. The recommendations should be adapted accordingly if a different security system is used.

The respective specific services offered by the Z system are not part of this module. For these services, additional modules will need to be implemented based on the results of the IT-Grundschutz modelling process.

Useful Resources

A number of abbreviations that are not explained elsewhere in IT-Grundschutz are commonly used in the Z system environment. These include:

• HMC (Hardware Management Console), MCS (Multiple Console Support), SMCS, Extended MCS: consoles for monitoring and controlling a Z system or z/OS operating system
• HFS: Hierarchical File System
• IPL: Initial Program Load, the startup procedure of an operating system
• RSF: Remote Support Facility
• SE: Support Elements, for system configuration and control
• SMP/E: System Modification Program/Extended, a software installation procedure
• zFS: zSeries File System, a file system used in z/OS and Unix System Services (USS)

IBM provides further information on the IBM Z in “ABC of z/OS System Programming Volume 1-13” (IBM Redbooks, https://www.redbooks.ibm.com).

Introduction

The constant growth of digital information and the increasing amount of unstructured information are prompting organisations to implement central storage solutions. The requirements for such storage solutions are subject to constant change; this can be seen, for example, in the following aspects:

• The data of an organisation should be available at any time and place for various application scenarios. This is why state-of-the-art storage solutions are often subject to more stringent availability requirements.
• The increasing digitalisation of all information within an organisation also makes it necessary to consider and comply with wide-ranging legal requirements (compliance).
• Storage solutions should be dynamically adaptable to the continuously changing requirements and able to provide storage space in a centralised manner.

In the past, storage solutions were often implemented by connecting storage media directly to a server. However, these direct-attached storage (DAS) systems often are no longer able to meet current and future requirements. This has led to the necessity for the central storage solutions commonly used today (and their components). They are differentiated as follows:

• Storage solution: This consists of one or several storage networks and at least one storage system.
• Storage network: This enables access to storage systems and the replication of data between storage systems.
• Storage system: a central instance that provides the other IT systems with storage space. A storage system also allows multiple IT systems to access the available storage space simultaneously.

Objective

The objective of this module is to show how central storage solutions can be planned, implemented, operated, and decommissioned in a secure manner.

Scoping and Modelling

Module SYS.1.8 Storage Solutions must be applied whenever central storage solutions are used. It can thus be applied to network-attached storage (NAS) systems, storage area networks (SAN) systems, hybrid storage, object storage, and cloud storage. However, the following must be taken into account:

• Network-attached storage (NAS) provides access to the storage systems using the protocols NFS (Network File System), AFP (Apple Filing Protocol), or CIFS (Common Internet File System), for example. The main application case is the provision of file server services. For NAS systems, the modules SYS.1.1 General Server and APP.3.3 File Servers must therefore be applied in addition to this module.
• Storage area networks (SAN) are generally created using a dedicated storage network between storage systems and connected IT systems. For SAN systems, it is therefore appropriate to consider module NET.1.1 Network Architecture and Design. Storage systems that can provide data via both NAS and SAN are often referred to as hybrid storage or combined storage systems (unified storage). For hybrid systems, the modules SYS.1.1 General Server and APP.3.3 File Servers must therefore be applied, as well. Module NET.1.1 Network Architecture and Design must also be appropriately considered.
• Object storage (often also referred to as object-based storage) allows for object-based access, in contrast to the traditional block-based and file-based access methods. A leading application is used to access object-based storage. Here, the application uses a specific interface (an application programming interface, or API) and its possible commands to access the object storage or access the storage directly via IP. For object-based storage solutions, module SYS.1.1 General Server must also be applied. In addition, security requirements must be taken into account that result from the use of web services. Web services are not considered in this module.
• In the context of further developments in the field of storage, the term "cloud storage" is becoming more and more established. This term refers to storage solutions as a basis for cloud services. In principle, the storage solution remains largely unchanged, but it accessed in a different way than with classic SAN or NAS architectures. Usually, this is implemented by means of a web service interface (via Representational State Transfer (REST) and Simple Object Access Protocol (SOAP)).

Backup devices connected to a storage system or a storage network are not addressed here; they are addressed in module OPS.1.2.2 Archiving. Design aspects of data backups are explained in module CON.3 Backup Concept.

A large number of user accounts can often access storage solutions. Therefore, storage solutions should be appropriately considered in roles and rights concepts. Requirements for this can be found in module ORP.4 Identity and Access Management.

If external service providers are used to operate a storage solution, the requirements of module OPS.2.1 Outsourcing for Customers must be taken into consideration separately.

Useful Resources

The International Organization for Standardization (ISO) provides guidelines for securing storage solutions in the standard ISO/IEC 27040:2015, “Information Technology – Security Techniques – Storage Security”.

The Information Security Forum (ISF) provides guidelines for securing storage solutions in section SY1.4 ("Network Storage Systems") of “The Standard of Good Practice for Information Security”.

Introduction

The term “general client” refers to an IT system running any operating system that allows the separation of users and is not used to provide server services. On a client, it should be possible to configure at least an administrator environment and a user environment. The underlying IT system generally has drives and connection options for external and removable storage media, additional interfaces for data exchange, and other peripheral devices. An IT system of this kind is typically integrated into a client-server network. The IT system can, for example, be a PC with or without a hard drive, a mobile or stationary device, a Linux workstation, or an Apple Mac.

Objective

The objective of this module is to protect information that is created, read, processed, stored, or sent on any type of client, regardless of the operating system used.

Scoping and Modelling

SYS.2.1 General Client must be applied to all clients regardless of the specific operating system at hand.

As a rule, clients run in an operating system that requires its own security safeguards. For common client operating systems, specific modules are available in the SYS.2 Desktop Systems layer that are based on this module and also need to be applied. If there is no specific module for the clients used in a particular case, the requirements of this module must be adapted and extended appropriately. Security recommendations for mobile devices with fixed operating systems (such as smartphones or tablets) can be found in the SYS.3 Mobile Devices layer.

If a client has further interfaces for exchanging data (e.g. USB, Bluetooth, LAN, or WLAN), they need to be protected in line with the respective organisation’s security policies as described in the corresponding modules. Requirements for this can be found in SYS.4.5 Removable Media or NET.2.2 WLAN Usage, for example.

The requirements of module CON.3 Backup Concept must also be taken into account for clients. Since clients are often threatened by malware, the requirements of OPS.1.1.4 Protection Against Malware for clients must be taken into account.

Useful Resources

No further information is available for module SYS.2.1 General Client.

Introduction

In Windows 8, Microsoft presented a further development of its client operating system and the features and components introduced with it. One new feature of Windows 8 (or 8.1) is a user interface that is geared towards the use of mobile devices with touch screens. This brings with it a new operating concept for applications: In addition to classic desktop applications, Microsoft has provided for a class of mobile applications, or simply "apps". These apps are primarily designed to be controlled by touch. In addition, they can perform display functions as “tiles” on screen. Some applications—above all Internet Explorer, which comes with Windows 8.1—are available in two versions: the familiar desktop version and a new app version. Windows 10 is a successor to Windows 8.1. Microsoft's extended support for Windows 8.1 is scheduled to end on 10 January 2023.

Objective

The objective of this module is to protect information that is processed in Windows 8.1, including by corresponding clients.

Scoping and Modelling

Module SYS.2.2.2 Windows 8.1 Clients must be applied to all client systems on which the Microsoft Windows 8.1 operating system is used.

This module describes requirements specific to Windows 8.1. The requirements of module SYS.2.1 General Client must also be met. For application programs used on Windows clients, the requirements of the corresponding modules must be fulfilled—for example, from APP.1.1 Office Products or APP.1.2 Web Browsers. When being used in a Windows domain, the requirements of corresponding modules such as APP.2.2 Active Directory must be met.

Useful Resources

Microsoft provides the following additional information about Windows 8.1:

• Secure Windows (for Windows 8/8.1, but largely also applicable to Windows Server 2012 / 2012 R2): https://technet.microsoft.com/en-us/library/hh832031.aspx
• Security and Protection: https://technet.microsoft.com/en-us/library/hh831778.aspx
• Security Auditing Overview: https://technet.microsoft.com/en-us/library/dn319078.aspx
• List of security events on Windows 8.1 and Windows Server 2012: https://www.microsoft.com/en-us/download/confirmation.aspx?id=50034
• Configuring Additional LSA Protection: https://docs.microsoft.com/de-de/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection

Introduction

In Windows 10, Microsoft has adapted its Windows client operating system to a new corporate strategy. In particular, the basic philosophy has also changed, moving away from the previous principle of the “local operating system” to “Windows as a Service”. This means that in addition to its previous functions, the operating system contains further (in particular, cloud-based) applications and is therefore dependent on close integration with Microsoft's server infrastructure. Important new aspects compared to previous Windows versions above all include the integral and partly uncontrollable exchange of data between clients and Microsoft's infrastructure, as well as the increasing outsourcing of security-critical core components of Windows infrastructures (e.g. authentication) to the cloud. These new features should definitely be taken into account before using Windows 10.

Objective

The objective of this module to protect information processed in Windows 10, including on corresponding clients.

Scoping and Modelling

SYS.2.2.3 Windows 10 Clients must be applied to all clients on which the Microsoft Windows 10 operating system is used.

This module includes specific requirements to be considered and met in order to securely operate clients under Windows 10 in addition to the requirements contained in module SYS.2.1 General Client. For application programs used on Windows clients, the requirements of the corresponding modules must be fulfilled—for example, from APP.1.1 Office Products or APP.1.2 Web Browsers. In use cases located in a Windows domain, the requirements of corresponding modules such as APP.2.2 Active Directory must be met.

Useful Resources

As part of the project “SiSyPHuS Win10 (Study on System Integrity, Logging, Hardening, and Security-Relevant Functionality in Windows 10)”, the BSI provides an analysis of the security functions of Windows 10 and appropriate hardening recommendations: https://www.bsi.bund.de/DE/Themen/Cyber-Sicherheit/Empfehlungen/SiSyPHuS_Win10/SiSyPHuS_node.html

Microsoft provides the following additional information about Windows 10:

• Configuring Additional LSA Protection: https://docs.microsoft.com/de-de/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection
• How Windows Defender Credential Guard Works: https://docs.microsoft.com/de-de/windows/access-protection/credential-guard/credential-guard-requirements
• Windows Defender Application Control and Virtualization-Based Protection of Code Integrity:https://technet.microsoft.com/de-de/library/dn986865.aspx

Introduction

In addition to Windows, Linux- and (less frequently) Unix-based operating systems are being installed on more and more clients. Examples of classic Unix systems include the BSD series (FreeBSD, OpenBSD, and NetBSD), Solaris, and AIX. Linux, on the other hand, constitutes a functional rather than a classic Unix system because the Linux kernel is not based on the original source code from which the various Unix derivatives have evolved. Since the configuration and operation of Linux and Unix clients are similar, Linux and Unix are jointly referred to in this module as "Unix clients" and "Unix-like".

Linux is free software that is developed by the open-source community. This means anyone can use, copy, distribute, or modify it. In addition, there are providers that consolidate and maintain distributions comprising the Linux kernel and various software components while offering additional services. Derivatives of the distributions Debian, Red Hat Enterprise Linux, or SUSE Linux Enterprise are often used. In addition, there are Linux distributions that are tailored to special purposes and devices. These include, for example, Qubes OS, which attempts to achieve a high level of security through virtualisation; LibreElec, for the use of home theatre PCs; or Kali Linux, a distribution specialised in security, computer forensics, and penetration testing. Clients can also boot live distributions without changing the operating systems installed on the clients. The market share of the Linux operating system on clients has increased in recent years. In special operational environments, various derivatives of "classic" Unix systems continue to be used. Typically, an IT system of this type is networked and operated as a client in a client-server network.

As the number of pre-selected software packages in standard installations of common Linux distributions or Unix derivatives increases, so does the number of potential targets for attacks. At the same time, however, Unix-like operating systems also offer extensive protection mechanisms.

Objective

The objective of this module is to protect information created, processed, stored, or sent on Linux and Unix clients. The requirements of the module mainly address Linux clients, but can be adapted generally to Unix clients.

Scoping and Modelling

Module SYS.2.3 Linux and Unix Clients must be applied to all clients on which Linux or Unix-based operating systems are used.

This module includes fundamental requirements for operating Unix-like clients. It substantiates the aspects addressed in module SYS.2.1 General Client and adds specific features of Unix systems. Although Apple's macOS is a Unix-like operating system, it is not addressed in this module. Related recommendations can be found in module SYS.2.4 macOS Clients.

This module only includes the actual operating system that is usually involved in a basic installation of a distribution. Software based on this, such as e-mail clients or office software, is not considered in this module. Corresponding requirements can be found, for example, in the modules of layer APP.1 Client Applications of the IT-Grundschutz Compendium.

This client module requires that, in addition to the administrator, only one unchanged person with an interactive user account be permanently active. Clients used by several persons consecutively or simultaneously require additional safeguards that are not addressed within the framework of this module.

Useful Resources

No further information is available for module SYS.2.3 Linux and Unix Clients.

Introduction

macOS is a client operating system from Apple. It is based on Darwin, the free Unix operating system from Apple, which in turn is based on the open-source operating system FreeBSD. macOS consists mainly of Darwin and the proprietary graphical user interface Aqua, as well as other applications and services. According to Apple's licensing conditions, macOS may only be installed on Apple IT systems ("Macs"). For this reason, features of these systems are also part of this module.

Objective

The objective of this module is to protect information which is processed on or transmitted by IT systems running macOS. To achieve this, macOS IT systems must appropriately secured.

Scoping and Modelling

Module SYS.2.4 macOS Clients must be applied to all client systems on which the Apple macOS operating system is used.

This module focuses on protecting a Mac running macOS that is operated as a stand-alone system or a client in a client/server network. It therefore supplements the general aspects of module SYS.2.1 General Client, which also applies here. The possible use of macOS as a server operating system is not considered in this module. For professional settings, the Profile Manager tool and mobile device management service offer the option to manage Macs remotely. These solutions offer extended configuration and administration functions which are not covered in this module. The relevant security aspects are covered in module SYS.3.2.2 Mobile Device Management (MDM). It should also be noted that the Apple operating systems macOS (for Macs), iOS (for iPhones), and iPadOS (for iPads) are closely interlinked. Module SYS.3.2.3 iOS (for Enterprise) should also be considered if iOS or iPadOS devices are used in addition to macOS.

Useful resources

The National Institute of Standards and Technology (NIST) has published the document "SP 800-179 Rev. 1 (DRAFT): Guide to Securing Apple macOS 10.12 Systems for IT Professionals: A NIST Security Configuration Checklist" (October 2018).

Introduction

A laptop (also referred to as a notebook) is a PC designed for mobile use. It has a compact design, peripheral devices such as a keyboard and monitor, batteries that make it temporarily independent from an external power supply and, in many cases, hardware components specially designed for mobile use. Laptops are widely used in most organisations and often replace the traditional desktop PC.

Laptops are usually operated with common desktop operating systems such as Microsoft Windows, Apple macOS, or Linux. Today, the boundaries between laptops and tablets and similar devices have become fluid. Some tablets have desktop operating systems such as Windows 10, and keyboard accessories are also available for mobile devices such as iPads, which make it possible to use them like laptops.

Since laptops are often also used on the move, they are frequently not permanently connected to an organisation's LAN. Instead, they can usually connect to an organisation's network using a virtual private network (VPN), including via the public Internet. The infrastructure in a traditional office environment, which features controllable environmental factors, a stable power supply and restricted areas, cannot be assumed for the mobile use of laptops.

Objective

The objective of this module is to allow organisations to use laptops securely and to make people aware of the specific threats to this type of device.

Scoping and Modelling

Module SYS.3.1 Laptops must be applied to all laptops subject to mobile or stationary use.

As with all IT systems, the operating systems and software components of laptops must be carefully selected and installed. The requirements to be met here depend on the operating system on a given laptop, which is why they are set out in the client-specific modules—for example, SYS.2.2.3 Windows 10 Clients, SYS 2.3 Linux and Unix Clients, or SYS.2.4 macOS Clients.

By the same token, requirements that apply to all types of clients are not part of this module. These can be found in module SYS.2.1 General Client.

Guidelines on setting up specific types of data connections—for example, in WLAN configurations (see NET.2.2 WLAN Usage) or via a VPN (see NET.3.3 VPN)—are not covered in this module.

Since laptops are often used outside an organisation for longer periods of time, data backups require special consideration. Further requirements for this are included in module CON.3 Backup Concept.

Useful Resources

No further information is available for module SYS.3.1 Laptops.

Introduction

Smartphones are IT systems designed for mobile use that have a customised interface operated via a large, usually touch-sensitive screen. In addition to telephony, smartphones combine features of a media player, personal information manager, and digital camera in one device while also offering users many other applications and functions, such as web browsing, e-mail access, and positioning (e.g. via GPS). They are equipped with interfaces for mobile networks, WLAN, Bluetooth, and NFC. In simple terms, tablets are smartphones with a large form factor that are usually not capable of making phone calls via mobile networks.

Objective

The objective of this module is to provide the persons in charge of security management and IT operations with information on the typical threats to smartphones and tablets and the requirements that should be met to avoid or eliminate these threats. Furthermore, it seeks to provide the persons in charge with approaches to drawing up configuration profiles in accordance with the protection needs at hand. These configuration profiles may be distributed and managed using a central infrastructure and a mobile device management (MDM) system. However, given the large number of different mobile operating systems, it generally cannot be assumed that mobile devices can be integrated into an MDM system.

Scoping and Modelling

The SYS.3.2.1 General Smartphones and Tablets module must be applied to all smartphones and tablets used for work-related purposes.

This module does not deal with how specific operating systems of smartphones and tablets can be secured; this is explained in detail in the modules for the respective systems, e.g. SYS.3.2.3 iOS (for Enterprise) or SYS.3.2.4 Android. Security requirements for operating an MDM system are described in SYS.3.2.2 Mobile Device Management (MDM). Organisations that use smartphones and tablets should apply these modules accordingly in addition to the present module.

Like any other ordinary clients, smartphones are exposed to risks related to malware. They must be taken into account in an organisation's concept for protection against malware. Requirements for protection against malware can be found in module OPS.1.1.4 Protection Against Malware.

Smartphones and tablets usually offer the option to install mobile applications (apps). To avoid unnecessary security risks, the requirements of the APP.1.4 Mobile Applications (Apps) module must be taken into account. Other modules from the APP Applications layer, such as APP.1.2 Web Browser, may also be relevant.

Since smartphones usually have mobile phone functions, the relevant requirements of the SYS.3.3 Mobile Telephones module must be taken into account, as well.

Useful resources

The International Organization for Standardization (ISO) provides guidelines for the use of mobile devices in the standard ISO/IEC 27001:2013, especially in annex A, A.6.2 ("Mobile Devices and Teleworking").

The Information Security Forum (ISF) offers guidelines for the use of mobile devices in "The Standard of Good Practice for Information Security", especially in Area PA2 ("Mobile Computing").

The National Institute of Standards and Technology (NIST) has published the following documents in the area of mobile devices:

• Guidelines for Managing the Security of Mobile Devices in the Enterprise, NIST Special Publication 800-124, Revision 1, June 2013
• Security and Privacy Controls for Federal Information Systems and Organizations, NIST Special Publication 800-53, Revision 4, April 2013
• Securing Electronic Health Records on Mobile Devices: NIST Special Publication 1800-1d, Draft, July 2015

Introduction

For many employees, smartphones, tablets and phablets have become an indispensable part of their work. However, IT departments are having to provide ever greater numbers of such devices in many different designs while also ensuring adequate security. In addition, mobile devices are exposed to particular risks and their administration differs in fundamental respects from other IT systems.

Consequently, a mobile device management (MDM) system is essential for regulated and secure operation of these devices, particularly in organisations with a large number of smartphones, tablets, and phablets. With corresponding MDM software, end devices can be managed centrally, security regulations can be implemented, and emergency actions can be triggered. An MDM system thus ensures a consistent (or at least comparable) security standard on all devices administered.

Objective

This module shows how organisations can secure the use of mobile devices via an MDM system and provides related operating information.

Scoping and Modelling

The SYS.3.2.2 Mobile Device Management (MDM) module must be applied to any information domain in which mobile devices are administered using a mobile device management (MDM) system.

For the purposes of this module, mobile devices are smartphones, tablets, and phablets on which mobile operating systems such as Android or iOS are installed. The security requirements of smartphones, tablets, laptops, and tablets with desktop operating systems are described in other modules of the SYS IT Systems layer. The requirements of SYS.3.2.1 General Smartphones and Tablets must also be taken into account when using an MDM system. Ways to secure specific smartphones, tablets, and phablets from different manufacturers are explained in detail in the modules for the respective operating systems, e.g. SYS.3.2.3 iOS (for Enterprise) or SYS.3.2.4 Android.

An access control policy SHOULD be drawn up for an MDM system. Requirements for this can be found in module ORP.4 Identity and Access Management. One of the most fundamental tasks of an MDM system is the administration of mobile devices. General security requirements for administration are contained in OPS.1.1.2 Proper IT Administration.

Finally, this module does not deal with aspects of “bring your own device” (BYOD) scenarios.

Useful resources

In its publications on cyber security, the BSI has published the document BSI-CS 052: “Mobile Device Management”. The BSI has also published the “Überblickspapier Consumerisation und BYOD” [Overview Paper on Consumerisation and BYOD], 2013.

The BSI has published “Mindeststandard des BSI für Mobile Device Management nach § 8 Absatz 1 Satz 1 BSIG – Version 1.0 vom 11.05.2017” [BSI Minimum Standard for Mobile Device Management in Accordance with Section 8 (1), Sentence 1 of BSIG – Version 1.0, 11 May 2017].

The National Institute of Standards and Technology (NIST) has published NIST Special Publication 800-124, "Guidelines for Managing the Security of Mobile Devices in the Enterprise", Revision 1, June 2013.

Introduction

Due to their modern and simple control concepts and high performance, smartphones and tablets are very common nowadays. This also includes the mobile iPhone and iPad devices produced by Apple, which run on the operating systems iOS and iPadOS. Since iPadOS is based on iOS, both are referred to as “iOS” in this module for simplicity. At present, the two operating systems mainly have functional differences that take into account the different form factor of the devices.

Originally, these devices were designed for private use. Due to the reshaping of infrastructures and the ways in which information is collected and processed, however, they are also being used more and more frequently in professional environments, where they are even replacing laptops in some cases.

Through the integration of business functions, iOS has (from version 4) been gradually extended for use in companies and public authorities, and functions have been integrated for management from an organisation’s point of view. This includes the possibility of centralised device registration (Apple Business Manager) as well as options such as Single Sign-On (SSO).

Objective

The objective of this module is to show how devices that run on iOS (for Enterprise) can be used securely in organisations. Requirements are presented for the settings of iOS-based end devices, which can be distributed to devices in the form of configuration profiles. iOS configuration profiles include uniformly defined settings (e.g. for security policies or individual system aspects) for managing iOS-based devices in a standardised and centralised manner and configuring them automatically.

Scoping and Modelling

Module SYS.3.2.3 iOS (for Enterprise) must be applied to all smartphones and tablets running the Apple iOS operating system that are used for business purposes.

This module includes basic specifications to be observed and fulfilled when operating iOS-based devices that are integrated into an organisation’s processes. Requirements for integrating such devices into an organisation’s security or collaboration infrastructure are not the focus of this module. Through mobile device management (MDM), it is possible to manage devices centrally and roll out configuration profiles for specific user groups or intended purposes. Using an MDM system, safeguards can also be implemented in a uniform way. This module assumes that the iOS devices to be managed are integrated into an MDM infrastructure. If a small number of devices are managed, they can be used without MDM in exceptional cases for economic reasons. Requirements for the operation of MDM systems can be found in module SYS.3.2.2 Mobile Device Management (MDM). For smaller environments, Apple Configurator can also be used to roll out the requirements listed in this module to multiple end devices in a uniform way. General and overarching aspects of the operation of smartphones and tablets (regardless of the respective operating systems) can be found in module SYS.3.2.1 General Smartphones and Tablets and must also be implemented if iOS-based devices are used.

SYS.3.2.1 General Smartphones and Tablets also contains requirements for the use of biometric authentication mechanisms.

Useful Resources

In its publications on cyber security, the BSI has published the document BSI-CS 074, “iOS-Konfigurationsempfehlung auf Basis betriebssystemeigener Mittel für eine Nutzung mit erhöhter Sicherheit” [iOS Configuration Recommendation Based on the Operating System's Own Resources for Use with Enhanced Security], 2015.

In the context of the topics of this module, Apple provides additional support information, including:

• Apple Configurator: https://support.apple.com/de-de/apple-configurator
• Apple Security Updates: https://support.apple.com/en-us/HT1222
• Obsolete and vintage products: https://support.apple.com/de-de/HT201624
• Apple Business Manager: https://business.apple.com
• Support for companies and education institutions: https://www.apple.com/de/support/business-education/

Introduction

Google's Android operating system is commonly used on smartphones and tablets. Since version 4, Android has been gradually implementing protections for business use. For example, functions that enable organisations to administrate Android devices have been integrated. The number of administration policies supported by Android also increases with every new version, and there are manufacturer-specific expansions that enable additional policies.

Objective

The objective of this module is to provide information on typical threats related to Android and to show how Android-based devices can be used securely in organisations. Moreover, security policies can be created on the basis of the requirements stated in the module.

Scoping and Modelling

Module SYS.3.2.4 Android must be applied to all smartphones and tablets running the Google Android operating system that are used for business purposes.

This module includes basic specifications which must be observed and fulfilled when operating Android-based devices. General and comprehensive requirements for the operation of smartphones and tablets are not part of this module; they are covered in module SYS.3.2.1 General Smartphones and Tablets and must also be implemented for the use of Android-based devices. The requirements for the central administration of Android devices using an MDM system are also not part of this module. They are covered in module SYS.3.2.2 Mobile Device Management (MDM).

Useful Resources

No further information is available for module SYS.3.2.4 Android.

Introduction

The mobile phones considered in this module, which are also known as “feature phones” or "dumbphones", have fewer features than a smartphone, but offer more than just telephony functions. These mobile phones can also have a camera for videos and photos, an appointment calendar, e-mail programs, games, an MP3 player, or a radio receiver. "Classic" mobile phones do not usually have a touch screen or an operating system on which additional apps can be installed. The lack of these functions distinguishes a conventional mobile phone from a smartphone.

A mobile telephone is characterised by its internationally unambiguous serial number (International Mobile Equipment Identity, or IMEI). Mobile phone users are identified by their SIM cards, which are issued by mobile phone providers upon entry into a contract.

Objective

The aim of this module is to identify typical hazards that can occur when using mobile phones and to secure information stored on or transmitted by mobile phones.

Scoping and Modelling

Module SYS.3.3 Mobile Telephones must be applied to all mobile phones used for business purposes.

This module deals with general aspects of typical mobile phones, security aspects of telephony and messaging over mobile networks, and security aspects of using such devices. The module thus covers a wide range of different devices that can be connected to mobile telephone networks. Supplementary aspects that go beyond communication via a mobile network and handling related devices can be found in other modules of the IT-Grundschutz Compendium. Security requirements for smartphones and the operating systems used on them can be found in the SYS.3.2 Tablets and Smartphones module layer. Aspects of IT-based telephony are covered in module NET.4.2 VoIP. If the mobile phones under consideration use VPNs, module NET.3.3 VPN should also be considered. For smartphones or tablets, module SYS.3.2.1 General Smartphones and Tablets must be applied.

Useful Resources

The International Organization for Standardization (ISO) provides guidelines for the use of mobile devices in the standard ISO/IEC 27001:2013, especially in annex A, A.6.2.1 (Mobile Device Policy).

The National Institute of Standards and Technology (NIST) has published NIST Special Publication 800-53, “Security and Privacy Controls for Federal Information Systems and Organizations", Revision 4, December 2014.

Introduction

Today’s printers, copiers, and all-in-one devices are complex devices which, in addition to mechanical components, contain their own operating systems and provide server services and functions. Since these devices often process confidential information, they must be protected along with the rest of an organisation's print and scan infrastructure.

All-in-one devices are devices that offer several paper-processing functions, such as printing, copying, scanning, and sending and receiving fax documents.

For many business processes, paper is still used as an information medium today. This makes printers, copiers, and all-in-one devices important components of IT infrastructure. If such devices fail or falsified documents are printed out, this can sometimes affect critical processes and lead to considerable economic losses.

Objective

This module describes how printers, copiers, and all-in-one devices can be operated safely so that information is not extracted from these devices and the security of the rest of the internal IT infrastructure at hand is not impaired.

Scoping and Modelling

Module SYS.4.1. Printers, Copiers, and All-in-One Devices must be applied to each printer, copier, and all-in-one device in the information domain under consideration.

This module covers the security of printers, copiers, and all-in-one devices. Networked document scanners or those connected locally to IT systems are not explicitly considered. However, corresponding risks and requirements can be derived from those described for all-in-one devices. Similarly, networked fax machines are not considered separately. The risks and requirements cited for fax functions in this module therefore also apply to this type of device. In addition, the requirements of module NET.4.3 Fax Machines and Fax Servers should be considered.

Printers, copiers, and all-in-one devices are often connected to data networks so that multiple users can use them. In addition to wired connections, some devices can also be connected directly to a WLAN. Recommendations for this are included in sub-layer NET Networks and Communication modules of the IT-Grundschutz Compendium, such as in module NET.2.2 WLAN Usage.

Printers, copiers, and all-in-one devices often contain confidential information that remains on the devices after they are taken out of service. Leased equipment is often replaced after a predetermined period or frequency of use, depending on the specific contract in question. At the latest, they are returned when the corresponding leasing contract expires. Paper and other equipment may also contain confidential information. Before these devices and resources are discarded, exchanged, repaired, or returned, all sensitive information must be deleted from them. Recommendations in this regard are not covered in this module. They can be found in module CON.6 Deleting and Destroying Data and Devices.

Print servers are systems with print queues, print job management features, and possible other functions, such as driver distribution or secure printing. For each print server, the general and operating-system-specific security requirements for servers must be met. Instead of being covered here, these requirements are described in module SYS.1.1 General Server and the respective operating-system-specific server modules.

An essential focus in securing printers, copiers, and all-in-one devices lies on regularly updating their software to close software vulnerabilities. This module does not deal with this aspect, however. Corresponding requirements are included in module OPS.1.1.3 Patch and Change Management.

Useful Resources

Within the framework of the Alliance for Cyber Security, the BSI offers recommendations in “Drucker und Multifunktionsgeräte im Netzwerk BSI-CS 015” [Printers and All-in-One Devices in the Network, BSI-CS 015] and “Sichere Passwörter in Embedded Devices (BSI-CS 069)” [Secure Passwords in Embedded Devices, BSI-CS 069]. In-depth information on printers, copiers, and all-in-one devices can also be found in the white paper “Datenschutz und Sicherheit in Druckinfrastrukturen” [Data Protection and Security in Printing Infrastructures], which was published by the ACS partner company mc² management consulting GmbH.

The National Institute of Standards and Technology (NIST) describes requirements for output devices such as printers, copiers, and all-in-one devices in Special Publication 800-53, “Security and Privacy Controls for Federal Information Systems and Organizations”, especially in section PE-5, "Access Control for Output Devices”.

Introduction

Embedded systems are information-processing systems that are integrated into a larger system or product. They take over control, regulation, and data processing tasks and are often not directly perceived by the user. Embedded systems can be found both in the field of advanced technology—in the aerospace, medical engineering, telecommunications, and automotive engineering sectors, for example—and in consumer and household appliances.

An embedded system consists of software and hardware that forms a functional unit and performs only one defined task. The software of embedded systems is referred to as firmware and is, in most cases, stored on flash memory, EPROM, EEPROM, or ROM. It cannot be exchanged by the user or can only be exchanged with special means and/or functions. It essentially consists of a boot loader, an operating system, and an application. Specialised systems can also run without an operating system. Although embedded systems are specialised devices, they are universal computers in contrast to pure hardware implementations (ASIC). Different CPU architectures or flexible, highly integrated field programmable gate array (FPGA) components can be used as platforms.

Embedded systems either have no user interface or use special peripheral equipment, such as functional keys, rotary switches, or displays designed for the respective intended purpose. The scope of output units ranges from a simple signal lamp to LCDs and complex cockpit displays. Embedded systems frequently communicate via data buses which are networked heterogeneously in complex systems. In addition, peripheral components such as sensors and actuators can also be connected via several different and multi-channel input/output ports. Some types of embedded systems also have a web interface through which they can be configured via a browser.

Objective

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

Scoping and Modelling

Module SYS.4.3 Embedded Systems must always be applied when embedded systems are used. It must be applied to all the embedded systems in the information domain under consideration.

This module deals with embedded systems in general. It is applicable to a wide range of different embedded systems. Dedicated security properties, such as those of operating and display systems or specific hardware and software architectures, are not described in more detail here. The security aspects of embedded systems used in industrial control systems are also not specifically addressed. In these areas, the modules of the IND Industrial IT layer should be consulted in addition to the present module. Specific security aspects of IoT systems are not part of this module either. IoT systems are networked devices or objects with additional smart functions that (unlike embedded systems) are not integrated into a larger system or product. Due to their wireless connections to data networks, such systems are subject to different security requirements. These are covered in SYS.4.4 General IoT Devices.

Chip cards are a special application of embedded systems. These cards are usually equipped with a processor, random access memory, and I/O interfaces. This module covers the general security aspects relating to chip cards, but not the specific aspects.

Useful Resources

In its document “ICS Security Compendium – Test Recommendations and Requirements for Component Suppliers”, the BSI provides assistance in testing ICS components and presents measures to avoid and detect vulnerabilities.

Introduction

In contrast to classic end devices, those with Internet of Things (IoT) functions are networked devices or objects that have additional “smart” functions. IoT devices are usually connected wirelessly to data networks. Most of these devices can access information on the Internet and be reached via the same means. As a consequence, they may have effects on the information security of the entire corresponding information domain.

IoT devices such as smartwatches or other wearables can enter organisations when they are worn by employees or visitors. However, many organisations also procure and operate IoT devices themselves—including detectors for fire, gas, and other hazards; coffee machines; or building management elements such as cameras and HVAC (heating, ventilation and air conditioning) systems.

In general, a differentiation can be made between IoT devices that may be addressed directly and IoT devices that require a central controller. Devices that can be addressed directly are usually connected to a LAN with their own IP address and can act autonomously, or are managed by a central control unit. There are also IoT devices that communicate only directly with controllers (e.g. via radio networks such as Bluetooth or ZigBee) and thus do not connect directly to existing data networks.

Objective

The objective of this module is to secure IoT devices such that they impair neither the information security of one’s own organisation nor the security of external parties. As a consequence, both unauthorised data leaks and any manipulation of these devices should be avoided, especially with regard to attacks through third parties.

Scoping and Modelling

Module SYS.4.4 General IoT Devices must be applied to every device with functions related to the Internet of Things (IoT).

This module addresses IoT devices in general and should thus be applicable to a wide range of such devices. Dedicated security properties, such as those of operating and display systems or specific hardware and software architectures, are not described in more detail here.

Depending on the characteristics of the IoT devices, their interfaces to industrial control systems (ICS systems) or embedded systems may be fluid. Requirements for devices used in production and manufacturing can be found in the modules of the IND Industrial IT layer.

Embedded systems, on the other hand, are information-processing systems which are integrated into a larger system or product; assume control, regulation, and data processing tasks there; and are often not recognised directly by the user. Module SYS.4.3 Embedded Systems must be implemented for these systems.

Requirements for the radio links often used in connection with IoT devices can be found in the modules of the layer NET.2 Radio Networks.

The IoT devices used in the information domain under consideration must also be taken into account in identity and access management. To that end, module ORP.4 Identity and Access Management should be implemented.

Useful resources

In the document “Security of IP-Based Surveillance Cameras”, the BSI provides an overview of the basic best practices for the secure operation of IP-based surveillance cameras.

The United States Department of Homeland Security (DHS) has published strategic principles for the security of IoT devices.

The Open Web Application Security Project (OWASP) Foundation offers best practices for the security of IoT devices.

Introduction

Removable media are often used to transport, store, or access data while on the move. Removable media include external hard drives, CD-ROMs, DVDs, memory cards, magnetic tapes, and USB pen drives.

Storage media can be classified according to whether they are read-only, write-once, or rewritable. There are also differences in the type of data storage (analogue or digital), the processing options available, and the form factor of media. There are removable storage media (e.g. built-in hard disks) and external data storage media (e.g. USB pen drives), for example.

Objective

This module is designed to show how removable media can be used in a secure manner. It also describes how to prevent the unintentional disclosure of information via removable media.

Scoping and Modelling

The SYS.4.5 Removable Media module must be applied to all removable media in the information domain under consideration.

This module deals with the security properties of removable media. The protection of the IT systems to which removable media can be connected is not covered in this module. Recommendations for this can be found in the modules SYS.1.1 General Server or SYS.2.1 General Client, as well as in the operating-system-specific modules.

Removable media store data electronically, magnetically, or in other ways that are not directly perceptible. They do not process any data themselves. The requirements for devices that are capable of this, such as smartphones and tablets, are listed in SYS.3.2.1 General Smartphones and Tablets. Removable media do not include cloud storage. Requirements for cloud environments can be found in the OPS.2.2 Cloud Usage module.

Removable media can be exchanged in person or by conventional post. The secure exchange of digital and analogue storage media to transmit information between different communication partners and IT systems is not considered in this module. The requirements of module CON.9 Information Exchange must be met in this regard.

Useful Resources

The International Organization for Standardization describes how removable media can be used securely in standard ISO/IEC 27001:2013, section A.8.3.