chrisbst48/IT-Grundschutz-Compendium_2022_EN huggingface dataset:
OPS.1.2.2.A14 Regular Observation of the Market for Archive Systems [IT Operation Department] (S)
The market for archive systems SHOULD be observed regularly and systematically. Among other aspects, the following criteria SHOULD be taken into account: • Changes in standards • Instances in which hardware and software manufacturers move to different technologies • Published security gaps or vulnerabilities • Cases in which the security of cryptographic algorithms becomes compromised
OPS.1.2.2.A15 Regular Processing of Cryptographically Secured Data During Archiving [IT Operation Department] (S)
Developments in the field of cryptography should be continuously monitored to assess the ongoing reliability and security of a given algorithm (see also OPS.1.2.2.A20 Appropriate Use of Cryptographic Procedures During Archiving). Archive data that has been secured using cryptographic procedures that will no longer be suitable for securing in the foreseeable future SHOULD be re-secured in good time using suitable procedures.
OPS.1.2.2.A16 Regular Renewal of Technical Archive System Components [IT Operation Department] (S)
Archive systems SHOULD be kept in line with the current state of the art over long periods of time. New hardware and software SHOULD be tested comprehensively before being installed in a running archive system. When commissioning new components or introducing new file formats, a migration concept SHOULD be drawn up. This concept SHOULD describe all changes, tests, and expected test results. Conversion of the individual data sets SHOULD be documented (using a transfer note). When converting archive data to new formats, it SHOULD be checked whether the data must also be archived in its initial format as a consequence of legal requirements.
OPS.1.2.2.A17 Selecting a Suitable Archiving System [IT Operation Department] (S)
A new archive system SHOULD always be selected on the basis of the specifications mentioned in the archiving concept in question. It SHOULD meet the requirements formulated in this concept.
OPS.1.2.2.A18 Using Appropriate Archive Media [IT Operation Department] (S)
Appropriate media SHOULD be selected and used for archiving. In doing so, the following aspects should be considered: • The data volumes to be archived • The average access times • The average number of simultaneous users accessing the archive system The archive media SHOULD also meet the requirements of long-term archiving with regard to audit compliance and useful life.
OPS.1.2.2.A19 Regular Function and Recovery Tests for Archiving [IT Operation Department] (S)
Regular function and recovery tests SHOULD be performed for archiving. The readability and integrity of archived storage media SHOULD be checked at least once a year. Appropriate processes SHOULD be defined for troubleshooting. Furthermore, the hardware components of archive systems SHOULD be checked for sound functionality at regular intervals. Whether all archiving processes work without any errors SHOULD also be checked regularly
OPS.1.2.2.A2 Drawing up an Archiving Concept (B)
The aims to be achieved through archiving MUST be defined. In particular, this MUST take into consideration the rules to be followed, the employees who will be responsible, and the desired scope of functions and services. The results MUST be documented in an archiving concept. The Top Management MUST be involved in this process. The archiving concept MUST be adapted to the current circumstances at regular intervals.
OPS.1.2.2.A20 Appropriate Use of Cryptographic Methods for Archiving [IT Operation Department] (H)
To cover long retention periods, archive data SHOULD only be secured with cryptographic procedures that are based on current standards.
OPS.1.2.2.A21 Transfer of Paper-based Data to Electronic Archives (H)
If documents on paper are digitised and transferred to an electronic archive, it SHOULD be ensured that the digital copy matches the original document in terms of its images and content.
OPS.1.2.2.A3 Appropriate Installation of Archive Systems and Storage of Archive Media [IT Operation Department] (B)
The IT components of an archive system MUST be installed in secured rooms. It MUST be ensured that only authorised persons may access the rooms. Archive storage media MUST be stored appropriately.
OPS.1.2.2.A4 Consistent Indexing of Data During Archiving [IT Operation Department, User] (B)
All the data, documents, and records stored in an archive MUST be uniquely indexed. To this end, the desired structure and extent of an archive's index information MUST be defined in the design phase.
OPS.1.2.2.A5 Regular Regeneration of Archived Data [IT Operation Department] (B)
The following MUST be ensured over the entire archiving period in question: • The data format used can be processed by the applications used • The data stored can be read and reproduced in the future in such a way that semantics and significance can be maintained • The file system used on the storage medium can be processed by all the components involved • The storage media can be read at any time without technical issues • The cryptographic methods used for encryption and the preservation of legal relevance by means of digital signatures, seals, time stamps, or technical evidence records correspond to the state of the art
OPS.1.2.2.A6 Protection of the Integrity of the Index Database of Archive Systems [IT Operation Department] (B)
The integrity of index databases MUST be safeguarded and verifiable. In addition, index databases MUST be backed up regularly. It MUST be possible to restore the backups. Medium-sized and large archives SHOULD have redundant index databases.
OPS.1.2.2.A7 Regular Backups of System and Archive Data [IT Operation Department] (B)
All archive data, the related index databases, and the system data MUST be backed up at regular intervals (see CON.3 Backup Concept).
OPS.1.2.2.A8 Logging of Archival Access [IT Operation Department] (B)
All attempts to access electronic archives MUST be logged. To this end, dates, times, users, client systems, the actions performed, and any error messages SHOULD be recorded. The archiving concept in question SHOULD specify how long the log data should be retained. The log data for archive access SHOULD be evaluated regularly. In so doing, the internal specifications of the organisation at hand SHOULD be taken into account. The specific staff members to whom specific events (e.g. system errors, timeouts, and the copying of records) should be displayed SHOULD also be defined. Critical events SHOULD be evaluated and, if required, escalated immediately once they are detected.
OPS.1.2.2.A9 Selection of Suitable Data Formats for Archiving Documents [IT Operation Department] (B)
A suitable data format MUST be selected for archiving. It MUST ensure that archived data and selected features of the initial document medium can be reproduced in the long term in a format that is true to the original. It MUST be possible to unambiguously interpret and electronically process the document structure of the selected data format. The syntax and semantics of the data formats used SHOULD be documented and published by a standardisation organisation. A loss-free image compression method SHOULD be used for evidential and audit-compliant archiving.
OPS.1.2.4 Teleworking
Target Object: Information domain/generic aspects / Order: R3
OPS.1.2.4.A1 Rules on Teleworking [Supervisor, Human Resources Department] (B)
All the relevant aspects of teleworking MUST be specified. The applicable rules or a corresponding leaflet explaining the security safeguards to be considered MUST be provided to teleworkers. Contentious points MUST be clarified in employment agreements or separate agreements between the employee and employer as a supplement to their employment contract. The rules MUST be updated at regular intervals.
OPS.1.2.4.A10 Analysis of Teleworking Location Requirements [IT Operation Department] (S)
A requirements analysis SHOULD be performed before setting up a teleworking location. It SHOULD include the hardware and software components required for teleworking locations. The requirements for each teleworking location SHOULD be agreed with the persons in charge of IT. The protection needs of the information processed at teleworking locations SHOULD always be determined and documented.
OPS.1.2.4.A2 Security-Related Requirements for Teleworking Computers (B)
Security-related requirements MUST be defined that IT systems must meet for teleworking. It MUST be ensured that only authorised persons have access to teleworking computers. Moreover, teleworking computers MUST be protected so that they can be used only for authorised purposes.
OPS.1.2.4.A5 Employee Awareness and Training (B)
Employees MUST be made aware of the risks connected to teleworking by means of a guide. Furthermore, they MUST be instructed in the corresponding security safeguards of their organisation and trained in how to deal with them. Training and awareness safeguards for employees SHOULD be repeated at regular intervals.
OPS.1.2.4.A6 Creating a Security Concept for Teleworking (S)
A security concept for teleworking that describes the security objectives, protection needs, security requirements, and risks involved SHOULD be drawn up. The concept SHOULD be reviewed and updated regularly. The security concept for teleworking SHOULD be coordinated with the overall security concept of the organisation in question.
OPS.1.2.4.A7 Regulations on Using Communication Capabilities for Teleworking [IT Operation Department, Employee] (S)
Clear rules SHOULD be specified regarding which communication capabilities may be used under which general framework conditions for the purpose of teleworking. There SHOULD be rules regarding the professional and private use of Internet services when teleworking. Here, it SHOULD also be clarified whether private use is generally allowed or prevented.
OPS.1.2.4.A8 Flow of Information Between Employees and Organisations [Supervisor, Employee] (S)
A regular in-house exchange of information SHOULD be ensured between teleworking employees and organisations. All employees SHOULD be informed promptly about security requirements and other security-relevant aspects. All the colleagues of teleworking employees SHOULD know when and where these employees can be contacted. Technical and organisational teleworking rules on the performance of tasks, security incidents, and other problems SHOULD be specified and communicated to employees.
OPS.1.2.4.A9 Support and Maintenance Concept for Teleworking Locations [IT Operation Department, Employee] (S)
A special support and maintenance concept SHOULD be drawn up for teleworking locations. This concept SHOULD specify the following aspects: contact persons for user services, maintenance dates, remote maintenance, transport of IT devices, and the introduction of standard teleworking computers. Contact persons for hardware and software problems SHOULD be named to help ensure that employees can continue to work.
OPS.1.2.5 Remote Maintenance
Target Object: Information domain/generic aspects / Order: R3
OPS.1.2.5.A1 Planning the Use of Remote Maintenance (B)
The use of remote maintenance MUST be adapted to each individual organisation. Remote maintenance MUST be planned in a needs-based manner with regard to technical and organisational aspects. At minimum, consideration MUST be given to the IT systems that should be maintained remotely and the persons responsible for this.
OPS.1.2.5.A10 Management of Remote Maintenance Tools [User] (S)
Organisational management processes describing how to handle the selected tools SHOULD be established. Operating instructions describing how to use these remote maintenance tools SHOULD be available. In addition to general training, model procedures for passive and active remote maintenance SHOULD be established and communicated. In addition to general training, the IT Operation Department SHOULD be made specifically aware of and trained in using remote maintenance tools. A contact person SHOULD be appointed for all technical issues related to remote maintenance tools.
OPS.1.2.5.A14 Dedicated Clients for Remote Maintenance (H)
For remote maintenance, IT systems SHOULD be used which are designed exclusively for the administration of other IT systems. All other functions on these IT systems SHOULD be disabled.
OPS.1.2.5.A17 Authentication Mechanisms for Remote Maintenance (S)
For remote maintenance, multi-factor methods SHOULD be used for authentication. The selection of the authentication method and the reasons on which this selection was based SHOULD be documented. Remote maintenance access SHOULD be considered in an organisation's identity and authorisation management efforts.
OPS.1.2.5.A19 Remote Maintenance by Third Parties (S)
If remote maintenance is carried out by external parties, all related activities SHOULD be supervised by internal staff. All remote maintenance processes performed by third parties SHOULD be recorded. Contractual arrangements MUST be made with external maintenance personnel regarding the security of the IT systems and information concerned. If a service provider performs remote maintenance for several clients, it MUST be ensured that the networks of its clients are not interconnected. The duties and qualifications of external maintenance personnel SHOULD be specified in a contract. Remote maintenance interfaces SHOULD be configured in such a way that it is only possible for the service provider to access the IT systems and network segments needed for their work.
OPS.1.2.5.A2 Establishing a Secure Connection for Remote Maintenance of Clients [User] (B)
If clients are accessed via remote maintenance, the users of these IT systems MUST explicitly consent to this access.
OPS.1.2.5.A20 Remote Maintenance Operations (S)
A reporting process for support and remote maintenance concerns SHOULD be established. Mechanisms for detecting and thwarting high-volume attacks, TCP state exhaustion attacks, and attacks at the application level SHOULD be implemented. All remote maintenance processes SHOULD be logged.
OPS.1.2.5.A21 Creation of a Business Continuity Plan in Case of Remote Maintenance Failure (S)
A plan SHOULD be developed to minimise the consequences of a failure of remote maintenance components. This SHOULD specify how to react in case of a failure. The contingency plan SHOULD ensure that disruptions and damage (both immediate and consequential) are minimised. It SHOULD also specify how normal operations can be resumed in a timely manner.
OPS.1.2.5.A22 Redundant Communication Links (H)
Redundant communication links SHOULD be established for remote maintenance access. Organisations SHOULD provide connections for out-of-band management.
OPS.1.2.5.A24 Securing Integrated Remote Maintenance Systems (S)
When procuring new IT systems, it SHOULD be checked whether these IT systems or their individual components have functions for remote maintenance. If these functions are not used, they SHOULD be disabled. The functions SHOULD also be disabled if they are compromised by known security vulnerabilities. If remote maintenance functions integrated into the firmware of individual components are used, their functions and access to them SHOULD be restricted to the greatest extent possible. The IT systems SHOULD only be accessible from a separate management network.
OPS.1.2.5.A25 Decoupling of Network Management Communication During Remote Maintenance (S)
Direct remote maintenance access to an IT system by an administrator from a remote maintenance client outside the corresponding management networks SHOULD be avoided. If such access is necessary, the communication SHOULD be decoupled. Jump servers SHOULD be used for this purpose.
OPS.1.2.5.A3 Securing Interfaces for Remote Maintenance (B)
The possible access and communication connections for remote maintenance MUST be restricted to those required. All remote maintenance connections MUST be disconnected after remote access. It MUST be ensured that remote maintenance software is only installed on IT systems where it is needed. Remote maintenance connections via untrusted networks MUST be encrypted. All other remote maintenance connections SHOULD be encrypted.
OPS.1.2.5.A5 Use of Online Services [User] (S)
Organisations SHOULD define the circumstances in which online services for remote maintenance may be used where the connection is established via an external service provider. The use of such services SHOULD generally be limited to as few cases as possible. IT systems SHOULD not establish automated connections to the online service. It SHOULD be ensured that the online service used performs end-to-end encryption on the transmitted information.
OPS.1.2.5.A6 Drawing Up a Policy for Remote Maintenance (S)
Organisations SHOULD draw up a policy on remote maintenance in which all the relevant regulations are documented. The policy SHOULD be known to all persons in charge who are involved the conception, setup, and performance of remote maintenance.
OPS.1.2.5.A7 Documentation During Remote Maintenance (S)
Remote maintenance SHOULD be documented appropriately. The documentation SHOULD show the remote maintenance access points that exist and whether they are activated. The documents SHOULD be stored in suitable locations and protected from unauthorised access. The documents SHOULD be available within the framework of business continuity management.
OPS.1.2.5.A8 Secure Protocols for Remote Maintenance (S)
Only communication protocols classified as secure SHOULD be used. Secure cryptographic procedures SHOULD be used for this purpose. The strength of the cryptographic procedures and keys used SHOULD be checked at regular intervals and adjusted as necessary. If the remote maintenance access points of IT systems in an internal network are accessed via a public data network, a secured virtual private network (VPN) SHOULD be used.
OPS.1.2.5.A9 Selection and Acquisition of Suitable Remote Maintenance Tools (S)
Suitable remote maintenance tools SHOULD be selected based on the operational, security-related, and data protection requirements of the organisation in question. All procurement decisions SHOULD be coordinated with the persons in charge of the systems and applications and the Chief Information Security Officer.
OPS.1.2.6 NTP Time Synchronisation
Target Object: Application / Order: R2
OPS.1.2.6.A1 Planning the Use of NTPs (B)
The IT Operation Department MUST plan where and how NTP is used. This SHOULD be documented fully. In the process, the applications that rely on accurate time information MUST be identified. The requirements of the information domain at hand regarding the accurate time of IT systems MUST be defined and documented. 
The IT Operation Department MUST define which NTP servers are to be used by which NTP clients. 
Whether the NTP servers are to operate in client-server or broadcast mode MUST be defined.
OPS.1.2.6.A10 Internal NTP Servers Only (H)
Each IT system in an information domain with an NTP service SHOULD receive its time information exclusively from NTP servers within the respective organisation's network.
OPS.1.2.6.A11 Redundant NTP Servers (H)
IT systems for which the accuracy of the system time is of significant importance SHOULD obtain their time information from at least four independent NTP servers.
OPS.1.2.6.A12 NTP Servers with Authenticated Information (H)
NTP servers SHOULD authenticate themselves to clients when communicating. This SHOULD also apply to the servers from which NTP servers receive their own time information. NTP clients SHOULD only accept authenticated NTP data.
OPS.1.2.6.A2 Secure Use of External Time Sources (B)
If time information is obtained from an NTP server outside the network of the organisation in question, the IT Operation Department MUST assess whether the operator's NTP server is sufficiently reliable. The IT Operation Department MUST ensure that only NTP servers classified as reliable are used. The IT Operation Department MUST know and observe the operator's usage regulations.
OPS.1.2.6.A3 Secure Configuration of NTP Servers (B)
The IT Operation Department MUST configure the NTP server in such a way that clients can only change NTP server settings if this is explicitly intended. Furthermore, it MUST be ensured that only trusted clients can request status information. 
If the respective organisation's internal NTP servers do not use sufficiently accurate time sources themselves, the IT Operation Department MUST configure these NTP servers to regularly request accurate time information from external NTP servers.
OPS.1.2.6.A4 Failure to Account for Unsolicited Time Information (B)
The IT Operation Department MUST configure all NTP clients to discard unsolicited time information received from other IT systems.
OPS.1.2.6.A5 Use of Client-Server Mode for NTP (S)
The IT Operation Department SHOULD configure all IT systems to use the NTP service in client-server mode. NTP servers SHOULD only send time information to clients when they actively request it.
OPS.1.2.6.A6 Monitoring of IT Systems Using NTP (S)
The IT Operation Department SHOULD monitor the availability, capacity, and system time of internal NTP servers. 
The IT Operation Department SHOULD configure IT systems that synchronise their time via NTP to log the following events: 
•	Unexpected restarts of the IT system 
•	Unexpected restarts of the NTP service 
•	Errors related to the NTP service 
•	Unusual time information 
If an NTP server regularly sends time information on its own (broadcast mode), the IT Operation Department SHOULD monitor the NTP clients to see if they receive unusual time information.
OPS.1.2.6.A7 Secure Configuration of NTP Clients (S)
The IT Operation Department SHOULD define which time information an IT system should use when it has been restarted. The IT Operation Department SHOULD define which time information an IT system should use when its NTP service has been restarted. 
The IT Operation Department SHOULD determine how NTP clients will react to significantly deviating time information. In particular, a decision SHOULD be taken as to whether strongly deviating time information will be accepted by NTP servers after a system restart. The IT Operation Department SHOULD set limits for time information that deviates significantly. 
The IT Operation Department SHOULD ensure that NTP clients will still receive sufficient time information even if an NTP server asks them to send fewer requests (or none at all).
OPS.1.2.6.A8 Use of Secure Time Synchronisation Protocols (S)
The IT Operation Department SHOULD check whether secure protocols can be used for time synchronisation (e.g. Network Time Security, NTS). Secure protocols SHOULD be used whenever possible.
OPS.1.2.6.A9 Sufficient Availability of Accurate Time Sources (H)
If accurate system times are of significant importance, an organisation SHOULD have multiple stratum-1 NTP servers on its network. The IT systems of an information domain with an NTP service SHOULD use stratum-1 NTP servers directly or indirectly as a time reference. The stratum-1 servers SHOULD each have different time sources.
OPS.2.1 Outsourcing for Customers
Target Object: Information domain/generic aspects / Order: R2
OPS.2.1.A1 Specification of Security Requirements for Outsourcing Projects (B)
All the security requirements for an outsourcing project MUST be defined on the basis of an outsourcing strategy. Both outsourcing parties MUST contractually commit to comply with IT-Grundschutz or a comparable level of protection. All interfaces between the outsourcing service provider and the outsourcing customer MUST be identified and appropriate security requirements defined. The security requirements MUST specify the authorisations (e.g. site, system, and data access rights) that the two parties are to grant to one another.