chrisbst48/IT-Grundschutz-Compendium_2022_EN huggingface dataset:
CON.8.A11 Drawing Up a Policy for Software Development (S)
A software development policy SHOULD be created and kept up to date. In addition to naming conventions, the policy SHOULD contain specifications for elements that may or may not be used. The relevant requirements from this module SHOULD be included in the policy. The policy SHOULD be binding for Developers.
CON.8.A12 Detailed Documentation (S)
Sufficient project, function, and interface documentation SHOULD be created and kept up to date. Operational documentation SHOULD include concrete security instructions for administrators on the installation, configuration, and use of the product in question. Software development SHOULD be documented in such a way that a technical expert can understand and further develop the program code with the help of the documentation. The documentation SHOULD also include the software architecture and threat modelling. Aspects related to documentation SHOULD be considered in the process models used for software development.
CON.8.A14 Training Development Teams on Information Security (S)
Developers and other members of a development team SHOULD be trained on general information security aspects and on the aspects specifically relevant to them, including: • Requirements analysis • Project management in general, as well as with regard to software development in particular • Risk management and threat modelling in software development • Quality management and quality assurance • Models and methods of software development • Software architecture • Software testing • Change management • Information security, the security policies of the organisation in question, and security aspects in special areas
CON.8.A16 Appropriate Control of Software Development (S)
Software development SHOULD follow a suitable control or project management model based on the selected process model. The control or project management model SHOULD be integrated into the software development policy in question. In this regard, the required personnel qualifications and the coverage of all relevant phases during the lifecycle of the software SHOULD be considered in particular. A suitable system of risk management SHOULD be established for the process model. Appropriate quality objectives SHOULD also be defined for each development project.
CON.8.A17 Selection of Trusted Development Tools (H)
Only tools with proven security properties SHOULD be used to develop software. Sufficient requirements SHOULD be imposed on hardware or software manufacturers with regard to the security of their tools.
CON.8.A18 Periodic Security Audits of the Development Environment (H)
Regular security audits SHOULD be performed on environments used for software development and testing.
CON.8.A19 Regular Integrity Audits of the Development Environment [IT Operation Department] (H)
The integrity of a development environment SHOULD be checked regularly with cryptographic mechanisms in line with the current state of the art. The deployed test program itself and its checksum files SHOULD be adequately protected against manipulation. Important information indicating a loss of integrity SHOULD not be lost in a sea of false positives.
CON.8.A2 Selection of a Process Model (B)
A suitable process model must be defined for software development. Based on the process model selected, a flow chart for software development MUST be created. In cases involving commissioned development, the client's security requirements for the process MUST be integrated into the process model. The selected process model, including the specified security requirements, MUST be followed. Staff SHOULD be trained in the methodology of the selected process model.
CON.8.A20 Checking External Components (B)
Unknown external components (or program libraries) whose security cannot be ensured by established and recognised peer reviews or comparable means MUST be checked for vulnerabilities. All external components MUST be checked for potential conflicts. The integrity of external components MUST be verified by checksums or cryptographic certificates. Furthermore, obsolete versions of external components SHOULD not be used in current development projects.
CON.8.A21 Threat Modelling (S)
Threat modelling SHOULD be undertaken during the design phase of software development. For this purpose, potential threats SHOULD be identified on the basis of the relevant security profile, the catalogue of requirements, and the planned operational environment or operational scenario. The threats SHOULD be assessed in terms of their probability and impact.
CON.8.A22 Secure Software Design (S)
Software design SHOULD take into account the applicable requirements catalogue, the security profile, and the results of threat modelling. As part of secure software design, a secure software architecture SHOULD be assembled as the basis for developing the source code of the application in question. Future standards and attack techniques SHOULD be taken into account as far as possible so that the software to be developed can also be easily maintained in the future.
CON.8.A3 Selection of a Development Environment (B)
A list of required and optional selection criteria for a development environment MUST be provided by the Process Owner for software development. The development environment MUST be selected based on the criteria specified.
CON.8.A5 Secure System Design (B)
The following basic rules of secure system design MUST be considered in the software to be developed: • All input data MUST be checked and validated before further processing takes place. • For client-server applications, the data MUST be validated on the server side. • The software's default settings MUST be set to facilitate secure operation. • In the event of errors in or failures of system components, sensitive information MUST NOT be disclosed. • It MUST be possible to run the software with as few privileges as possible. • Sensitive data MUST be transmitted and stored in encrypted form according to the specifications of the crypto concept at hand. • Trusted mechanisms that meet the security requirements of the application in question MUST be used for user authentication and access. • If passwords are stored for authentication, they MUST be stored using a secure hash procedure. • Security-relevant events MUST be logged in such a way that they can be evaluated afterwards. • Information that is not relevant for productive operation (e.g. comments with access data for the development environment) SHOULD be removed in delivered program code and delivered configuration files. The system design MUST be documented. It MUST be verified that the system design meets all the relevant security requirements.
CON.8.A6 Use of External Libraries from Trusted Sources (B)
If external libraries are used as part of the development and implementation process, they MUST be obtained from trusted sources. Before external libraries are used, their integrity MUST be ensured.
CON.8.A7 Conducting Software Tests During Development [Tester, Developer] (B)
Even before software is tested and approved in the approval process, software tests MUST be performed and the source code checked for errors during development. The Process Owner of the client or department that has commissioned the development SHOULD be involved. The tests carried out during development MUST cover the functional and non-functional requirements of the software. The software tests MUST include negative tests, as well. In addition, all critical limits on input and data types MUST be checked. Test data SHOULD be carefully selected and protected for this purpose. Furthermore, automatic static-code analysis SHOULD be performed. The software MUST be tested in a test and development environment that is separate from the production environment. Furthermore, tests MUST be carried out on whether the system requirements are sufficiently dimensioned for the intended software.
CON.8.A8 Provision of Patches, Updates, and Changes [Developer] (B)
It MUST be ensured that security-critical patches and updates for developed software are provided in a timely manner by the Developers. If security-critical updates are provided for external libraries in use, the Developers MUST adapt their software to this and provide corresponding patches and updates. The Developers MUST provide checksums or digital signatures for installation, update, or patch files.
CON.9 Information Exchange R3 Information domain/generic aspects
Target Object: Information domain/generic aspects / Order: R3
CON.9.A1 Definition of Authorised Recipients [Central Administration, Users] (B)
The Central Administration MUST ensure that the disclosure of information does not violate any related legal frameworks. The Central Administration MUST define which recipients are allowed to receive and share which information. The channels through which the respective information may be exchanged MUST be defined. Before exchanging information, each employee MUST ensure that the recipient has the necessary authorisations to receive and process the information.
CON.9.A2 Regulating the Exchange of Information [Central Administration, User] (B)
Before information is exchanged, the information owner MUST determine its level of sensitivity. The information owner MUST determine how to protect the information during transmission. If sensitive information is being transmitted, the information owner MUST inform the recipient about its level of sensitivity. If the information is sensitive, the information owner MUST also inform the recipient that they may only use the information for the purpose for which it was transmitted.
CON.9.A3 Instruction of Personnel on Exchanges of Information [Process Owner] (B)
The Process Owner MUST inform all the relevant employees about the framework conditions for each information exchange. The Process Owner MUST ensure that the employees know what information they can pass on, as well as when, where, and how.
CON.9.A4 Agreements on Exchanging Information with External Parties [Central Administration] (S)
If information is regularly exchanged with other organisations, the organisation in question SHOULD formally agree on a corresponding framework. This information exchange agreement SHOULD include information on the protection of all confidential information.
CON.9.A5 Removal of Residual Information Prior to Sharing [User] (S)
In addition to general training, an organisation SHOULD inform its users about the dangers of residual and additional information in documents and files. The users SHOULD be taught how to avoid residual and additional information in documents and files. The organisation SHOULD instruct each user on how to exclude unwanted residual information from exchanges of information. Users SHOULD check each file and document for unwanted residual information before sharing it. Users SHOULD remove unwanted residual information from documents and files.
CON.9.A6 Compatibility Checks on Sender and Recipient Systems (S)
Before exchanging information, the compatibility of the sender and receiver IT systems and products SHOULD be checked.
CON.9.A7 Backup Copies of Transferred Data [User] (S)
Users SHOULD make a backup copy of transmitted information in case the information cannot be restored from other sources.
CON.9.A8 Encryption and Digital Signatures (S)
An organisation SHOULD check whether information can be cryptographically secured during an exchange. If information is to be cryptographically secured, sufficiently secure procedures SHOULD be used for this purpose.
CON.9.A9 Confidentiality Agreements [Central Administration, User] (H)
Before disclosing confidential information to external parties, the user SHOULD inform the Central Administration. The Central Administration SHOULD conclude a confidentiality agreement with the recipients in question. The confidentiality agreement SHOULD regulate how the information may be kept on the receiving side. The confidentiality agreement SHOULD specify who on the receiving side may have access to which transmitted information.
DER.1 Detecting Security-Relevant Events
Target Object: Information domain/generic aspects / Order: R2
DER.1.A1 Creation of a Security Policy for the Detection of Security-Relevant Events (B)
Based on the general security policy of the organisation in question, a specific security policy MUST be drawn up for detecting security-relevant events. This specific security policy MUST comprehensibly describe requirements and specifications on how to plan, set up, and safely operate methods of detecting security-relevant events. This specific security policy MUST be known to all employees responsible in the field of detection and serve as the basis of their work. If the specific security policy is changed or there are deviations from its requirements, this MUST be agreed and documented with the responsible CISO. The correct implementation of this specific security policy MUST be regularly reviewed. The results of the checks MUST be documented in a meaningful way.
DER.1.A10 Use of TLS/SSH Proxies [Process Owner] (S)
At transitions to external networks, TLS/SSH proxies SHOULD be used to interrupt encrypted connections and make it possible to check the data being transmitted for malware. All TLS/SSH proxies SHOULD be protected against unauthorised access. Security-relevant events SHOULD be detected automatically on TLS/SSH proxies. An organisational regulation SHOULD be drawn up that specifies how log data can be evaluated manually in accordance with the provisions of data protection law.
DER.1.A11 Use of a Central Logging Infrastructure to Evaluate Security-Relevant Events [Process Owner] (S)
Event messages that are generated by IT systems and applications and stored on a central logging infrastructure (see OPS.1.1.5 Logging) SHOULD be retrievable using a tool. The selected tool SHOULD be able to analyse the messages. The collected event messages SHOULD be checked for anomalies at regular intervals. The signatures of the detection systems used SHOULD always be identically up to date so that security-relevant events can also be detected retrospectively.
DER.1.A12 Evaluation of Information from External Sources [Process Owner] (S)
External sources SHOULD be used to gain new insights into security-relevant events that could impact an organisation’s own information domain. Messages from different channels SHOULD be recognised as relevant by employees and forwarded to the correct recipients. Information from reliable sources SHOULD be evaluated as a general rule. All information received SHOULD be evaluated in terms of whether it is relevant to the organisation's own information domain. If this is the case, the information SHOULD be escalated in line with security incident handling.
DER.1.A13 Regular Audits of Detection Systems (S)
An organisation's detection systems and safeguards SHOULD be audited regularly to check whether they are still up to date and effective. The values assessed SHOULD include those that indicate how often security-relevant events are recorded, reported, and escalated. The results of the audits SHOULD be documented transparently and compared against the organisation's goals. Deviations SHOULD be investigated.
DER.1.A14 Evaluation of Log Data by Specialised Personnel (H)
Employees SHOULD be specially assigned to monitor all types of log data. The monitoring of log data SHOULD be the predominant task of the appointed employees. The appointed employees SHOULD receive specialised further training and qualifications. A group of persons SHOULD be appointed to be exclusively responsible for the evaluation of log data.
DER.1.A15 Central Detection and Real-Time Examination of Event Messages (H)
Central components SHOULD be used to detect and evaluate security-relevant events. Centralised, automated analyses SHOULD be carried out using software tools. These central, automated, software-based analyses SHOULD be used to record and correlate all the events that occur in the system environment at hand. The security-relevant processes SHOULD be transparent. It SHOULD be possible to view and evaluate all the data received in the log administration system in a seamless manner. The data SHOULD be analysed as constantly as possible. If defined threshold values are exceeded, an alarm SHOULD be generated automatically. The corresponding personnel SHOULD make sure that an alarm triggers a qualified response that is appropriate to the situation at hand. In this context, the employee concerned SHOULD also be informed immediately. The persons in charge of the system SHOULD audit and (if required) adapt the analysis parameters at regular intervals. In addition, data that has already been audited SHOULD be examined automatically for security-relevant events at regular intervals.
DER.1.A16 Use of Detection Systems in Accordance with Protection Requirements (H)
Applications with higher protection needs SHOULD be protected by means of additional detection safeguards. To this end, detection systems SHOULD be used that also make it possible to guarantee that higher protection needs are being met from a technical perspective.
DER.1.A17 Automatic Reaction to Security-Relevant Events (H)
Should a security-relevant event occur, the detection systems used SHOULD automatically report the event and react with appropriate security safeguards. In the process, methods SHOULD be used that automatically detect possible attacks, misuse attempts, or security violations. It SHOULD be possible to automatically intervene in the data stream to prevent a possible security incident.
DER.1.A18 Performance of Regular Integrity Checks (H)
The integrity of all detection systems SHOULD be checked regularly. User rights SHOULD also be checked. In addition, the sensors in use SHOULD regularly check the integrity of files. An automatic alarm SHOULD be triggered if certain values change.
DER.1.A2 Compliance with Legal Conditions When Analysing Log Data (B)
When analysing log data, the provisions of current federal and state data protection law MUST be followed. If detection systems are used, employees' personal rights and rights of co-determination MUST be respected. It MUST also be ensured that all the additional legal provisions that apply are taken into consideration, such as the German Telemedia Act (TMG), the German Works Constitution Act, and the German Telecommunications Act.
DER.1.A3 Definition of Reporting Paths for Security-Relevant Events (B)
Appropriate channels for reports and alerts MUST be defined and documented for security relevant events. They MUST determine which points of contact must be informed and when. They MUST also specify how the respective persons can be reached. A security-relevant event MUST be reported using different communication channels depending on the urgency at hand. All the relevant persons with regard to reporting and alarms MUST be informed of their tasks. All the steps of the reporting and alert process MUST be described in detail. The established reporting and alarm paths SHOULD be reviewed, tested, and updated at regular intervals as required.
DER.1.A4 Raising Employee Awareness [Supervisor, User, Employee] (B)
All users MUST be instructed not to simply ignore or close the event messages displayed by their clients. Each user MUST use the prescribed alert channels to pass on messages to those responsible for incident management (see DER.2.1 Security Incident Handling). Every employee MUST immediately report a security incident they have detected to the incident management department.
DER.1.A5 Use of Detection Features Included in Systems [Process Owner] (B)
If IT systems or applications have features that can be used to detect security-relevant events, these MUST be enabled and used. If a security-relevant event occurs, the messages of the IT systems concerned MUST be evaluated. The logged events of other IT systems MUST be checked, as well. In addition, the collected messages SHOULD be checked randomly at mandatory intervals. It MUST be checked whether additional malicious code scanners should be installed on central IT systems. If additional malware scanners are used, they MUST allow their messages and logs to be evaluated through a central access point. It MUST be ensured that the malicious code scanners will automatically report security-relevant events to the responsible parties. The responsible parties MUST evaluate and investigate these messages.
DER.1.A6 Continuous Monitoring and Analysis of Log Data (S)
All log data SHOULD be actively monitored and analysed as constantly as possible. Employees SHOULD be made responsible for these activities. If the employees responsible have to actively search for security-relevant events that have occurred (e.g. when testing or monitoring IT systems), such tasks SHOULD be documented in corresponding process instructions. Sufficient personnel resources SHOULD be made available for detecting security-relevant events.
DER.1.A7 Training of Responsible Persons [Supervisor] (S)
The persons responsible for reviewing event messages SHOULD receive advanced training and qualifications. When new IT components are procured, a budget for training SHOULD be planned. A training concept SHOULD be created before the responsible staff members receive training on new IT components.
DER.1.A9 Use of Additional Detection Systems [Process Owner] (S)
The network plan in question SHOULD be used to determine which network segments need to be protected by additional detection systems. Additional detection systems and sensors SHOULD be added to the information domain. Malicious code detection systems SHOULD be used and administered from a central location. The transitions defined in the network plan between internal and external networks SHOULD be complemented by network-based intrusion detection systems (NIDS).
DER.2.1 Security Incident Handling
Target Object: Information domain/generic aspects / Order: R2
DER.2.1.A1 Definition of a Security Incident (B)
Within an organisation, the meaning of the term security incident MUST be clearly defined. A security incident MUST be distinguished from disruptions during day-to-day operations whenever possible. All employees involved in handling security incidents MUST be familiar with the definition of a security incident. The definition and occurrence thresholds of such incidents SHOULD be based on the protection needs of the business processes, IT systems, and applications affected.
DER.2.1.A10 Limiting the Effects of Security Incidents [BCM Officer, IT Operation Department] (S)
During the root cause analysis of a security incident, a decision SHOULD be taken on whether it is more important to contain the damage caused or to resolve the incident. Sufficient information SHOULD be available to be able to estimate the effects of a security incident. For certain security incident scenarios, worst-case considerations SHOULD be undertaken in advance.
DER.2.1.A11 Classification of Security Incidents [IT Operation Department] (B)
A uniform procedure SHOULD be defined for classifying security incidents and disruptions. The classification procedure for security incidents SHOULD be coordinated between security management and fault (incident) management.
DER.2.1.A12 Specification of Where Security Incident Handling Overlaps with Fault Management [BCM Officer] (S)
The interfaces among fault management, business continuity management, and security management SHOULD be analysed. In so doing, resources that these areas could use in tandem SHOULD also be defined. The employees involved in fault management SHOULD be made aware of issues related to handling security incidents and business continuity management. Security management SHOULD have read-only access to the incident management tools used.
DER.2.1.A13 Integration into Security and Business Continuity Management [BCM Officer] (S)
The handling of security incidents SHOULD also be coordinated with business continuity management. If a special fault management role has already been established in an organisation, this person SHOULD also be involved.