S 2.378 System development

Initiation responsibility: Head of IT

Implementation responsibility: User, Administrator

System development for the purpose of this safeguard refers to the development, modification, or expansion of hardware, software, or a complex system consisting of several software and hardware components.

In all of these cases, the corresponding projects must be coordinated with IT management and the specialised departments affected before implementation. An overview of the required performance and other requirements must be formulated for this purpose. The security management must be informed of the system development project at this early stage so the relevant security aspects can be taken into account in the project conception phase. In addition to the required performance of each system, it is also necessary to take possible effects on the business processes and information security in the organisation into account in all cases.

The security requirements for an IT system should be determined and coordinated in advance before starting development. The subsequent implementation of security safeguards is significantly more expensive and generally provides less protection than security that has been integrated right from the start in the system development process or product selection process. For this reason, security should be an integral part of the entire life cycle of an IT system or product.

The recommendations listed here are based on the document "Planning and Implementing IT Projects in the Federal Administration" (V model) and in part on the specifications of the "Information Technology Security Evaluation Criteria" (ITSEC) and the "Common Criteria for Information Technology Security Evaluation" (CC).

Safeguard S 2.80 Drawing up a requirements catalogue for standard software must be considered when creating the requirements. This safeguard explains the most important points you need to take into account when specifying the functional and security-related requirements.

The requirements catalogue must be coordinated with the security management. If changes to requirements need to be made in the course of system development, then the security management must agree to the changes and the requirements catalogue needs to be updated. The requirements catalogue forms the foundation for the approval and release of the product.

Procedural model

System development must be performed according to a consistent, uniform, and mandatory procedural model. These system developers must ensure that development proceeds strictly according to the procedural model. The procedural model must consist of security-specific roles, activities and results that can be used to check the appropriateness and implementation of security-related system properties.

Before release, the system development must go through the following phases defined in the ITSEC/CC at a minimum:

Security-related results of the requirements definition phase

In the requirements definition phase, the threats, vulnerabilities and risks to the information security of the particular application, the security aspects the application environment; the external specifications; and the project environment must be examined. The security required, which leads to the formulation of security requirements, is determined in the framework of a protection requirements determination based on this information. The security requirements must be checked for consistency and completeness (see also S 2.80 Drawing up a requirements catalogue for standard software).

Security-related results of the architectural design phase

In the architectural design phase, the internal controls for the application, the basic information security functions, and the organisational and technical security safeguards are specified at the technical level.

The security requirements must be checked for consistency and to ensure they were stated in enough detail by the specifications of the architectural design. In this case, the security components should be clearly separated logically from the other components.

Security-related results of the detailed design phase

In the detailed design phase, the security specifications of the technical design must be further refined so that they can serve as a basis for the implementation without requiring any further interpretation. All modules in which control functions are executed, sensitive processing and communication workflows are executed, sensitive data is accessed or from which sensitive data is transmitted must be identified.

It must be checked whether the technical design has been consistently refined by the detailed design. The internal controls needed to guarantee fulfilment of the security requirements must be specified by defining program interfaces (APIs or Application Program Interfaces). To improve handling, the security APIs should be clearly structured and separated from the other modules.

Security-related results of the implementation phase

In the implementation phase, the security requirements specified must be implemented appropriately using the corresponding security APIs. The implementation must be checked and tested to see if it meets their specifications, and especially the security specifications.

Minimum requirements on the development environment

An integrated development environment (IDE) is an application program used to develop software. The integrated development environment makes it easier to develop IT systems since it collects all of the most important components, for example a compiler, a debugger, and an editor, into one piece of software.

All development must be based on a uniform and mandatory library structure. Naming conventions must be defined and prescribed for the program code as well as for the names of modules. The goal of such naming conventions is to highlight important information such as the development status, development site, type of documentation, etc. using suitable names.

Methods, tools, and roles must be defined and implemented that allow the following:

It must be possible to document tested and approved development results so that they can serve as a basis for further development. In particular, it must be possible to assign further development to different development units at defined points in the procedural model.

The development tools used must allow you to track down and check the quality of all changes made that were necessary due to modifications or due to negative test results.

The physical environment in which system development will take place must also be specified in the early planning phase based on the security requirements. This includes, among other items, the requirements placed on the site access and system access control mechanisms

Quality assurance (QA)

Quality assurance must be planned at the start of the development phase. In this context, suitable safeguards must be specified to meet the security requirements and then integrated constructively and analytically into the development process.

In addition to checking if the functionality provided by the system meets the specifications and requirements catalogue, it is also necessary to check the response of the system to cases of misuse and to errors.

QA safeguards must be implemented at defined review dates, but at least at the end of each development phase. Furthermore, additional internal reviews can be specified when this is necessary.

During the requirements definition and design phases, test specifications and test cases must be developed and documented that are suitable for examining the quality of the system and the conformity to the security requirements. Corresponding tests must be conducted during the implementation phase and during approval.

The execution of the test must be documented. Automatic re-testing and automatic comparison of the test results (regression test) should be set as goals. As a rule, practical data is only allowed to be used as test data when it is available in anonymised form (see also S 2.82 Developing a test plan for standard software and S 2.83 Testing standard software).

Transferral to production and software maintenance

There must be uniform guidelines for the transferral to production and for system maintenance.

Transferral to production

Strict separation of development environment from the production environment, and especially of the processing of test data and real data, must be guaranteed. There must be a clearly defined approval procedure for the systems and applications developed. Systems and applications may only be transferred from the test environment to production environment after release. All parts of programs that were only written for test purposes must be removed before release. The minimum requirement for release is the successful completion of the approval processes together with extensive tests in the target environment at the end of the development process. In the framework of the approval process, it is particularly important to determine if the IT systems and IT applications respond in accordance with the security requirements when in the target environment.

It must be ensured that only properly released programs and modules are actually used (see also S 2.85 Approval of standard software).

Maintenance and problem management

Every unauthorized change to an IT system in use must be prevented. It must be possible to trace all authorised modifications using a suitable change and configuration management system. In the context of change and configuration management, it is also necessary to define storage periods for all system components.

System components not in use any more such as old versions of programs or modules, configuration data, and their documentation must also be kept for the duration of the storage period. There must be a clearly defined procedure and clearly specified authorities for reporting system problems to those responsible.

Every authorised modification to the system due to detected shortcomings or to the extension of its functionality must be performed according to the procedural model selected in the uniform development environment, and the system must be returned back to production using a controlled return procedure. There must also be a clearly defined procedure for handling emergencies.

Software development by end users

Standard software often allows the end users to develop and use their own programs in order to make routine tasks easier (for example by programming macros). However, the uncontrolled use of programs developed by users can pose security risks. For this reason, a policy decision should be made in every organisation of whether or not software developed in-house is desired, and if so, who is allowed to develop such software (see S 2.379 Software development by end users). Software developed in-house must be tested and released before it may be used in the production environment. Likewise, it must be specified who will maintain these programs and eliminate problems when they arise. The regulations for the use of programs developed by users should be specified in a security policy.

Review questions:

© Federal Office for Information Security. All rights reserved.