APP.6 General Software

Description

Introduction

This building block encompasses all software under the term General Software, regardless of whether it is a word processor, an operating system, a mobile communication app, a custom-developed application, or a distributed content management system.

In general, all software goes through a lifecycle that encompasses planning, requirements gathering, procurement, software testing including release, installation in the production environment, training, operation, updates and change management, and decommissioning including uninstallation. This lifecycle can vary depending on the application context, so that for individual applications additional individual intermediate steps may be added, and the scope of individual steps also varies.

However, recurring information security aspects arise in the listed intermediate steps that can be applied to any type of software.

Objective

This building block identifies what security requirements must be fulfilled so that general software can be used securely throughout its entire lifecycle. The overarching objective is to protect the software and the information processed with it.

Scope and Modeling

The building block APP.6 General Software must fundamentally be applied to every software deployed in the information domain. Exceptions are operating systems running on closed systems such as IoT devices, routers, printers, or embedded systems. Software is often delivered bundled (e.g. office suites or operating systems with extensively integrated built-in tools) or extended with plug-ins, add-ons, or comparable items. In such cases, the building block can be applied once to the entire software bundle.

This building block addresses only standardized and generic procedures in the software lifecycle. No specific recommendations are described for how software is to be individually configured and how it is to be secured on the IT systems in use by individual protection mechanisms. For this purpose, the specific building blocks of the APP layer must be applied.

The intermediate steps of release (including software testing) and patch and change management are not addressed in this building block but in the building blocks OPS.1.1.6 Software Tests and Releases and OPS.1.1.3 Patch and Change Management.

If requirements for software cannot be fulfilled by a finished software product through, for example, configuration adjustment, but a custom-developed product is needed, then the building block APP.7 Development of Custom Software must be additionally modeled.

Software and the associated data must often also be available in emergency situations. Initial considerations on this are shown in the building block DER.4 Emergency Management.

Threat Landscape

Since IT-Grundschutz building blocks cannot address individual information domains, typical scenarios are used to represent the threat landscape. The following specific threats and vulnerabilities are of particular relevance for the building block APP.6 General Software.

Inappropriate Selection of Software

For many application purposes and deployment options, a wide variety of software solutions are available on the market. If an inappropriate software that does not meet the institution’s requirements is selected, operations can be significantly disrupted. File formats might not be compatible with already-deployed programs, or new products might have insufficient functionality. This can lead to performance losses, disruptions, or errors in business processes.

In particular, if the software does not meet the institution’s security requirements, the data processed by the software could be disclosed or manipulated, e.g. if login functions of applications have not been designed for the planned deployment environment in an open data network.

Disclosure of Sensitive Information Through Incorrect Configuration

If software is incorrectly configured, sensitive information can be unintentionally disclosed, e.g. if unnecessary functions are still enabled, such as cloud backup functions that unintentionally synchronize data into a cloud. This could allow sensitive data to be viewed and disclosed by unauthorized third parties.

This can lead to financial losses or damage the reputation of an institution. Additionally, the institution could also be in violation of applicable law, e.g. if personal data is disclosed.

Procurement of Software from Unreliable Sources

If software is procured from unreliable sources, it is not ensured that an unaltered original version of the software is being used. Instead, a defective or compromised version of the software may have been obtained. This also applies to extensions such as plug-ins or add-ons. If compromised software is installed, malicious code can be distributed within the institution. In addition, it is possible that the software does not function as intended. Furthermore, the integrity and availability of IT systems can be impaired.

Security Vulnerabilities Through Inadequate Maintenance

Security vulnerabilities and software weaknesses can in principle arise throughout the entire usage period of software. This can endanger the information security of the data processed with the software, e.g. by allowing login functions to be bypassed or encryption to be broken.

Security vulnerabilities and weaknesses in particular cannot be remedied in a timely manner if no appropriate maintenance contract has been concluded with the manufacturing or providing company, or if the software is simply used beyond its maintenance period. Violations of licensing terms can also lead to, e.g., (automatic) update mechanisms being deactivated, so that the software is no longer maintained.

Data Loss Through Incorrect Use of Software

Through incorrectly used software, employees can accidentally delete data or modify it in such a way that it becomes unusable. This can block entire business processes. Even if encryption functions are used incorrectly, the data may still be present but can no longer be decrypted. In this case, the data can no longer be recovered or can only be recovered with significantly greater effort.

Insufficient Resources for Software Execution

If IT systems have insufficient resources to run the software, this can significantly increase processing and response times for users. In the worst case, the software cannot be executed on such a system. This can significantly disrupt business processes.

Disregard of User Requirements

Regardless of whether software fulfills functional requirements, it may not be accepted by users if, for example, it is cumbersome and complicated to operate. This can in turn lead to users falling back on alternative forms of processing and repurposing other IT systems or software. For example, personal IT systems could be used without coordination with IT Operations. These alternative forms of processing rarely arise with information security in mind and thus present an elevated risk.

Requirements

The following are the specific requirements of the building block APP.6 General Software. The Information Security Officer (ISO) is responsible for ensuring that all requirements are fulfilled and verified in accordance with the established security concept. The ISO MUST always be involved in strategic decisions.

Further roles are defined in the IT-Grundschutz Compendium. They should be filled insofar as this is reasonable and appropriate.

Exactly one role should be Primarily responsible. Beyond that, there may be Additional responsibilities. If one of these additional roles is primarily responsible for fulfilling a requirement, this role is listed in square brackets after the requirement heading. The use of singular or plural says nothing about how many people should fill these roles.

Basic Requirements

The following requirements MUST be fulfilled with priority for this building block.

APP.6.A1 Planning Software Deployment (B) [Subject Matter Experts]

Before an institution introduces (new) software, it MUST decide:

• what the software will be used for and what information will be processed with it,
• how users will be involved in requirements gathering and supported during the introduction,
• how the software will be connected to other applications and IT systems via which interfaces,
• on which IT systems the software is to run and what resources are required to run the software, and
• whether the institution will become dependent on a manufacturer or supplier by using this software.

Security aspects MUST already be considered here. Additionally, the institution MUST clarify and define responsibilities for subject matter support, release, and operational administration in advance. The responsibilities MUST be documented and updated as needed.

APP.6.A2 Creation of a Requirements Catalog for Software (B) [Subject Matter Experts]

Based on the results of the planning, requirements for the software MUST be gathered in a requirements catalog. The requirements catalog MUST encompass the fundamental functional requirements. Furthermore, the non-functional requirements and in particular the security requirements MUST be integrated into the requirements catalog.

Both the requirements from subject matter experts and from IT Operations MUST be considered here. In particular, the legal requirements arising from the context of the data to be processed MUST also be considered.

The completed requirements catalog SHOULD be coordinated with all affected specialist departments.

APP.6.A3 Secure Procurement of Software (B) [Procurement Office]

When software is procured, suitable software MUST be selected based on the requirements catalog. The selected software MUST be procured from trustworthy sources. The trustworthy source SHOULD provide a means to check the integrity of the software.

Furthermore, the software SHOULD be procured with an appropriate maintenance contract or comparable commitment from the manufacturing or providing company. These contracts or commitments SHOULD in particular guarantee that arising security vulnerabilities and weaknesses in the software are remedied in a timely manner throughout the entire usage period.

APP.6.A4 Rules for the Installation and Configuration of Software (B) [Subject Matter Experts]

The installation and configuration of the software MUST be regulated by IT Operations such that:

• the software is only installed and operated with the minimum necessary functional scope,
• the software is executed with the minimum possible permissions,
• the most data-minimizing settings (with regard to the processing of personal data) are configured, and
• all relevant security updates and patches are installed before the software is deployed in production.

Dependent components (including runtime environments, libraries, interfaces, and other programs) MUST also be considered here. IT Operations MUST define, in coordination with subject matter experts, who may install the software and how. Ideally, software SHOULD always be installed centrally by IT Operations. If it is necessary for the software to be (partially) installed manually, IT Operations MUST create an installation guide clearly specifying which intermediate steps are to be performed for installation and which configurations are to be made.

Furthermore, IT Operations MUST regulate how the integrity of the installation files is verified. If digital signatures or checksums are available for an installation package, these MUST be used to verify the integrity.

If required, IT Operations SHOULD define a secure default configuration for the software with which the software is configured. The default configuration SHOULD be documented.

APP.6.A5 Secure Installation of Software (B)

Software MUST be installed on IT systems in accordance with the installation regulation. In doing so, exclusively unaltered versions of the approved software MUST be used.

If these instructions are deviated from, this MUST be approved by supervisors and IT Operations and documented accordingly.

Standard Requirements

Together with the basic requirements, the following requirements correspond to the state of the art for this building block. They SHOULD generally be fulfilled.

APP.6.A6 Consideration of Recommended Security Requirements (S)

The institution SHOULD consider the following security requirements in the requirements catalog for the software:

• The software SHOULD include general security functions such as logging and authentication that are required in the application context.
• The software SHOULD enable use of the hardening functions of the deployment environment. In particular, the hardening functions of the planned operating system and planned execution environment SHOULD be considered.
• If information is transmitted by the software over unsecured, public networks, the software SHOULD use secure encryption functions that correspond to the state of the art. Furthermore, 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 revoke certificates, withdraw trust from them, or add custom certificates.

The functions of the software arising from the security requirements SHOULD be used in operation.

APP.6.A7 Selection and Evaluation of Potential Software (S) [Subject Matter Experts, Procurement Office]

Based on the requirements catalog, the products available on the market SHOULD be reviewed. They SHOULD be compared with each other using a rating scale. Subsequently, it SHOULD be investigated whether the products in the shortlist meet the institution’s requirements. If there are multiple alternative products, the acceptance of users and the additional effort for, e.g., training or migration SHOULD also be considered. Subject matter experts SHOULD select a suitable software product together with IT Operations based on the evaluations and test results.

APP.6.A8 Regulation for the Availability of Installation Files (S)

IT Operations SHOULD ensure the availability of installation files to be able to reproduce the installation. For this, IT Operations SHOULD:

• back up the installation files appropriately, or
• ensure the availability of the installation files through the source (e.g. app store).

In addition, it SHOULD be ensured that software can be reproducibly configured. For this, the configuration files SHOULD be backed up. Alternatively, it SHOULD be documented appropriately how the software is configured.

This regulation SHOULD be integrated into the institution’s data backup concept.

APP.6.A9 Software Inventory (S)

Software SHOULD be inventoried. An inventory record SHOULD document which systems the software is deployed on and under which license. If needed, the security-relevant settings SHOULD additionally be recorded. Software SHOULD only be used with licenses that correspond to the intended purpose and contractual terms. The license SHOULD cover the entire planned usage period of the software.

If a deviation from the default configuration occurs, this SHOULD be documented. The inventory record SHOULD be updated by IT Operations on an event-driven basis, in particular when software is installed.

The inventory record SHOULD be structured so that in the event of security incidents, a quick overview with the necessary details is possible.

APP.6.A10 Creation of a Security Policy for Software Deployment (S)

The institution SHOULD consolidate the rules that define how the software is to be used and operated in a security policy. The policy SHOULD be known to all relevant persons responsible, those in charge, and employees of the institution, and SHOULD form the basis for their work and actions. In terms of content, the policy SHOULD also include a user manual that explains how the software is to be used and administered.

It SHOULD be regularly and randomly checked whether employees are complying with the policy. The policy SHOULD be regularly updated.

APP.6.A11 Use of Plug-ins and Extensions (S)

ONLY plug-ins and extensions that are absolutely necessary SHOULD be installed. If extensions are used, the software SHOULD offer the ability to configure and disable extensions.

APP.6.A12 Regulated Decommissioning of Software (S) [Subject Matter Experts]

When software is decommissioned, IT Operations SHOULD define with subject matter experts how this is to be carried out in detail. It SHOULD also be defined how users are to be informed about this. It SHOULD be clarified whether the functional requirements continue to exist (e.g. for the processing of specialist tasks). If this is the case, it SHOULD be defined how the required functions of the affected software will continue to be available.

APP.6.A13 Uninstallation of Software (S)

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

Requirements for High Protection Needs

The following are exemplary proposals for requirements for this building block that go beyond the level of protection that corresponds to the state of the art. The proposals SHOULD be considered when there are high protection needs. The specific determination is made within the context of an individual risk analysis.

APP.6.A14 Use of Certified Software (H)

When procuring software, it SHOULD be defined whether assurances from the manufacturing or providing company regarding implemented security functions can be recognized as sufficiently trustworthy. If this is not the case, a certification of the application, e.g. according to Common Criteria, SHOULD be used as a decision criterion. If multiple products are available for selection, security certificates SHOULD in particular be considered when the evaluated functional scope (largely) covers the minimum functionality and the strength of the mechanisms corresponds to the protection needs.

Additional Information

Good to Know

The International Organization for Standardization (ISO) provides requirements for information security of IT systems in standard ISO/IEC 27001:2013 in Annex A.14 “Security requirements of information systems,” which should also be considered when selecting and using software.

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

The National Institute of Standardisation and Technology formulates in NIST Special Publication 800-53 in Appendix F “Family System and Service Acquisition,” among other things, requirements for the procurement of IT products, including software.

The Information Security Forum (ISF) presents in its standard “The Standard of Good Practice for Information Security” in the chapter “Business Application Management,” among other things, best practices for securing software.