CON.8 Software Development

A suitable process model MUST be defined for software development. Based on the process model selected, a flow chart for software development MUST be created. In cases involving commissioned development, the client's security requirements for the process MUST be integrated into the process model.

The selected process model, including the specified security requirements, MUST be followed.

Staff SHOULD be trained in the methodology of the selected process model.

A list of required and optional selection criteria for a development environment MUST be provided by the Process Owner for software development. The development environment MUST be selected based on the criteria specified.

The following basic rules of secure system design MUST be considered in the software to be developed:

• All input data MUST be checked and validated before further processing takes place.
• For client-server applications, the data MUST be validated on the server side.
• The software's default settings MUST be set to facilitate secure operation.
• In the event of errors in or failures of system components, sensitive information MUST NOT be disclosed.
• It MUST be possible to run the software with as few privileges as possible.
• Sensitive data MUST be transmitted and stored in encrypted form according to the specifications of the crypto concept at hand.
• Trusted mechanisms that meet the security requirements of the application in question MUST be used for user authentication and access.
• If passwords are stored for authentication, they MUST be stored using a secure hash procedure.
• Security-relevant events MUST be logged in such a way that they can be evaluated afterwards.
• Information that is not relevant for productive operation (e.g. comments with access data for the development environment) SHOULD be removed in delivered program code and configuration files.

The system design MUST be documented. It MUST be verified that the system design meets all the relevant security requirements.

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.

Even before software is tested and approved in a corresponding process, software tests MUST be performed and the source code checked for errors during development. The Process Owner of the client or department that has commissioned the development SHOULD be involved.

The tests carried out during development MUST cover the functional and non-functional requirements of the software. The software tests MUST include negative tests, as well. In addition, all critical limits on input and data types MUST be checked.

Test data SHOULD be carefully selected and protected for this purpose. Furthermore, automatic static-code analysis SHOULD be performed.

The software MUST be tested in a test and development environment that is separate from the production environment. Furthermore, tests MUST be carried out to determine whether the system requirements are sufficiently sized for the intended software.

It MUST be ensured that security-critical patches and updates for developed software are provided in a timely manner by the Developers. If security-critical updates are released for external libraries in use, the Developers MUST adapt their software accordingly and provide corresponding patches and updates.

The Developers MUST provide checksums or digital signatures for installation, update, and patch files.

Development project source code MUST be managed by an appropriate version management system. An organisation MUST regulate access to its version management system and define when changes made to source code by Developers are to be stored as a separate version in the system. It MUST be ensured that all changes to source code can be tracked and reversed by means of the version management system.

Version management MUST be included in the organisation's backup concept. Version management MUST NOT take place without data backups.

Unknown external components (or program libraries) whose security cannot be ensured by established and recognised peer reviews or comparable means MUST be checked for vulnerabilities. All external components MUST be checked for potential conflicts.

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

Furthermore, obsolete versions of external components SHOULD NOT be used in current development projects.

One person SHOULD be assigned responsibility for the software development process. In addition, the roles and responsibilities for all software development activities SHOULD be defined. The roles SHOULD cover the following topics:

• Compliance management and change management
• Software design and architecture
• Information security in software development
• Software implementation in the areas relevant to the development project at hand
• Software testing

One person SHOULD be assigned responsibility for information security for each development project.

A software development policy SHOULD be created and kept up to date. In addition to naming conventions, the policy SHOULD contain specifications for elements that may or may not be used. The relevant requirements from this module SHOULD be included in the policy. The policy SHOULD be binding for Developers.

Sufficient project, function, and interface documentation SHOULD be created and kept up to date. Operational documentation SHOULD include specific security instructions for administrators on the installation, configuration, and use of the product in question.

Software development SHOULD be documented in a manner that will enable a technical expert to understand and develop the corresponding program code further. The documentation SHOULD also include the software architecture and threat modelling.

Aspects related to documentation SHOULD be considered in the process models used for software development.

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

• Requirements analysis
• Project management in general, as well as with regard to software development in particular
• Risk management and threat modelling in software development
• Quality management and quality assurance
• Models and methods of software development
• Software architecture
• Software testing
• Change management
• Information security, the security policies of the organisation in question, and security aspects in special areas

Software development SHOULD follow a suitable control or project management model based on the selected process model. The control or project management model SHOULD be integrated into the software development policy in question. In this regard, the required personnel qualifications and the coverage of all relevant phases during the lifecycle of the software SHOULD be considered in particular. A suitable system of risk management SHOULD be established for the process model. Appropriate quality objectives SHOULD also be defined for each development project.

Threat modelling SHOULD be undertaken during the design phase of software development. For this purpose, potential threats SHOULD be identified on the basis of the relevant security profile, the catalogue of requirements, and the planned operational environment or operational scenario. The threats SHOULD be assessed in terms of their probability and impact.

Software design SHOULD take into account the applicable requirements catalogue, the security profile, and the results of threat modelling. As part of secure software design, a secure software architecture SHOULD be assembled as the basis for developing the source code of the application in question. 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.

Only tools with proven security properties SHOULD be used to develop software. Sufficient requirements SHOULD be imposed on hardware or software manufacturers with regard to the security of their tools.

Regular security audits SHOULD be performed on environments used for software development and testing.

The integrity of a development environment SHOULD be checked regularly with cryptographic mechanisms in line with the current state of the art. The deployed test program itself and its checksum files SHOULD be adequately protected against manipulation. A large number of false positives SHOULD NOT be allowed to obscure important information that indicates a loss of integrity.