chrisbst48/IT-Grundschutz-Compendium_2022_EN huggingface dataset:
OPS.1.1.6 Software Tests and Approvals
Target Object: Information domain/generic aspects / Order: R1
OPS.1.1.6.A1 Planning of Software Tests (B)
Before software tests are carried out, corresponding framework conditions MUST be specified within an organisation in accordance with the protection needs, organisational units, technical possibilities, and test environments at hand. Software MUST be tested on the basis of a software requirements catalogue. If there is also a requirements specification, this MUST also be taken into account. Test cases MUST be selected in such a way that they test all the software functions at hand in the most representative way possible. In addition, negative tests SHOULD be included to ensure software does not contain any unwanted functions. The test environment MUST be selected to be as representative as possible of all the device models and operating system environments used in the organisation in question. Testing SHOULD also determine whether software is compatible and functional with the operating systems used in their present configurations.
OPS.1.1.6.A10 Drawing Up an Acceptance Plan (S)
An acceptance plan SHOULD document the test types to be performed, the test cases considered, and the expected results. Furthermore, the acceptance plan SHOULD include the corresponding approval criteria. A procedure SHOULD be defined for the possibility of approval being denied.
OPS.1.1.6.A11 Using Anonymised or Pseudonymised Test Data [Data Protection Officer, Tester] (B)
If production data containing sensitive information is used for software testing, it MUST be appropriately protected during the testing. If this data contains personal information, it must be anonymised. If references to persons could be derived from the test data, the Data Protection Officer and (if applicable) the Employee Representatives MUST be consulted.
OPS.1.1.6.A12 Performing Regression Tests [Tester] (S)
Regression testing SHOULD be performed when software has been changed. It SHOULD check whether previously existing security mechanisms and settings have been unintentionally changed by the update. Regression tests SHOULD be performed in full and include extensions and auxiliary resources. If test cases are omitted, this SHOULD be justified and documented. The test cases carried out SHOULD be documented along with their results.
OPS.1.1.6.A13 Separating the Test Environment from the Production Environment (S)
Software SHOULD only be tested in a test environment intended for this purpose. The test environment SHOULD be operated separately from the production environment. The architectures and mechanisms used in the test environment SHOULD be documented. The documentation SHOULD also specify what is to be done with the test environment once the software tests are complete.
OPS.1.1.6.A14 Performing Penetration Tests [Tester] (H)
Penetration tests SHOULD be performed as a test method for applications and/or IT systems with increased protection needs. A concept for penetration tests SHOULD be created. In addition to the deployed test methods, the concept for penetration tests SHOULD document corresponding success criteria. Penetration tests SHOULD be performed in accordance with the framework conditions of the penetration test concept. The vulnerabilities detected during penetration tests SHOULD be classified and documented.
OPS.1.1.6.A15 Verification of Installation and Related Documentation [Tester] (S)
Software installations SHOULD be checked according to the rules for installation and configuration of software (see module APP.6 General Software). If available, the installation and configuration documentation SHOULD also be checked.
OPS.1.1.6.A16 Security Vetting of Testers (H)
If testers require access to particularly sensitive information, the organisation in question SHOULD obtain evidence of their integrity and reputation. When dealing with classified material, software testers SHOULD be subjected to security vetting in line with the German Security Screening Act (SÜG). The CISO SHOULD involve the organisation's Confidentiality Officer or Security Representative in this regard.
OPS.1.1.6.A2 Performing Functional Software Tests [Tester] (B)
Functional software tests MUST verify the proper and complete functioning of software. Functional software tests MUST be performed in a manner that will not impact production operations.
OPS.1.1.6.A3 Assessing Test Results [Tester] (B)
The results of software tests MUST be assessed. A gap analysis SHOULD be performed using the defined specifications. Such assessments MUST be documented.
OPS.1.1.6.A4 Software Approval [Process Owner] (B)
The technical organisational unit responsible MUST approve software as soon as it has passed corresponding tests. The approval MUST be documented by means of an approval confirmation. The approving organisational unit MUST verify whether the software has been tested in accordance with the relevant requirements. The results of the software tests MUST match the previously specified expectations. It MUST also be verified that the legal and organisational requirements at hand have been met.
OPS.1.1.6.A5 Performing Software Tests for Non-Functional Requirements [Tester] (B)
Software tests MUST be performed to verify that all essential non-functional requirements are met. In particular, security-specific software tests MUST be performed if the application in question includes security-critical functions. The test cases carried out MUST be documented along with their results.
OPS.1.1.6.A6 Orderly Instruction of Software Testers [Process Owner] (S)
The IT Operation Department SHOULD inform software testers of the test types to be performed and the software areas to be tested. Furthermore, the software testers SHOULD be informed of the use cases and possible further requirements of the software.
OPS.1.1.6.A7 Selecting Software Testers [Human Resources Department, Process Owner] (S)
Particular selection criteria SHOULD be considered when selecting software testers. Software testers SHOULD have the required professional qualifications. If individual software is to be reviewed at the source code level, the testers SHOULD have sufficient expertise in the programming language and development environment to be tested. The source code SHOULD NOT be reviewed exclusively by testers who were involved in the creation of the source code.
OPS.1.1.7 System Management
Target Object: Information domain/generic aspects / Order: R2
OPS.1.1.7.A1 Specification of System Management Requirements (B)
Requirements for system management infrastructure and processes MUST be specified. In so doing, all the essential elements of system management MUST be taken into account. The security aspects of system management MUST also be considered from the start.
In addition, the interfaces of the IT systems to be managed MUST be documented, in part to ensure the compatibility of the system management solution at hand and the system(s) to be managed.
OPS.1.1.7.A10 Concept for Secure Operation of the System Management Solution (S)
Based on the security policies and the system management concept at hand, a concept SHOULD be drawn up for the secure operation of the system management solution and the underlying infrastructure.
The manner in which the performance of other operative units can be integrated and controlled SHOULD also be checked.
OPS.1.1.7.A11 Regular Gap Analysis Within the Framework of System Management (S)
The IT Operation Department SHOULD regularly check the extent to which the data, configurations, and scripts managed by the system management solution correspond to the target state. At minimum, the following aspects SHOULD be checked in the gap analysis:
-The configuration of the system management solution
-The configuration of the systems to be managed
-The automation functions or scripts used
In the process, whether the aspects listed still meet the security policy and requirements specification SHOULD be reviewed. A comparison SHOULD also be made to determine whether the software version of the system management solution is up to date.
OPS.1.1.7.A12 Triggering Actions by the Central Components of the System Management Solution (S)
Actions performed by a system management solution on the systems managed SHOULD be triggered exclusively by the system management solution. For this purpose, only those management functions of the system management solution and the systems to be managed that are actually needed SHOULD be activated.
OPS.1.1.7.A13 Commitment to the Use of Designated Interfaces for System Management (S)
Management access to systems to be managed SHOULD only be obtained through the designated interfaces of the respective system management solution. If direct access is necessary to the systems to be managed (e.g. after a failure of one of these systems), both the direct access and all changes made in this context SHOULD be documented and entered into the system management solution to the extent necessary.
OPS.1.1.7.A14 Central Configuration Management for Systems to be Managed (S)
Software and configuration data for systems to be managed SHOULD be consistently managed in a configuration management system that provides versioning and change tracking. The associated documentation for configuration management SHOULD be complete and up to date at all times. The documentation required for this SHOULD be securely available from a central point and integrated into backup processes. The central configuration management used for this purpose SHOULD be maintained continuously and audited regularly. 
All interfaces between the system management solution and other applications and services SHOULD be documented and fully managed in a configuration management solution. Functional changes to the interfaces SHOULD be coordinated between the relevant operational areas at an early stage and documented accordingly. 
Configuration data for the systems being managed SHOULD be automatically distributed across the network, and it SHOULD be possible to install and activate it without interrupting operations.
OPS.1.1.7.A15 Status Monitoring, Logging, and Alerting of Relevant Events in the System Management Solution and the Systems to be Managed (S)
The basic performance and availability parameters of a system management solution and the systems to be managed SHOULD be continuously monitored. For this purpose, the respective threshold values SHOULD be determined in advance (baselining). If defined threshold values are exceeded, the responsible personnel SHOULD be notified automatically. 
For better error analysis, information from the status monitoring of other areas (e.g. from a separate “Networks” area) SHOULD also be considered to find the exact cause of disruptions. 
Important events on systems to be managed and on the system management solution SHOULD be automatically transmitted to a central logging infrastructure and logged there (see OPS.1.1.5 Logging). 
Important events SHOULD be defined for the following aspects at minimum: 
•	Failure or inaccessibility of systems to be managed 
•	Failure or inaccessibility of system management components 
•	Hardware malfunctions 
•	Login attempts on the system management solution 
•	Login attempts on systems to be managed 
•	Critical states or overload of the system management solution 
•	Critical states or overloads of systems to be managed 
Event messages and logging data SHOULD be transmitted to a central logging system. Alarm messages SHOULD be transmitted as soon as they occur.
OPS.1.1.7.A16 Integration of System Management into Contingency Planning (S)
A system management solution SHOULD be integrated into its organisation’s contingency planning. To accomplish this, both the system management solution and the configurations of the systems being managed SHOULD be secured and integrated into restoration of service plans.
OPS.1.1.7.A17 Control of System Management Communication (S)
Communications between users and a systems management solution, as well as between the system management solution and the IT systems being managed, SHOULD be limited to strictly necessary connections using appropriate filtering techniques.
OPS.1.1.7.A18 System State Verification (S)
The consistency between a system's actual state and the state assumed by the corresponding system management solution SHOULD be checked regularly. If discrepancies are found, the state assumed by the system management solution SHOULD be restored.
OPS.1.1.7.A19 Securing System Management Communications Between the System Management Solution and the Systems Being Managed (S)
System management communications between a system management solution and the systems to be managed SHOULD always be encrypted. The strength of the cryptographic procedures and keys used SHOULD be checked at regular intervals and adjusted as necessary.
OPS.1.1.7.A2 System Management Planning (B)
A system management solution and its underlying infrastructure MUST be planned appropriately. At minimum, planning MUST include the following:
• A detailed requirements analysis
• A meaningful rough concept
• A comprehensive implementation plan
• Milestones for quality assurance and acceptance
All the issues mentioned in the corresponding requirements specification and role and access control policy MUST be considered. The following aspects MUST be considered at minimum:
• Separation into appropriate areas for system management
• Access options to and by the system management solution
• System management authorisations on the systems to be managed
• Network connections for access to and by the system management solution
• Protocols for user access to the system management solution
• Protocols for communication between the system management solution and the systems to be managed
• Requirements that management systems tools must fulfil
• Interfaces for forwarding collected event or alarm messages
• Logging (including the required interfaces to a centralised logging solution)
• Vendor and developer support over the planned deployment period
• The option to apply patches to the system management solution and the systems to be managed
• Reporting and interfaces to overarching solutions
• Corresponding requirements to be fulfilled by the systems to be managed
OPS.1.1.7.A20 Implementing System Management Solutions for High 
Availability (H)
A central system management solution SHOULD be operated in a manner that ensures high availability. To this end, the servers and tools used for the system management solution (including their network connections) SHOULD be designed redundantly.
OPS.1.1.7.A21 Physical Separation of the Central System Management Network (H)
An organisation's management network for system management SHOULD be physically separated from its functional (and especially its productive) networks.
OPS.1.1.7.A22 Integration of System Management into Automated Detection Systems (S)
The logging of security-relevant events in system management SHOULD be integrated into a security information and event management (SIEM). The events to be forwarded to the SIEM SHOULD be comprehensibly defined. 
The requirements catalogue for selecting a system management solution SHOULD specify the necessary interfaces and transfer formats. 
A system management solution SHOULD be monitored in an automated manner by a security vulnerability detection system.
OPS.1.1.7.A23 Cross-Site Time Synchronisation for System Management (H)
Time synchronisation SHOULD be ensured for both an organisation's system management solution and the systems being managed across all its sites. A common reference time SHOULD be used for this purpose.
OPS.1.1.7.A24 Automated Checking of Security-Relevant Configurations by Suitable Detection Systems (H)
Security-relevant configurations of a system management solution and the systems to be managed SHOULD be regularly checked by suitable detection systems for deviations from the target state and for potential vulnerabilities.
OPS.1.1.7.A25 Logging and Regulation of System Management Meetings (H)
Session content, particularly user activity on a system management solution and all instances of direct access to systems to be managed, SHOULD be continuously logged and regulated by a technical solution. Command-level activities (i.e. manual and automated commands) SHOULD be monitored and prevented if necessary. 
During monitoring, alerts SHOULD be raised not only in the event of specific rule violations, but also in case of anomalies in user behaviour
OPS.1.1.7.A26 Decoupling of Access to the System Management Solution (H)
All administrative access to a system management solution SHOULD be secured through the use of jump servers.
OPS.1.1.7.A3 Time Synchronisation for System Management (B)
All the components of a system management solution, including the systems to be managed, MUST be synchronised. System time MUST be synchronised for each system to be managed and for the system management solution via appropriate protocols.
OPS.1.1.7.A4 Protection of System Management Communication (B)
As soon as a system management solution and the systems to be managed communicate via productive infrastructure, secure protocols MUST be used for this purpose. If this is not possible, a dedicated administration network (out-of-band management) MUST be used (see NET.1.1 Network Architecture and Design). If this is also not possible, complementary security mechanisms MUST be used at another level (e.g. tunnel mechanisms via encrypted VPN or comparable solutions).
OPS.1.1.7.A5 Mutual Authentication Between the System Management Solution and Systems to be Managed (B)
Authentication between a system management solution and the systems to be managed MUST be two-way in nature. Authentication MUST be integrated into an overarching authentication concept. Authentication MUST be performed using secure protocols.
OPS.1.1.7.A6 Securing Access to the System Management Solution (B)
User access to a system management solution MUST be secured through:
• Secure and appropriate authentication and authorisation of the user
• Secure encryption of transmitted data
An appropriate authentication method MUST be selected. The selection process MUST be documented. The strength of the cryptographic methods and keys used MUST be regularly reviewed and adjusted as needed.
The system management solution MUST use an authorisation component to ensure that users can only perform actions for which they are authorised.
OPS.1.1.7.A7 Definition of a Security Policy for System Management (S)
For system management, a security policy SHOULD be drawn up and continuously maintained. All persons involved in system management SHOULD be familiar with the policy. The security policy SHOULD be integral to their work. Regular and transparent reviews SHOULD be conducted to ensure that the policy requirements are being implemented. The results SHOULD be documented.
At minimum, the security policy SHOULD specify the following:
• The areas of system management that are to be realised via central management tools and services
• The system management tasks that are to be realised in an automated manner
• Configuration management for the data managed by the system management solution, e.g. versioning of configurations
• Specifications for network separation
• Specifications for access control
• Logging specifications
• Quality assurance specifications for the use of automation functions, e.g. scripts
• Specifications for protecting communication
• The basic operational rules for system management
• Specifications for coordination with network management, e.g. assignment of IP addresses or DNS names
OPS.1.1.7.A8 Drawing Up a System Management Concept (S)
Based on the security policy drawn up for system management, a system management concept SHOULD be established and continually maintained. In doing so, the following minimum aspects SHOULD be taken into account as required:
• Methods, techniques, and tools for system management
• Protection of access and communication
• Protection at the network level, in particular the assignment of system management components to security zones
• Scope of monitoring and alerting for each system to be managed
• Logging
• Automation, in particular the central distribution of configuration files to the systems to be managed
• Specifications for the development and testing of automation functions
• Reporting chains in the event of malfunctions and security incidents
• Provisioning of system management information for other areas of the organisation in question
• Integration of system management into contingency planning
• Required network transmission capacity of the system management solution
OPS.1.1.7.A9 Detailed and Implementation Planning for System Management (S)
Detailed and implementation planning SHOULD be drawn up for system management solutions. It SHOULD consider all the items addressed in the respective security policy and system management concept.
OPS.1.2.2 Archiving
Target Object: Information domain/generic aspects / Order: R3
OPS.1.2.2.A1 Determining Parameters for Electronic Archiving (B)
Before methods and products for electronic archiving are chosen, the technical, legal, and organisational parameters MUST be determined and documented. The results MUST be incorporated into the archiving concept in question.
OPS.1.2.2.A10 Drawing Up a Policy for Using Archive Systems [IT Operation Department] (S)
It SHOULD be ensured that employees use archive systems as prescribed in the applicable archiving concept. To this end, an administration and user policy SHOULD be drawn up. The administration policy SHOULD cover the following items: • Assignment of responsibility for operation and administration • Agreements regarding performance parameters during operation (including service level agreements) • Terms regarding the assignment of site and data access rights • Terms regarding the assignment of access rights to the services provided by the archive • Regulations regarding the handling of archived data and archive media • Monitoring of the archive system and the related environmental conditions • Rules on backups • Rules on logging • Separation of producers and consumers (OAIS model)
OPS.1.2.2.A11 Instruction Regarding the Administration and Operation of the Archive System [IT Operation Department, User] (S)
Users and the responsible employees in the IT Operation Department SHOULD be trained in their areas of responsibility. The training of IT Operation Department employees SHOULD cover the following subjects: • System architecture and security mechanisms of the archive system used and the underlying operating system • Installation and operation of the archive system and handling of archive media • Documentation of administrative activities • Escalation procedures The user training SHOULD cover the following subjects: • Handling the archive system • Operating the archive system • Legal framework conditions of archiving The completion of these training courses and the names of those who attend SHOULD be documented.
OPS.1.2.2.A12 Monitoring of Storage Resources for Archive Media [IT Operation Department] (S)
The capacity available in archive media SHOULD be monitored continuously. Once it has fallen below a defined threshold, a responsible employee MUST be alerted automatically. The alert SHOULD be role-based. A sufficient number of empty archive media MUST be available on short notice at any point in time to prevent storage bottlenecks.
OPS.1.2.2.A13 Regular Auditing of Archiving Processes (S)
Whether archiving processes are still working correctly and properly SHOULD be checked regularly. A checklist SHOULD be drawn up for this that includes questions regarding responsibilities, organisational processes, use of archiving, the redundancy of archived data, administration, and technical assessment of the archive system. The audit results SHOULD be documented transparently and compared against the target condition. Deviations SHOULD be investigated.