chrisbst48/IT-Grundschutz-Compendium_2022_EN huggingface dataset:
APP.6.A8 Regulation of the Availability of Installation Files (S)
The IT Operation Department SHOULD ensure the availability of installation files so that the installation process can be reproduced. To this end, the IT Operation Department SHOULD do one of the following: • Secure the installation files appropriately • Ensure that the installation files will continue to be available from the source in question (e.g. the corresponding app store) This regulation SHOULD be integrated into the respective organisation's data backup concept.
APP.6.A9 Taking Inventory of Software (S)
Software SHOULD be inventoried. An inventory SHOULD document the systems on which software is used and under which licence. If necessary, the security-relevant settings SHOULD also be documented. Software SHOULD only be used with licences that correspond to the intended use and the respective contractual provisions. Each licence SHOULD cover the entire intended period of use of the corresponding software. If there is a deviation from a default configuration, this SHOULD be documented. The inventory SHOULD be updated by the IT Operation Department as necessary, especially when software is installed. The inventory SHOULD be structured in such a way that a quick overview of the necessary details is possible if there are any security incidents.
APP.7 Development of Individual Software
Target Object: Information domain/generic aspects / Order: R3
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.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.
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.
CON.1 Crypto Concept R3 Information domain/generic aspects
Target Object: Information domain/generic aspects / Order: R3
CON.1.A1 Selecting Appropriate Cryptographic Methods [Process Owner] (B)
Appropriate cryptographic methods MUST be selected. In so doing, it MUST be ensured that established algorithms are used that have been examined intensively by experts and do not have any known vulnerabilities. The key lengths recommended at the time MUST also be used.
CON.1.A10 Developing a Crypto Concept (H)
A crypto concept SHOULD be developed that is integrated into the security concept of the organisation in question. The concept SHOULD describe all the technical and organisational specifications for the cryptographic products used. Additionally, all the relevant applications, IT systems, and communication links SHOULD be listed. The created crypto concept SHOULD be updated at regular intervals.
CON.1.A11 Secure Configuration of Crypto Modules [IT Operation Department] (H)
Crypto modules SHOULD be installed and configured securely. All preset keys SHOULD be changed. Afterwards, whether the crypto modules work properly and can actually be operated by users SHOULD be tested. Furthermore, the requirements for the operational environment SHOULD be defined. If an IT system is changed, whether the cryptographic methods used are still effective SHOULD be tested. The configuration of the crypto modules SHOULD be documented and checked at regular intervals.
CON.1.A12 Secure Separation of Roles When Using Crypto Modules [IT Operation Department] (H)
User roles SHOULD be defined when configuring a crypto module. Access control and authentication mechanisms SHOULD be used in order to verify whether an employee is actually allowed to use the desired service. The crypto module SHOULD be configured such that the authentication information has to be re-entered every time there is a role change or a specified period of inactivity as passed.
CON.1.A13 Operating System Security Requirements When Using Crypto Modules (H)
The interaction between the operating system and the crypto modules SHOULD ensure the following: • The crypto modules installed cannot be disabled or circumvented without this being noticed. • The applied or stored keys cannot be compromised. • The data to be protected can only be stored on storage media without encryption or leave the information-processing system with the knowledge of and under the control of the user. • Attempted manipulations of the crypto module will be detected.
CON.1.A14 Training of Users and Administrators [Supervisor, Process Owner, IT Operation Department] (H)
There SHOULD be training for users and administrators on handling the relevant crypto modules. The meaning of the security settings of crypto modules and why they are important SHOULD be explained in detail to the users. In addition, they SHOULD be made aware of the dangers of bypassing or disabling these security settings for the sake of convenience. The training content SHOULD always be adapted to the particular operational scenarios at hand. Administrators SHOULD also receive specific training on the administration of crypto modules. They SHOULD also be provided with an overview of basic cryptographic terms.
CON.1.A15 Reacting to the Practical Weakening of a Crypto Method (H)
A process SHOULD be established that can be used in the event of a weakened cryptographic method. In so doing, it SHOULD be ensured that the weakened cryptographic method can be secured or will be replaced with an appropriate alternative.
CON.1.A16 Physical Protection of Crypto Modules [IT Operation Department] (H)
The IT Operation Department SHOULD ensure that unauthorised physical access to the contents of a crypto module is prevented. Hardware and software products used as crypto modules SHOULD be able to perform a self-test.
CON.1.A17 Emission Security [IT Operation Department] (H)
Whether additional safeguards are necessary for emission security SHOULD be examined. In particular, this SHOULD be ensured when processing government material that is classified as VS-VERTRAULICH (VS-CONFIDENTIAL) or higher.
CON.1.A18 Cryptographic Replacement Modules [IT Operation Department] (H)
Replacement crypto modules SHOULD be kept available.
CON.1.A2 Backups When Using Cryptographic Methods [IT Operation Department] (B)
In backups, cryptographic keys MUST be stored and kept by the IT Operation Department in such a way that unauthorised persons cannot access them. Long-term cryptographic keys MUST be stored outside of the IT systems used. For long-term storage of encrypted data, checks SHOULD be performed at regular intervals to determine whether the cryptographic algorithms and key lengths used still reflect the state of the art. The IT Operation Department MUST guarantee that data stored in encrypted form can still be accessed after longer periods. The crypto products used SHOULD be archived. The configuration data of crypto products SHOULD be backed up.
CON.1.A3 Encryption of Communication Links (S)
It SHOULD be determined whether communication links can be encrypted in a feasible manner with a reasonable amount of resources. If this is the case, communication links SHOULD be encrypted appropriately.
CON.1.A4 Appropriate Key Management (S)
Cryptographic keys SHOULD always be created with appropriate key generators in a secure environment. If possible, cryptographic keys SHOULD be used for one purpose only. In particular, different keys SHOULD be used for encryption and signature creation. The exchange of cryptographic keys SHOULD be carried out using a method that is considered secure. If keys are used, the authenticity of the origin and integrity of the key data SHOULD be checked. All cryptographic keys SHOULD be changed at a sufficient frequency. There SHOULD be a defined procedure for scenarios in which a key has been revealed. All created cryptographic keys SHOULD be stored and managed securely.
CON.1.A5 Secure Deletion and Destruction of Cryptographic Keys [IT Operation Department] (S)
Keys and certificates that are no longer needed SHOULD be deleted and destroyed securely.
CON.1.A6 Identifying the Need for Cryptographic Methods and Products [IT Operation Department, Process Owner] (S)
The business processes or specialised procedures that require cryptographic methods SHOULD be defined. The applications, IT systems, and communication links necessary to fulfil the tasks at hand SHOULD then be identified. The IT Operation Department SHOULD use suitable cryptographic mechanisms to secure these elements.
CON.1.A7 Drawing Up a Security Policy for the Use of Cryptographic Methods and Products (H)
Based on its general security policy, an organisation SHOULD draw up a specific policy for the use of crypto products. In this security policy, the person responsible for the secure operation of cryptographic products SHOULD be specified. There SHOULD be deputising rules in connection with the crypto products used. Necessary training and awareness safeguards SHOULD be defined for users, along with codes of conduct and reporting channels for potential problems or security incidents. Furthermore, the policy SHOULD define the methods used to ensure that crypto modules are configured securely, used properly, and maintained at regular intervals. The policy SHOULD be known to all the relevant employees and SHOULD be integral to their work. If the policy is changed or deviations prove necessary, this SHOULD be coordinated with the CISO and documented accordingly. There SHOULD be regular checks on whether the policy is still being properly implemented. The results SHOULD be appropriately documented.
CON.1.A8 Determining the Factors That Influence Cryptographic Methods and Products (H)
Before a decision can be taken on which cryptographic methods and products will be used in the event of high protection requirements, the following influencing factors SHOULD be determined, among other considerations: • Security aspects (see CON.1.A6 Identifying the Need for Cryptographic Methods and Products) • Technical aspects • Personnel and organisational aspects • Economic aspects • The lifecycles of cryptographic methods and the key lengths used • Approval of cryptographic products • Legal framework conditions
CON.1.A9 Selecting an Appropriate Cryptographic Product [IT Operation Department, Process Owner] (H)
Before selecting a cryptographic product, an organisation SHOULD define the requirements to be met by the product. Here, aspects such as the scope of functions, interoperability, efficiency, and protection against incorrect operation and malfunction SHOULD be considered. It SHOULD be checked whether certified products should be given priority. The selection process SHOULD also consider the future deployment locations due to the export and import restrictions on cryptographic products, for example. As a general rule, products that do not make it possible to control the storage of keys SHOULD NOT be used.
CON.10 Development of Web Applications R2 Information domain/generic aspects
Target Object: Information domain/generic aspects / Order: R2
CON.10.A1 Authentication for Web Applications (B)
Developers MUST ensure that users securely and appropriately authenticate themselves to a web application before they can access protected functions or content. An appropriate authentication method MUST be selected. The selection status MUST be documented. A central authentication component MUST be used. The central authentication component SHOULD be used with established standard components (e.g. from frameworks or program libraries). If a web application stores authentication data on a client, the user MUST be explicitly informed about the risks of this function and consent to it (“opt-in”). The web application MUST offer the option to set limits for failed login attempts. The web application MUST inform users immediately if their password has been reset.
CON.10.A10 Restrictive Disclosure of Security-Related Information (B)
Developers MUST ensure that web pages, responses, and error messages from web applications do not contain information that would provide an attacker with insights into how to bypass corresponding security mechanisms.
CON.10.A11 Software Architecture of a Web Application (S)
Developers SHOULD document the software architecture of web applications with all their components and dependencies. The documentation SHOULD be updated and adapted during the development process. The documentation SHOULD be designed so that it can be used in the development phase and the decisions taken will be traceable. The documentation SHOULD identify all the components necessary for operation that are not part of the respective web application. The documentation SHOULD also describe which components implement which security mechanisms, how the web application is to be integrated into an existing infrastructure, and which cryptographic functions and procedures are used.
CON.10.A12 Verification of Essential Changes (S)
If important settings are to be changed with an application, the Developers SHOULD ensure that the changes are verified again by entering a password. If this is not possible, the web application SHOULD ensure that users authenticate themselves by other appropriate means. Users SHOULD be informed of changes via communication channels outside the web application.
CON.10.A13 Error Handling (S)
If errors occur during the runtime of a web application, the Developers SHOULD handle them so that the web application remains in a consistent state. The web application SHOULD log error messages. If an initiated action causes an error, the web application SHOULD cancel that action. If an error occurs, the web application SHOULD deny access to a requested resource or function. Previously reserved resources SHOULD be released within the framework of error handling. The error SHOULD be handled by the web application itself whenever possible.
CON.10.A14 Secure HTTP Configuration of Web Applications (S)
To protect against clickjacking, cross-site scripting, and other attacks, Developers SHOULD set appropriate HTTP response headers. The following HTTP headers SHOULD be used at minimum: Content-Security-Policy, Strict-Transport-Security, Content-Type, X-Content-Type-Options, and Cache-Control. The HTTP headers used SHOULD be adapted to the web application at hand. The HTTP headers used SHOULD be as restrictive as possible. Cookies SHOULD always be set with the attributes secure, SameSite, and httponly.
CON.10.A15 Prevention of Cross-Site Request Forgery (S)
Developers SHOULD equip web applications with the security mechanisms required to distinguish between users' intended page requests and unintentionally forwarded third-party commands. At minimum, whether a secret token is required in addition to the session ID for access to protected resources and functions SHOULD be checked.
CON.10.A16 Multi-Factor Authentication (S)
Developers SHOULD implement multi-factor authentication.
CON.10.A17 Preventing Resources from Being Blocked (H)
As protection against denial-of-service (DoS) attacks, resource-intensive operations SHOULD be avoided. Where resource-intensive operations are necessary, a particular effort SHOULD be made to secure them. For web applications, potential overflows of log data SHOULD be monitored and prevented.
CON.10.A18 Cryptographic Protection of Confidential Data (H)
Developers SHOULD ensure that a web application's confidential data is protected by secure cryptographic algorithms.
CON.10.A2 Access Control for Web Applications (B)
An authorisation component MUST be used by the Developer to ensure that users can only perform actions for which they are authorised. Every attempt to access protected content and functions MUST be checked before being allowed. The authorisation component MUST consider all the resources and content administered by the web application. If the corresponding access control system is defective, access MUST be denied. Access control MUST also be in place for URL calls and object references.
CON.10.A3 Secure Session Management (B)
Developers MUST ensure that session IDs are protected appropriately. Session IDs MUST be generated randomly and with sufficient entropy. If the web application framework can generate secure session IDs, the Developers MUST use this feature of the framework. The security-relevant configuration options of the framework MUST be considered. If session IDs are transmitted and stored by the clients, they MUST be transmitted with sufficient protection. A web application MUST provide users with the option to expressly terminate an active session. After a user has logged in, any existing session ID MUST be replaced by a new one. Sessions MUST have a maximum validity period (timeout). Inactive sessions MUST automatically expire after a specified period of time. After a session has become invalid, all the session data MUST be rendered invalid and deleted.
CON.10.A4 Controlled Integration of Content in Web Applications (B)
Developers MUST ensure that a web application only integrates designated data and content for delivery to the user. The destinations of the redirection function of a web application MUST be restricted sufficiently so that users are only redirected to trustworthy websites. If a user is leaving the trustworthy domain, the web application MUST inform them of this.
CON.10.A5 Upload Functions (B)
Developers MUST ensure that a user can only save files under the specified path. Developers MUST ensure that a user cannot influence the storage location for uploads. Developers MUST integrate functions into a web application that allow the subsequent operator of the web application to configure uploads.
CON.10.A6 Protection Against Unauthorised Automated Use of Web Applications (B)
Developers MUST implement security mechanisms that protect web applications from automated access. When implementing the security mechanisms, Developers MUST consider how they affect the usability of authorised users.
CON.10.A7 Protection of Confidential Data (B)
Developers MUST ensure that confidential data is transferred from clients to servers using only the HTTP post method. Developers MUST use directives in web applications to ensure that no sensitive data is cached on the client side. Developers MUST ensure that no confidential form data is displayed in plain text in forms. A web application SHOULD prevent confidential data from being stored unexpectedly by the web browser. All web application access data MUST be protected against unauthorised access on the server with the help of cryptographic algorithms (salted hash). The files containing the source code of a web application MUST be protected against unauthorised retrieval.
CON.10.A8 Comprehensive Input Validation and Output Encoding (B)
Developers MUST treat all data passed to a web application as potentially dangerous and filter it appropriately. All input data, as well as data streams and secondary data (such as session IDs), MUST be validated on the server side. The automatic handling of erroneous input SHOULD be minimised (through sanitising) to the greatest extent possible. If this is unavoidable, sanitising MUST be implemented securely. Output data MUST be encoded so that malicious code is not interpreted or executed on the target system.
CON.10.A9 Protection Against SQL Injections (B)
If data is passed to a database management system (DBMS), Developers MUST use stored procedures or prepared SQL statements. If data is passed to a DMBS and neither stored procedures nor prepared SQL statements are supported by the operational environment, the SQL queries MUST be secured separately
CON.2 Data Protection R2 Information domain/generic aspects
Target Object: Information domain/generic aspects / Order: R2