APP.6 General Software

Before an organisation introduces (new) software, it MUST determine the following:

• What the software will be used for and what information it will process
• How users should be involved in the requirements analysis and supported in the implementation process
• How the software will be connected to other applications and IT systems, and via which interfaces
• The IT systems on which the software is to be run and what resources are required
• Whether the organisation will become dependent on a manufacturer if it uses the software in question

Security aspects MUST be considered in this process. In addition, the organisation MUST clarify and define the responsibilities for technical supervision, approval, and operational administration in advance. The responsibilities MUST be documented and updated as needed.

Based on the results of corresponding planning, the software requirements at hand MUST be collated in a requirements catalogue. The requirements catalogue MUST include the basic functional requirements. In addition, the non-functional requirements, and particularly the security requirements, MUST be integrated into the requirements catalogue.

In doing so, the requirements of both the Process Owners and the IT Operation Department MUST be taken into account. In particular, the legal requirements arising from the context of the data to be processed MUST also be considered.

The requirements catalogue SHOULD be finalised in consultation with all the departments involved.

During the procurement process, suitable software MUST be selected based on the requirements catalogue. The selected software MUST be procured from a trusted source. The trusted source SHOULD provide a means of verifying the integrity of the software.

Furthermore, the software SHOULD be procured with a suitable maintenance contract or a comparable commitment from the manufacturer or software provider. In particular, these contracts or commitments SHOULD guarantee that any vulnerabilities or security flaws that emerge in the software will be promptly remedied throughout the period of use.

The installation and configuration of software MUST be regulated by the IT Operation Department in order to ensure the following:

• The software is installed and executed with the smallest functional scope necessary
• The software is executed with the fewest authorisations possible
• Settings pertaining to the processing of personal data are configured to store as little data as possible
• All relevant security updates and patches are installed before the software is used productively

Dependent components (including runtime environments, libraries, interfaces, and other programs) MUST also be considered. In coordination with the Process Owner, the IT Operation Department MUST determine who is allowed to install the software and how. Ideally, software SHOULD always be installed centrally by the IT Operation Department. If it is necessary to install software (or parts thereof) manually, the IT Operation Department MUST create installation instructions that clearly regulate the intermediate steps required for installation and what configurations are to be made.

In addition, the IT Operation Department MUST define how the integrity of installation files is to be checked. If digital signatures or checksums are available for an installation package, they MUST be used to verify its integrity.

If required, the IT Operation Department SHOULD define a secure default configuration for the software in question. The default configuration SHOULD be documented.

Software MUST be installed in line with the applicable rules on installations in IT systems. Unmodified versions of the approved software MUST be used.

If there is any deviation from these instructions, this MUST be approved by the Supervisor and IT Operation Department and documented accordingly.

An organisation SHOULD consider the following security requirements in the requirements catalogue for the software at hand:

• The software SHOULD include general security functions that are required in the application context in question, such as logging and authentication.
• The software SHOULD make it possible to use the hardening functions of the operational environment. In particular, the hardening capabilities of the intended operating system and execution environment SHOULD be considered.
• If the software transmits information over unsecured public networks, it SHOULD use secure encryption functions that reflect the current state of the art. In addition, the transmitted data SHOULD be checked for integrity using checksums or digital signatures.
• If the software uses certificates, it SHOULD offer the option to display the certificates transparently. It SHOULD also be possible to block certificates, withdraw trust from them, or add an organisation's own certificates.

The functions of the software that pertain to the security requirements at hand SHOULD be used in actual operations.

The requirements catalogue SHOULD be used to evaluate the products available on the market. These products SHOULD be compared using an assessment scale. Whether the products on the short list actually meet the requirements of the organisation in question SHOULD then be examined. If there are several product alternatives, user acceptance and the additional effort required for aspects such as training or migration SHOULD also be considered. The Process Owners SHOULD select a suitable software product together with the IT Operation Department based on the assessments and test results.

The IT Operation Department SHOULD ensure the availability of installation files so that the installation process can be reproduced. In this regard, the IT Operation Department SHOULD:

• Secure the installation files appropriately
• Ensure that the installation files will continue to be available from the source in question (e.g. the corresponding app store)

In addition, it SHOULD be ensured that software can be configured in a reproducible manner. For this purpose, the configuration files SHOULD be backed up. Alternatively, there SHOULD be suitable documentation on how the software is configured.

This regulation SHOULD be integrated into the organisation's data backup concept.

Software SHOULD be inventoried. An inventory SHOULD document the systems on which software is used and under which licence. If necessary, the security-relevant settings SHOULD also be documented. Software SHOULD only be used with licences that correspond to the intended use and the respective contractual provisions. Each licence SHOULD cover the entire intended period of use of the corresponding software.

If there is a deviation from a default configuration, this SHOULD be documented. The inventory SHOULD be updated by the IT Operation Department as necessary, especially when software is installed.

The inventory SHOULD be structured to provide a quick overview of the necessary details in the event of a security incident.

An organisation SHOULD establish a security policy that summarises the regulations that determine how software is to be used and operated. The policy SHOULD be known to all the relevant people in charge and employees of the organisation and SHOULD represent the basis for their actions and work. In terms of content, the policy SHOULD also include a manual that explains how software should be used and managed.

Employee compliance with the policy SHOULD be checked regularly and at random. The policy SHOULD be updated at regular intervals.

Plug-ins and extensions SHOULD be restricted to those that are absolutely necessary. If extensions are used, the corresponding software SHOULD offer the option to configure and disable them.

If software is to be decommissioned, the IT Operation Department SHOULD regulate this procedure with the Process Owners. The process for informing users in this regard SHOULD also be regulated. In the process, the matter of whether the functional requirements in question still apply (e.g. for business processes) SHOULD be clarified. If they do, the manner in which the required functions of the software to be decommissioned will continue to be available SHOULD be regulated.

If software is uninstalled, all files created and no longer needed SHOULD be removed. All entries in system files that were made for the software and are no longer needed SHOULD be reversed.

When purchasing software, it SHOULD be determined whether the assurances of the manufacturer, distributor, and provider regarding the security functions implemented can be considered to be sufficiently trustworthy. If this is not the case, certification of the application (e.g. according to Common Criteria) SHOULD be factored into the selection process. If several products are available, security certificates SHOULD be considered, particularly if the evaluated scope of functions includes the minimum functions (or most of them) and the strength of the corresponding mechanisms matches the protection needs at hand.