+APP.7 Development of Individual Software
---+APP.7.G1. Unsatisfactory Contractual Arrangements with External Service Providers
---+APP.7.G2. Software Design Errors
---+APP.7.G3. Undocumented Functions
---+APP.7.G4. Insufficient Security Safeguards in Applications
---+APP.7.G5. Inadequate Control of Software Development
---+APP.7.G6. Hiring Unsuitable Software Developers
---+APP.7.A1 Including Aspects of Individual Software in Software Deployment Planning (B)
---+APP.7.A2 Defining Security Requirements for the Software Development Process (B)
---+APP.7.A3 Specification of Security Functions for System Integration [IT Operation Department] (B)
---+APP.7.A4 Commissioning in Line with Requirements [Procurement Department] (B)
---+APP.7.A5 Appropriate Control of Application Development (S)
---+APP.7.A6 Documentation of Individual Software Requirements (S)
---+APP.7.A7 Secure Acquisition of Individual Software (S)
---+APP.7.A8 Early Involvement of the Process Owner in Development-Related Software Tests (S)
---+APP.7.A9 Trusted Storage (H)
---+APP.7.A10 Commissioning Certified Software Development Companies (H)
|
APP.7 Development of Individual Software
IntroductionMany organisations faced challenges that they can no longer adequately solve with unadapted software. The tasks associated with these challenges often require software solutions that are tailored to an organisation's individual needs. In this module, these software solutions are referred to as individual software. One variant involves implementing basic solutions that comprise a set of typical functions and then customising them. The basic functions are adapted to an organisation's specific purposes and supplemented by individually required functions. Common examples of this involve IT applications such as enterprise resource planning (ERP) systems, content management systems (CMS), or identity management (IDM) systems. Individual software can also be developed entirely from scratch by an organisation or third parties. This includes applications for business process control or individually adapted specialised applications, such as personnel management software or procedures for managing social data or registration data. It is essential that the required security functions be considered during the planning and design of individual software and that information security be taken into account throughout the entire lifecycle. It can take a great deal of additional effort (or be impossible) to compensate for planning errors or missing security functions during live operations. Individual software is usually developed as part of a project. A wide variety of process and project management models have been established for this purpose. While classic, linear process models such as the waterfall process are very well suited to projects with fixed requirements at the beginning, agile procedure models such as Scrum enable individual software to be developed iteratively and incrementally. Agile procedure models can thus adapt better to changing circumstances, especially if not all requirements are fixed at the beginning. However, they do not offer the same costing certainty as linear procedure models and in some cases do not fit the classic structures of procurement processes, which are geared towards a linear approach. ObjectiveThe aim of this module is to cover the basic security requirements to be considered when planning and developing individual software. Scoping and ModellingModule APP.7 Development of Individual Software must be applied once to each development of individual software. Aspects of planning, designing, and using individual software, such as defining required security functions or decommissioning such software, are covered in APP.6 General Software. It should therefore always be used in conjunction with this module. Software development very often involves a client-contractor relationship. This situation is reflected in IT-Grundschutz in that the APP.7 Development of Individual Software module deals with the client side, while CON.8 Software Development module covers the contractor side. The release and testing of individual software are covered in module OPS.1.1.6 Software Tests and Approvals. Useful ResourcesThe International Organization for Standardization (ISO) provides the following: - An overview of all components in the software lifecycle in the norm ISO/IEC 12207:2008, “System and Software Engineering – Software Life Cycle Process”
- An overview of the options for system security in the standard ISO/IEC 15408-2:2008, “Information Technology – Security Techniques – Evaluation Criteria for IT Security – Part 2: Security Functional Components”
- Requirements for system development and operation in the standard ISO/IEC 27001:2013, “Information Technology – Security Techniques – Information Security Management Systems – Requirements” (annex A, A.14, "System Acquisition, Development and Maintenance")
In its standard "The Standard of Good Practice for Information Security", the Information Security Forum (ISF) sets requirements for the management of business applications in "Area BA Business Application Management". In “NIST Special Publication 800-53” (appendix F-SA, “Family: System and Services Acquisition, Family: System and Communications Protection, and Family: System and Information Integrity”), the National Institute of Standards and Technology specifies further requirements for handling individual software.
1. Oversigt
| Titel |
Standard |
|
APP.7.A1 Including Aspects of Individual Software in Software Deployment Planning (B)
|
The planning of software deployment MUST be extended to include aspects of individual software by defining the following: - Who is responsible for managing and coordinating the software development or the contractor
- The organisational framework in which the software is to be developed (project management model)
Individual software SHOULD be developed within the framework of a development project. A schedule SHOULD be drawn up to plan the approximate timing of the development project.
|
|
APP.7.A2 Defining Security Requirements for the Software Development Process (B)
|
An organisation MUST define clear requirements for the software development process. The requirements MUST specify the environment in which software may be developed and the technical and organisational safeguards to be implemented by contracted software developers.
|
|
APP.7.A3 Specification of Security Functions for System Integration [IT Operation Department] (B)
|
The IT Operation Department and Process Owners MUST establish requirements for the technical operational environment of planned individual software and coordinate them with software development. The requirements MUST clearly state the use of the application in question in terms of: - type of hardware platform
- type of software platform (including the entire software stack)
- available resources (e.g. CPU cluster or RAM)
- interfaces with other systems
- security functions resulting from the above aspects
Interfaces with other IT systems SHOULD be modelled and defined in standardised technical formats.
|
|
APP.7.A4 Commissioning in Line with Requirements [Procurement Department] (B)
|
If individual software is developed by an organisation or commissioned externally, the following issues in particular MUST be used as a basis for software development in addition to the existing legal and organisational requirements: - the catalogue of requirements (see APP.6 General Software)
- the security requirements for the software development process
- the security functions for system integration
|
|
APP.7.A5 Appropriate Control of Application Development (S)
|
An appropriate control and project management model SHOULD be used when developing individual software. In this regard, the selected model SHOULD be agreed with the contractor and considered in terms of controlling. Whether the required staff are adequately qualified SHOULD be considered in particular. All the relevant phases SHOULD be covered during the lifecycle of the software. It SHOULD also include an appropriate development model, risk management, and quality objectives.
|
|
APP.7.A6 Documentation of Individual Software Requirements (S)
|
The requirements from the requirements catalogue, the security requirements for the software development process, and the security functions for system integration SHOULD be comprehensively documented. In particular, a security profile SHOULD be created for the application in question. This SHOULD document the protection needs of the functions and data to be processed. The documentation, including the security profile, SHOULD be made available to the software developers. The documentation SHOULD be updated in the event of changes to the individual software or related functional updates.
|
|
APP.7.A7 Secure Acquisition of Individual Software (S)
|
A development project SHOULD be commissioned within the framework of the most suitable project management model. Security aspects SHOULD be taken into account during the tendering and awarding process to ensure the following: - only suitable contractors are commissioned
- no wide-ranging conclusions about the organisation's security architecture can be drawn from publicly available information
The organisation SHOULD have defined processes and specified contact persons to ensure that the relevant framework conditions are considered.
|
|
APP.7.A8 Early Involvement of the Process Owner in Development-Related Software Tests (S)
|
The Process Owner SHOULD be involved in the software developers’ tests early on in the development process (before final acceptance). This SHOULD be agreed in the project schedule in coordination with the contractor from the start.
|
|
APP.7.A9 Trusted Storage (H)
|
Checks SHOULD be carried out on whether business-critical applications are protected against manufacturer outages. For this purpose, materials and information not included in the scope of delivery of the application in question SHOULD be placed in trust—for example, with an escrow agency. Documented code, design plans, keys, and passwords SHOULD be included in this. The escrow agency's obligations regarding deposit and release SHOULD be contractually regulated. It SHOULD be clarified when deposits may be released and to whom.
|
|
APP.7.A10 Commissioning Certified Software Development Companies (H)
|
Certified software developers SHOULD be commissioned to develop any particularly security-critical applications. Their certification SHOULD include security considerations for relevant aspects of software development.
|
1.1 Referencer
1.2 Identificerede krav
1.3 Relaterede reguleringer
2. Identificerede krav
3. Relaterede reguleringer
Reguleringer
| Kilde |
Regulering |
Linkede sager
|