APP.7 Development of Custom Software

Description

Introduction

Many institutions face challenges that they can no longer adequately address with off-the-shelf software. The tasks associated with these challenges frequently require software solutions tailored to the individual needs of the institutions. In the following, these software solutions are referred to as custom software. On one hand, base solutions consisting of a basic set of typical functions can be deployed and individualized. The basic functions are adapted to the institution’s individual deployment purpose and extended with individually required functions. Common examples of this include IT applications such as ERP (Enterprise Resource Planning), CMS (Content Management Systems), or IDM (Identity Management) systems. Custom software can also be completely newly developed by the institution itself or by third parties. This includes applications for business process control or individually adapted specialist applications such as HR management software, systems for managing social data, or registration data management.

Of essential importance here is that the required security functions are already considered during the planning and conceptualization of the custom software, and that information security is taken into account throughout the entire lifecycle of the custom software. Errors in planning or missing security functions cannot be compensated during ongoing operation, or can only be compensated with significant additional effort.

Custom software is typically developed within the context of a project. For this purpose, a wide variety of procedures or project management models have been established. While classic, linear process models such as the waterfall process are well suited to projects with requirements that are fixed from the outset, agile process models such as Scrum enable custom software to be developed iteratively and incrementally. Agile process models can thus better adapt to changing circumstances, especially when not all requirements are yet known from the start. However, they do not provide the same planning certainty as linear process models and in some cases also do not fit with the classical structures of procurement processes that are geared toward a linear approach.

Objective

The objective of this building block is to identify what fundamental security requirements must be observed in the planning and development of custom software.

Scope and Modeling

The building block APP.7 Development of Custom Software must be applied once for each development of a custom software.

Aspects of the planning, conception, and deployment of custom software — such as defining required security functions or decommissioning custom software — are addressed in the building block APP.6 General Software. It must therefore always be applied together with this building block.

When software is developed, a contracting and a contracted relationship very frequently exists. In IT-Grundschutz, this is reflected by the building block APP.7 Development of Custom Software addressing the contracting side and the building block CON.8 Software Development addressing the contracted side.

The release and testing of custom software is addressed in the building block OPS.1.1.6 Software Tests and Releases.

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.7 Development of Custom Software.

Inadequate Contractual Arrangements with External Service Providers

Due to inadequate contractual arrangements with external service providers, a wide variety of serious security problems can arise. This applies in particular when applications are created, introduced, or maintained. If tasks, performance parameters, or effort are insufficiently or ambiguously described, security measures may not be implemented, possibly due to ignorance, insufficient qualification, or lack of resources. This can have many negative consequences, such as when regulatory requirements and obligations are not met, reporting obligations and laws are not complied with, or no responsibility is assumed because monitoring and control options are missing.

Software Design Flaws

When applications, programs, and protocols are conceptualized, security-relevant design flaws can arise. These frequently result from application modules and protocols intended for a specific purpose being reused in other deployment scenarios. If different security requirements are then relevant, this can lead to serious security problems — for example, when application modules and protocols actually intended for isolated operational environments are connected to the internet.

Undocumented Functions

Many applications contain undocumented functions built in by the manufacturer, often for development or support of the application. These are usually not known to users. Undocumented functions are problematic when they allow essential security mechanisms to be circumvented, e.g. for access protection. This can significantly impair the confidentiality, integrity, and availability of the processed data.

Missing or Insufficient Security Measures in Applications

Security mechanisms or security functions in the application are intended to ensure that the required level of confidentiality, integrity, and availability can be guaranteed when processing information. However, during the development of an application, functional requirements or the time and cost framework often take priority. This means that important security mechanisms may be insufficiently developed, so that they can easily be circumvented, or may even be completely missing.

Inadequate Control of Software Development

If the software development is not sufficiently controlled by the contracting party, a number of risks exist, such as:

• Required security functions may be missing or only insufficiently implemented. This can give rise to a variety of risks that jeopardize the availability, confidentiality, and integrity of data processed by the custom software.
• The development project may be delayed in time, so that the custom software is not available on time.
• Priorities may be set incorrectly — for example, functions needed on a secondary basis may be developed extensively while urgently needed security functions are only rudimentarily implemented. Project delays and diverse security risks can also arise from this.

Engagement of Unsuitable Software Developers

If unsuitable software developers are engaged, various threats can arise:

• Due to missing specialist expertise, e.g. in the programming language used, the frameworks deployed, or the planned technical deployment environment, the software can contain many avoidable security vulnerabilities.
• Lack of knowledge in project management and requirements engineering can lead to friction in coordination processes and thus to significant delays. Critical aspects may also be incorrectly prioritized, so that essential security functions are not implemented with the required priority. Unsuitable software developers may be engaged due to, for example, excessively tight and unrealistic cost estimates. Errors, ambiguous requirements, and incorrect objectives in tender documents can also lead to this.

Requirements

The following are the specific requirements of the building block APP.7 Development of Custom 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.7.A1 Extension of Software Deployment Planning with Aspects of Custom Software (B)

Planning for software deployment MUST be supplemented with aspects of custom software by defining:

• who is responsible for controlling and coordinating the software development or the contracted party, and
• in what kind of organizational framework the software is to be developed (project management model).

Custom software SHOULD be developed within the framework of a development project. The development project should be roughly scheduled in time based on a project schedule.

APP.7.A2 Definition of Security Requirements for the Software Development Process (B)

The institution MUST define clear requirements for the software development process. The requirements MUST make clear in what kind of environment the software may be developed and which technical and organizational measures are to be implemented by the contracted software developers.

APP.7.A3 Definition of Security Functions for System Integration (B) [IT Operations]

IT Operations and the responsible subject matter experts MUST create requirements for the technical deployment environment of the planned custom software and coordinate these with the software development. The requirements MUST clearly state:

• on what kind of hardware platform,
• on what kind of software platform (including the entire software stack),
• with what available resources (e.g. CPU cluster or working memory),
• with what interfaces to other IT systems or applications, and
• with what security functions resulting from these

the application is to be deployed. Interfaces with other IT systems SHOULD be modeled and defined in standardized technical formats.

APP.7.A4 Requirements-Compliant Commissioning (B) [Procurement Office]

If custom software is developed by the institution itself or externally commissioned, then in addition to existing legal and organizational requirements, the following in particular MUST be used as the basis for software development:

• the requirements catalog (see APP.6 General Software),
• the security requirements for the software development process, and
• the security functions for system integration.

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.7.A5 Appropriate Control of Application Development (S)

A suitable management and project management model SHOULD be used for the development of custom software. The selected model SHOULD be coordinated with the contracted party. It SHOULD be taken into account in the management.

In particular, it SHOULD be ensured that the required personnel are sufficiently qualified. All relevant phases SHOULD be covered during the software lifecycle. Furthermore, it SHOULD include an appropriate development model, risk management, and quality objectives.

APP.7.A6 Documentation of Requirements for Custom Software (S)

The requirements from the requirements catalog, the security requirements for the software development process, and the security functions for system integration SHOULD be comprehensively documented. In particular, a security profile for the application SHOULD be created. This SHOULD document the protection needs of the data and functions to be processed. The documentation including the security profile SHOULD be made available to the developers for software development.

The documentation SHOULD be updated when changes are made to the custom software and when functional updates occur.

APP.7.A7 Secure Procurement of Custom Software (S)

The development project SHOULD be commissioned within the framework of the most suitable project management model. Security aspects SHOULD already be considered during the tendering and awarding process, so that:

• on one hand, only suitable contracted parties are engaged,
• on the other hand, no far-reaching conclusions about the security architecture are possible from the publicly available information.

The institution SHOULD have defined processes and designated contact persons in place that ensure the respective framework conditions are taken into account.

APP.7.A8 Early Involvement of Subject Matter Experts in Development-Accompanying Software Tests (S)

Subject matter experts SHOULD be involved early in development-accompanying tests by software developers, before the final acceptance. This SHOULD be considered in coordination with the contracted party already initially in the project schedule.

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.7.A9 Escrow Deposit (H)

For institution-critical applications, it SHOULD be examined whether these can be secured against the failure of the manufacturing company. For this purpose, materials and information not included in the delivery scope of the application SHOULD be deposited in trust, e.g. with an escrow agency. Documented code, design plans, keys, or passwords SHOULD be included. The obligations of the escrow agency regarding deposit and release SHOULD be contractually regulated. It SHOULD be clarified when the deposited materials may be released and to whom.

APP.7.A10 Commissioning of Certified Software Development Companies (H)

If particularly security-critical applications are being developed, certified software development companies SHOULD be engaged for this purpose. The certification SHOULD cover security aspects for relevant aspects of software development.

Additional Information

Good to Know

The International Organization for Standardization (ISO) provides:

• in standard ISO/IEC 12207:2008, “System and software engineering – Software life cycle process,” an overview of all components of the software lifecycle,
• in standard ISO/IEC 15408-2:2008, “Information technology – Security techniques – Evaluation criteria for IT security – Part 2: Security functional components,” an overview of the possibilities for system security, and
• in standard ISO/IEC 27001:2013, “Information technology – Security techniques – Information security management systems – Requirements,” in Annex A, A.14 “System acquisition, development and maintenance,” requirements for system development and operation.

The Information Security Forum (ISF) provides in its standard “The Standard of Good Practice for Information Security” in the “Area BA Business Application Management” requirements for the management of business applications.

The National Institute of Standards and Technology provides in “NIST Special Publication 800-53” in Appendix F-SA “Family: System and Services acquisition, Family: System and communications protection and Family: System and information integrity” further requirements for handling custom software.