S 2.487 Development and extension of applications

Initiation responsibility: Specialists Responsible, Persons responsible for individual applications

Implementation responsibility: Purchaser, Tester, Head of Development, Developer

For the efficient development of applications (also web applications), rules and regulations should be defined and complied with. In this case, the objective is to avoid both planning and programming errors at an early stage of the development and extension process or to detect them at least in good time.

Therefore, the following aspects should be taken into account for the development and extension of applications.

Development according to a procedural model

It should be developed according to an appropriate procedural model (e.g. V-Modell XT, waterfall model, spiral model). Prior to initial operation, an application must pass all development phases of the procedural model.

The procedural model applied should at least cover the following or comparable phases.

During this phase, all data to be processed by the application should be identified and classified according to the protection requirements. Adequate protection mechanisms of the application must be defined, which protect the data according to their respective protection requirements.

During the planning phase, the architecture and the structure of the application should be defined and documented. In this respect, the selection of development techniques (for example, programming languages, frameworks) should also be taken into account. The developers' knowledge and experience should also be taken into consideration for financial and security reasons.

The architecture should allow that components (for example, for authorisation, authentication) are preferably used in modules which can be reused. Due to the central availability and use of modules, redundancies can be avoided and it is much easier to maintain the application.

For client/server architectures (e.g. web application), the central security mechanisms should be implemented at least on the server side whenever possible.

It should be ensured that the security requirements are fulfilled completely by the security mechanisms and that they are documented to create test cases.

The decisions taken should be documented so that it is ensured by adequate documentation that the application is enhanced.

It should be ensured that the documentation is continued during the development activity (for example, by means of comments in the source text and tools to generate the documentation). Thus, the source text can also be understood by third parties at a later point of time.

To ensure that solutions that have already been developed and discarded as well as for documentation purposes, the history of changes should be documented (e.g. using a revision system).

Tests

Test cases should not only take into account business functions, but also security functionality. This includes, for example, security components such as authorisation, authentication and filter components. If possible, penetration tests and (for high protection requirements) also source code analyses should be carried out to check the implemented security mechanisms (S 5.150 Performing penetration tests).

Prior to the initial operation of an application, not only the proper functioning, but also possible misuse of the offered functionality should be tested. This can be achieved by performing penetration tests. To ensure that a two-man-rule is applied to the testing, the tests should not be carried out by those who were previously involved in the planning or the development of the application.

With respect to the tests, it must be ensured that they are only carried out using the test data and not live data or customer data.

For web applications, the website should be checked for conformity with the used standard (e.g. HTML standard). Thus, unexpected side effects due to the misinterpretation via the browsers can be prevented. In this respect, a test using different browsers can be very useful.

When planning and performing the tests, safeguard S 2.62 Software acceptance and approval procedure should be taken into consideration.

Integration and software distribution (deployment)

Prior to the productive initial operation, the applications and necessary background systems, if any, must be configured securely. In this case, the connection of possible background systems (e.g. identity repositories, databases) to the application should be taken into account. Prior to the initial operation of an application, it must also be ensured that the transport channel is protected.

Sensitive data of the application is often stored in background systems. Therefore, the security level of the application and of possible background systems should be uniform. The users should only be able to access the background systems using the defined interface of the application.

In addition to this, it should be ensured that the data cannot be manipulated by third parties when distributing the application.

Maintenance

A process to maintain the application taking into account the regular check of the security of the application for weaknesses or available patches must be defined.

If the application is adapted or extended, it must be ensured that the efficiency of the security mechanisms is not impaired. In addition, the efficiency of the security mechanisms should be checked again performing tests in a separate test environment.

Implementation of programming guidelines

A programming guideline helps to define a consistent programming style and to establish a uniform security level (for example by using security libraries). Thus, the quality and comprehensibility of the source text can be improved. As a result of this, it is easier to detect errors and weaknesses and a subsequent extension of the application can be implemented in a cost-effective manner.

Programming guidelines should not only be implemented when developing the application within the organisation, but also when outsourcing the development activity.

Sustainable development of security mechanisms

When security mechanisms are designed and developed, both future developments of attack techniques and standards (for example, a new HTML standard) should be taken into consideration in this case. For instance, a filter component filtering <script> tags classified as malicious should also filter unknown tags. Unknown tags might be used in future (e.g. with the introduction of a new HTML standard) to bypass the security mechanisms of the web application.

Product-specific security functionality

If a web application is only used with a specific browser (under certain circumstances, a browser from only one manufacturer), the use of product-specific security functions of the browser should be taken into account.

Outsourcing application development

If application development is outsourced, it must be ensured that the contracted third party company meets the necessary security requirements when implementing the application. This can be accomplished, for example by specifying a procedural model or applying programming guidelines.

If a service provider is contracted for the development of an application with high protection requirements, the source text (e.g. the project archive) should be subject to the administrative control of the client. The client should be able to access the source text of the application at any time and track and understand the changes made to the source text.

Determination of the development environment

The production, test and development environments must be run on separate systems. In the different environments, different access data should be selected. Here, test accounts should not contain any privileged rights if possible. In general, successful attacks to the development or test environments must not have any impact on the production environment.

Review questions:

© Federal Office for Information Security. All rights reserved.