CON.8 Software Development

Description

Introduction

Many institutions face challenges that can no longer be adequately addressed with a finished, unadapted software product. They require software solutions tailored to their individual requirements. Examples include highly specific software solutions for industry-specialised processes (such as controlling production plants) or IT applications adapted to their own business processes (such as content management systems or identity management systems). Even legacy systems that are no longer maintained by the original manufacturer can be individually further developed.

In this context, (bespoke) software can be developed by the institution itself or by a third party. Software development plays a central role when program code is developed or adapted based on the institution’s requirements. It is of essential importance that information security is considered throughout the entire software development process and not only at a later stage. Only in this way can the information security of the software solution to be developed be sustainably ensured.

Software can be developed as part of classic, self-contained projects, or as a continuous activity without a fixed end. In both cases, project management tools are very frequently used in practice to coordinate and control software development. For this reason, this building block uses the term project more frequently and does not consistently distinguish between project-based and continuous development, since the associated approaches and tools are similar.

Objective

The building block addresses all relevant security aspects that institutions must observe when developing software in-house. It examines how an institution can prepare and conduct software development. Corresponding threats are identified and requirements formulated.

Scope and Modeling

The building block CON.8 Software Development is to be applied to every development project in the information network when software is to be developed.

When software is developed, a client-contractor relationship very frequently exists. In IT-Grundschutz, this situation is reflected in the building block APP.7 Development of Bespoke Software covering the client side and the building block CON.8 Software Development covering the contractor side. The requirements of this building block are therefore to be met by contractors. The requirements relevant to software development (functional and non-functional requirements, requirements for secure procedures and the security profile) are identified by the client within the framework of the building block APP.7 Development of Bespoke Software.

The building block does not constitute a complete guide or general procedure for software development, but focuses on the relevant aspects of information security in software development. The building block also does not cover aspects of patch and change management. For these, the building block OPS.1.1.3 Patch and Change Management is to be applied.

The acceptance and associated testing of in-house or commissioned software is governed by the building block OPS.1.1.6 Software Tests and Releases. Aspects of testing within the scope of software development that go beyond this are covered in this building block CON.8 Software Development.

The building block ORP.5 Compliance Management (Requirements Management) must also be considered, as it governs how legal and internal institutional requirements as well as customer requirements are taken into account.

If the software development encompasses cryptographic aspects, the relevant requirements from the building block CON.1 Cryptographic Concept must be observed.

Threat Landscape

Since IT-Grundschutz building blocks cannot address individual information networks, typical scenarios are used to illustrate the threat landscape. The following specific threats and vulnerabilities are of particular relevance for the building block CON.8 Software Development.

Selection of an Inappropriate Process Model

Process models structure and plan the course of software development by defining specific steps and their sequence. If an inappropriate process model is selected for software development, the course of development and the associated development project can be significantly disrupted. Depending on how the chosen model is designed and how extensive the development project is, either important aspects may be neglected or irrelevant aspects may be excessively focused upon. Both problems increase the workload in project management and restrict productive work.

If no process model is used at all, there is an elevated risk that relevant aspects — particularly those relating to information security — will not be adequately addressed in software development. This can result in relevant security functions not being implemented or tested at all, meaning the developed software does not meet security requirements.

Selection of an Inappropriate Development Environment

If a development environment is selected inappropriately or is chosen individually by individual employees, urgently needed functions may be missing or not implemented in sufficient form. Furthermore, an inappropriate development environment can also contain errors or vulnerabilities that can cause significant disruptions during software development.

If no specific development environment is selected and specified, different developers may work on the software using different self-chosen tools, potentially causing compatibility problems. Different compilers, for example, can trigger such compatibility problems.

Absent or Inadequate Quality Assurance in the Development Process

Absent or inadequate quality assurance during software development can delay or even cause the entire development project to fail. If it is not checked whether the in-house software is being implemented securely, vulnerabilities in the delivered software are a threat.

If quality assurance is not firmly embedded in the development process, errors and manipulations in the design or implementation may go undetected. Attention should be paid not only to in-house components, but especially to external contributions and adopted components.

Absent or Inadequate Documentation

If the software is not or only insufficiently documented during the design or development phase, this can mean that any errors can only be diagnosed and rectified with a delay or not at all. If development is inadequately documented, the software can also only be updated, adapted or extended with great effort at a later stage.

If administration or user documentation is inadequate, the software could be improperly managed or operated in productive use. This can, for example, disrupt IT operations, produce incorrect work results or delay workflows.

Insufficiently Secured Use of Development Environments

If the development environment is insufficiently secured, the software to be produced could potentially be manipulated. Such manipulations can subsequently only be detected with great difficulty.

If it is not known which users can and could access the development environment at what times, the software can be anonymously manipulated. If the manipulated parts of the software are discovered, it may not be possible to determine which users manipulated them.

Without adequate version control of the source code, it is not possible to reliably trace changes or to restore previous working versions of the software.

If source code is insufficiently protected against accidental or deliberate changes, parts of the source code or even the entire source code can be damaged and the work already invested lost.

If the source code or version control is not adequately protected against data loss, various threats arise regardless of whether the data loss is caused, for example, by a technical defect or by human error. The software may not be able to be further developed at all because the data inventory is completely absent, or only an outdated and potentially erroneous intermediate state may be available that can only be used with very high effort.

Software Design Errors

The more extensive a software’s functional scope becomes, the more extensive its program code often becomes as well. If the program code is not structured by appropriate measures and is not based on an adequate software architecture, it can generally only be maintained with great difficulty. Security vulnerabilities can then only be closed with difficulty or outdated program components can only be replaced with very high effort — for example when the protection need of the processed data changes and consequently the security requirements for the software also change.

Software design errors not only make it more difficult to maintain the software, but can themselves lead to security vulnerabilities and threats. If the program code is not sensibly structured and the software architecture is not comprehensibly documented, conceptual errors in software tests can only be identified with great difficulty. Consequently, security vulnerabilities can exist at the most varied levels of the software.

Software design errors are frequently historically conditioned in practice — for example when legacy systems are used for tasks and environments for which they were not originally designed. Moreover, in software development of very old applications, aspects such as maintainability and modifiability were not taken into account to the extent now required by the state of the art.

Absent or Inadequate Testing and Release Procedures

If new software is not adequately tested and released, errors in the software cannot be identified. Such errors threaten not only the productive use and information security of the new software itself, but potentially also other applications and IT systems in the production environment.

If security functions or the basic security requirements are not tested, it is not ensured that the developed software meets the security requirements of the deploying institution. Consequently, sensitive information could be disclosed, manipulated or destroyed — for example if unauthorised third parties gain access to the software due to inadequate authentication functions.

Software Testing with Production Data

If new software is tested with production data, persons who may not be authorised could view confidential information, such as particularly sensitive personal data.

If testing is not done with copies of production data but with the originals (e.g. in database systems), even more extensive threats arise:

• Malfunctions of software during testing can result in not only the confidentiality of production data but also its integrity or availability being affected.
• Unintended changes to production data can also arise from the software being tested or operated incorrectly. This change may not be detected promptly. Such errors can also affect other IT applications that access the same data sets.

These circumstances are very frequently exacerbated by the fact that while software is being tested, the focus is not on protecting the test data but on whether the software behaves as intended or as defined by the requirements.

Requirements

The following are the specific requirements of the building block CON.8 Software Development. The Information Security Officer (ISO) is responsible for ensuring that all requirements are met and reviewed in accordance with the established security concept. The ISO must always be involved in strategic decisions.

Additional roles are defined in the IT-Grundschutz Compendium. These should be filled to the extent that it is sensible and appropriate.

Exactly one role should bear Primary responsibility. There may also be Additional responsibilities. If one of these additional roles has primary responsibility for fulfilling a specific requirement, that role is listed in square brackets after the heading of the requirement. The use of singular or plural says nothing about how many persons should fill these roles.

Basic Requirements

The following requirements MUST be met as a priority for this building block.

CON.8.A2 Selection of a Process Model (B)

A suitable process model for software development MUST be defined. Based on the chosen process model, a schedule for software development MUST be created. The client’s security requirements for the procedure MUST be integrated into the process model.

The selected process model, including the defined security requirements, MUST be adhered to.

Personnel SHOULD be trained in the methodology of the chosen process model.

CON.8.A3 Selection of a Development Environment (B)

A list of required and optional selection criteria for a development environment MUST be created by Subject Matter Experts for software development. The development environment MUST be selected based on the specified criteria.

CON.8.A4 DISCONTINUED (B)

This requirement has been discontinued.

CON.8.A5 Secure System Design (B)

The following fundamental rules of secure system design MUST be observed in the software to be developed:

• All input data MUST fundamentally be checked and validated before further processing.
• In client-server applications, data MUST fundamentally be validated on the server.
• The default settings of the software MUST be preconfigured to enable secure operation of the software.
• In the event of errors or failures of system components, sensitive information MUST NOT be disclosed.
• The software MUST be executable with the lowest possible privileges.
• Sensitive data MUST be transmitted and stored encrypted in accordance with the specifications of the cryptographic concept.
• Trustworthy mechanisms that meet the security requirements of the application MUST be used for user authentication and authorisation.
• If passwords are stored for authentication, they MUST be stored using a secure hashing method.
• Security-relevant events MUST be logged in a manner that allows them to be evaluated retrospectively.
• Information that is not relevant for productive operation (e.g. comments containing access credentials for the development environment) SHOULD be removed from delivered program code and delivered configuration files.

The system design MUST be documented. It MUST be checked whether all security requirements for the system design have been met.

CON.8.A6 Use of External Libraries from Trusted Sources (B)

If external libraries are used as part of the development and implementation process, they MUST be obtained from trusted sources. Before external libraries are used, their integrity MUST be ensured.

CON.8.A7 Carrying Out Development-Accompanying Software Tests (B) [Testers, Developers]

Before software is tested and released in the release process, development-accompanying software tests MUST be carried out and the source code reviewed for errors. Subject Matter Experts of the client or the commissioning specialist department SHOULD already be involved at this stage.

The development-accompanying tests MUST cover the functional and non-functional requirements of the software. The software tests MUST also cover negative tests. In addition, all critical boundary values of inputs and data types MUST be checked.

Test data SHOULD be carefully selected and protected for this purpose. Furthermore, automated static code analysis SHOULD be carried out.

The software MUST be tested in a testing and development environment that is separate from the production environment. It MUST also be tested whether the system prerequisites for the intended software are sufficiently dimensioned.

CON.8.A8 Provision of Patches, Updates and Changes (B) [Developers]

It MUST be ensured that security-critical patches and updates for the developed software are provided promptly by the developers. If security-critical updates are provided for external libraries used, the developers MUST adapt their software accordingly and in turn make corresponding patches and updates available.

For installation, update or patch files, checksums or digital signatures MUST be provided by the developer.

CON.8.A9 DISCONTINUED (B)

This requirement has been discontinued.

CON.8.A10 Version Control of Source Code (B) [Developers]

The source code of the development project MUST be managed via appropriate version control. The institution MUST regulate access to the version control and define when changes to the source code by developers are to be saved as a distinct version in the version control. It MUST be ensured that all changes to the source code can be traced and reversed through the version control.

The version control MUST be taken into account in the data backup concept. Version control MUST NOT take place without data backup.

CON.8.A20 Review of External Components (B)

Unknown external components (i.e. program libraries) whose security cannot be ensured through established and recognised peer reviews or comparable processes MUST be reviewed for vulnerabilities. All external components MUST be reviewed for potential conflicts.

The integrity of external components MUST be verified by checksums or cryptographic certificates.

Furthermore, no outdated versions of external components SHOULD be used in current development projects.

Standard Requirements

Together with the basic requirements, the following requirements represent the state of the art for this building block. They SHOULD generally be met.

CON.8.A1 Definition of Roles and Responsibilities (S) [Central Administration]

For the software development process, an overall responsible person SHOULD be designated. Furthermore, roles and responsibilities for all activities within the scope of software development SHOULD be defined. The roles SHOULD professionally cover the following topics:

• Requirements engineering (requirements management) and change management,
• Software design and architecture,
• Information security in software development,
• Software implementation in the areas relevant to the development project, and
• Software testing.

For each development project, a person responsible for information security SHOULD be designated.

CON.8.A11 Creation of a Guideline for Software Development (S)

A guideline for software development SHOULD be created and kept up to date. The guideline SHOULD contain not only naming conventions but also specifications for elements that may and may not be used. The relevant requirements from this building block SHOULD be incorporated into the guideline. The guideline SHOULD be binding for developers.

CON.8.A12 Comprehensive Documentation (S)

Adequate project, function and interface documentation SHOULD be created and kept up to date. The operational documentation SHOULD contain specific security notes for installation and configuration for administrators as well as for the use of the product.

The software development SHOULD be documented in such a way that specialists can trace and further develop the program code with the aid of the documentation. The documentation SHOULD also cover the software architecture and threat modelling.

The documentation aspects SHOULD be taken into account in the process model for software development.

CON.8.A13 DISCONTINUED (S)

This requirement has been discontinued.

CON.8.A14 Training of the Development Team on Information Security (S)

Developers and other members of the development team SHOULD be trained on general information security aspects and on the aspects specifically relevant to them:

• Requirements analysis,
• Project management in general and specifically in software development,
• Risk management and threat modelling in software development,
• Quality management and quality assurance,
• Models and methods for software development,
• Software architecture,
• Software testing,
• Change management, and
• Information security, the institution’s security specifications and security aspects in specific areas.

CON.8.A15 DISCONTINUED (S)

This requirement has been discontinued.

CON.8.A16 Appropriate Management of Software Development (S)

For software development, an appropriate management or project management model based on the selected process model SHOULD be used. The management or project management model SHOULD be integrated into the guideline for software development. In particular, the required qualifications of personnel and the coverage of all relevant phases during the lifecycle of the software SHOULD be taken into account. Appropriate risk management SHOULD be defined for the process model. Furthermore, appropriate quality objectives for the development project SHOULD be defined.

CON.8.A21 Threat Modelling (S)

In the design phase of software development, threat modelling SHOULD be carried out. For this purpose, potential threats SHOULD be identified based on the security profile, the requirements catalogue and the planned deployment environment or deployment scenarios. The threats SHOULD be assessed with regard to their likelihood of occurrence and impact.

CON.8.A22 Secure Software Design (S)

The software design SHOULD take into account the requirements catalogue, the security profile and the results of threat modelling. Within the framework of secure software design, a secure software architecture SHOULD be developed as the basis on which the application’s source code is to be developed. Future standards and attack techniques SHOULD be taken into account as far as possible, so that the software to be developed can also be easily maintained in the future.

Requirements for High Protection Needs

The following are examples of proposed requirements for this building block that go beyond the level of protection corresponding to the state of the art. These proposals SHOULD be considered for high protection needs. The specific determination is made within the framework of an individual risk analysis.

CON.8.A17 Selection of Trustworthy Development Tools (H)

Only tools with proven security properties SHOULD be used for software development. Sufficient security requirements for their tools SHOULD be imposed on manufacturers of hardware or software.

CON.8.A18 Regular Security Audits of the Development Environment (H)

Regular security audits of the software development environment and the software testing environment SHOULD be carried out.

CON.8.A19 Regular Integrity Checking of the Development Environment (H) [IT Operations]

The integrity of the development environment SHOULD be regularly checked using cryptographic mechanisms in accordance with the state of the art. The checksum files and the checking program itself SHOULD be adequately protected against manipulation. Important indications of an integrity loss SHOULD not be lost in a flood of irrelevant warning messages (false positives).

Additional Information

Good to Know

The International Organization for Standardization (ISO) sets out requirements for software development among others in these standards:

• ISO/IEC 27001:2013 Appendix A.14.2 “Security in development and support processes” — requirements for security in development and support processes,
• ISO/IEC 25000:2014 “Systems and software Quality Requirements and Evaluation - Guide to SQuaRE” — a general overview of the SQuaRE standard series,
• ISO/IEC 25001:2014 “Planning and management” — requirements for planning and management, and
• ISO/IEC 25010:2011 “System and software quality models” — requirements for a quality model and guidelines.

The Information Security Forum (ISF) provides specifications for secure software development in its standard “The Standard of Good Practice for Information Security” in chapter “SD System Development”.

The National Institute of Standards and Technology provides requirements for secure system design in its Special Publication 800-160 “Systems Security Engineering, Considerations for a Multidisciplinary Approach in the Engineering of Trustworthy Secure Systems”.

The special interest group “Process Models for Business Application Development” of the Gesellschaft für Informatik provides an overview of current information on application development in its publications.

Further information on threat modelling can be found in the scientific article “Threat Modelling in Software Development”. The article was published at the “Sicherheit 2010: Sicherheit, Schutz und Zuverlässigkeit” (Security 2010: Security, Protection and Reliability) conference of the Gesellschaft für Informatik.