chrisbst48/IT-Grundschutz-Compendium_2022_EN huggingface dataset:
OPS.1.1.2.A15 Division of Administrative Activities (H)
Different administration roles SHOULD be created for partial tasks. When differentiating among tasks, the type of data involved and the system architecture in place SHOULD be taken into consideration.
OPS.1.1.2.A16 Access Restrictions for Administrative Access (H)
Access to administrative interfaces SHOULD be technically restricted with filtering and separation measures. Interfaces SHOULD not be accessible to persons outside the responsible administration teams. Administrative access to IT systems in other protection zones SHOULD only be established via a jump server in the respective administrator's current security zone. Access attempts from other systems or other security zones SHOULD be rejected.
OPS.1.1.2.A17 Dual Control in IT Administration (H)
For particularly security-critical IT systems, access to credentials with administrative authorisations SHOULD be implemented in a way that always requires two employees. In other words, one administrator SHOULD perform the administrative tasks at hand under the supervision of a second administrator.
OPS.1.1.2.A18 Consistent Logging of Administrative Activities (H)
Administrative activities SHOULD be logged. For particularly security-critical IT systems, all administrative access attempts SHOULD be logged consistently and completely. Executing administrators SHOULD not have authorisation to change or delete the recorded log files. The log files SHOULD be retained for an appropriate period of time.
OPS.1.1.2.A19 Consideration of High-Availability Requirements (H)
Administrators SHOULD analyse which of the IT systems and networks they support are subject to high-availability requirements. For these areas, they SHOULD make sure that the components and architectures used, as well as the related operating processes, are appropriate for fulfilling these requirements.
OPS.1.1.2.A2 Deputising Rules and Contingency Planning (B)
It MUST be ensured that only appointed deputies can access the IT systems to be supported. Emergency users with administrative rights should be set up for emergencies.
OPS.1.1.2.A20 Administration and Commissioning of Devices (S)
There SHOULD be an overview of all the devices in use at a given organisation that could have an impact on information security. In addition to IT systems and ICS components, devices pertaining to the Internet of Things (IoT) SHOULD also be considered. Appropriate testing and approval procedures SHOULD be carried out before the devices are put into operation for the first time. The overview SHOULD be kept up to date and correspond with the documentation of administrative activities.
OPS.1.1.2.A3 Controlled Hiring of IT Administrators (B)
If employees assume administrative tasks within an IT environment, they MUST be trained, particularly in terms of the IT architecture and the IT systems and applications for which they are responsible. Administrators MUST be made familiar with the security provisions that apply in their organisation and are relevant to their work.
OPS.1.1.2.A4 Termination of IT Administration Duties [Human Resources Department] (B)
If administrators are relieved of their tasks, all their assigned personal administration credentials MUST be withdrawn. The passwords still known to employees who are being relieved of duties MUST be checked and these passwords MUST be changed. Furthermore, whether employees being relieved of their duties have been appointed as contact persons for third parties (e.g. in contracts or as an Admin-C entry for Internet domains) MUST be checked. If this is the case, new contact persons MUST be specified and the third parties advised. The users of the IT systems and applications concerned MUST be informed that the previous administrator has left.
OPS.1.1.2.A5 Verifying Administrative Tasks (B)
An organisation MUST be able to prove which administrator has carried out which administrative activities at any time. For this purpose, each administrator SHOULD have their own user ID. Administrator deputies SHOULD also receive their own user IDs. Each login by an administrator ID MUST be logged.
OPS.1.1.2.A6 Protecting Administrative Tasks (B)
Administrators MUST authenticate themselves through appropriate procedures before performing actions with administrative privileges. Actions and activities that do not require elevated privileges MUST NOT be performed with administrative privileges. Organisations MUST ensure that only administrators have access to administrative interfaces and functions. In particular, organisations MUST ensure that only administrators can make security-relevant changes to IT systems and applications. Administration MUST be performed using secure protocols. The option to set up a separate administration network SHOULD be considered.
OPS.1.1.2.A7 Regulation of IT Administration Tasks (S)
The competencies, tasks, and obligations of administrators SHOULD be defined in a binding manner in a work instruction or policy. The tasks allocated to different administrators SHOULD be distributed in such a way that overlapping responsibilities are avoided, but all the tasks to be performed are still assigned. These regulations SHOULD be updated at regular intervals. In particular, their specifications SHOULD prevent administrators from making unauthorised changes within the information domain in question, provided that the changes go beyond the tasks explicitly assigned to them and are not necessary to prevent a security incident or failure.
OPS.1.1.2.A8 Administration of Specialised Applications (S)
The Basic Requirements listed in this module SHOULD also be implemented consistently for employees with administrative tasks involving individual specialised applications. The division of tasks between application and system administration SHOULD be clearly defined and documented in writing. Interfaces SHOULD be defined between the persons in charge of system administration and those in charge of specialised application administration. If there is an administrative intervention in the operation of an application, this SHOULD be coordinated in advance with the department in question. The needs of the department SHOULD be taken into account.
OPS.1.1.2.A9 Sufficient Resources for the IT Operation Department (S)
Sufficient personnel and material resources SHOULD be provided in order to properly handle the administrative tasks at hand. This SHOULD take into account the fact that appropriate capacities must also be available for unforeseeable tasks. Resource planning SHOULD be reviewed regularly and adapted to the current requirements.
OPS.1.1.3 Patch and Change Management
Target Object: Information domain/generic aspects / Order: R1
OPS.1.1.3.A1 Concept for Patch and Change Management [Process Owner] (B)
If IT components, software, or configuration data are changed, there MUST be specifications that also consider security aspects. These MUST be defined in a concept for patch and change management and followed accordingly. All patches and changes MUST be suitably planned, approved, and documented. Patches and changes SHOULD be suitably tested in advance (see also OPS.1.1.6 Software Tests and Approvals in this regard). If patches are installed and changes carried out, fallback solutions MUST be available. If there are major changes, the Chief Information Security Officer MUST also be involved. Overall, it MUST be ensured that the desired security level is maintained during and after the implementation of changes. In particular, the desired security settings SHOULD also be maintained.
OPS.1.1.3.A10 Assuring the Integrity and Authenticity of Software Packages (S)
The authenticity and integrity of software packages SHOULD be ensured throughout the patch or change process. To this end, it SHOULD be checked whether checksums or digital signatures are available for the software packages used. If there are, these SHOULD be checked before a package is installed. Furthermore, it SHOULD be ensured that the programs required for checking are available. As a matter of principle, software and updates SHOULD only be obtained from trustworthy sources.
OPS.1.1.3.A11 Continuous Documentation of Information Processing (S)
Changes SHOULD be documented in all phases, applications, and systems. Corresponding rules SHOULD be developed for this purpose.
OPS.1.1.3.A12 Use of Tools in Change Management (H)
Before using a change management tool, it SHOULD be checked whether it can distribute changes appropriately in the information domain in question. It SHOULD also be possible to define break points for stopping the distribution of incorrect changes.
OPS.1.1.3.A13 Measuring the Success of Change Requests [Process Owner] (H)
The Process Owner for patch and change management SHOULD perform follow-up tests to verify that a given change has been successful. For this, the Process Owner SHOULD select suitable reference systems as quality assurance systems. The results of follow-up tests SHOULD be documented within the scope of the change process.
OPS.1.1.3.A14 Synchronisation Within Change Management (H)
In the change management process, appropriate mechanisms SHOULD ensure that devices that cannot be reached temporarily or for a longer period of time also receive patches and changes.
OPS.1.1.3.A15 Regular Updating of IT Systems and Software (B)
IT systems and software SHOULD be updated regularly. In principle, patches SHOULD be applied promptly after release. Based on the patch and change management concept at hand, patches must be assessed promptly after release and prioritised accordingly. Decisions MUST be taken as to whether patches should be applied. When a patch is applied, it SHOULD be checked whether it has been successfully applied on all relevant systems in a timely manner. If a patch is not applied, this decision and the reasons for it MUST be documented.
OPS.1.1.3.A16 Regular Search for Information on Patches and Vulnerabilities (B)
The IT Operation Department MUST ensure it is regularly informed about vulnerabilities which become known in the firmware, operating systems, applications, and services used. The identified vulnerabilities MUST be rectified as soon as possible. As long as no appropriate patches are available, other appropriate safeguards to protect the systems affected MUST be implemented depending on the severity of the vulnerabilities and basic threats. If this is not possible, it SHOULD be ensured that the hardware, relevant operating systems, deployed applications, and services are no longer used.
OPS.1.1.3.A2 Definition of Responsibilities (B)
Persons in charge of patch and change management MUST be specified for all organisational areas. The defined responsibilities MUST also be reflected in an organisation's access control policy.
OPS.1.1.3.A3 Configuration of Auto-Update Mechanisms (B)
The handling of integrated auto-update mechanisms of the software used MUST be defined within a strategy for patch and change management. In particular, it MUST be specified how these mechanisms are to be safeguarded and appropriately configured. Moreover, the type of update mechanisms of new components SHOULD be checked.
OPS.1.1.3.A5 Handling Change Requests [Process Owner] (S)
All requests for changes SHOULD be recorded and documented. Change requests SHOULD be checked by the person responsible for patch and change management to ensure that the information security aspects have been sufficiently taken into account.
OPS.1.1.3.A6 Coordination of Change Requests (S)
The coordination process associated with a change SHOULD take into account all the relevant target groups and the impact on information security. The target groups affected by the change SHOULD be able to comment on the change in a verifiable manner. There SHOULD be a defined procedure to speed up the handling of important requests for changes.
OPS.1.1.3.A7 Integration of Change Management into Business Processes (S)
The change management process SHOULD be integrated into business processes or specialised tasks. In cases involving planned changes, the current situation of the affected business processes SHOULD be considered. All relevant departments SHOULD be informed of upcoming changes. There SHOULD also be an escalation level that includes members of the corresponding organisation's Top Management. In case of doubt, these members SHOULD decide on the priority and scheduling of a given hardware or software change.
OPS.1.1.3.A8 Secure Use of Tools for Patch and Change Management (S)
Requirements and framework conditions SHOULD be defined for selecting tools for patch and change management. Furthermore, a specific security policy SHOULD be drawn up for the tools used.
OPS.1.1.3.A9 Testing and Acceptance Procedures for New Hardware (S)
When new hardware is selected, it SHOULD be checked that the software used, and in particular the relevant operating systems, are compatible with the hardware and its driver software. New hardware SHOULD be tested before it is used. It SHOULD be tested exclusively in an isolated environment. There SHOULD be an acceptance procedure and a declaration of release for IT systems. The person in charge SHOULD file the declaration of release in a suitable place in writing. If errors are detected during live operations despite the acceptance and release procedures, there SHOULD be a procedure for troubleshooting.
OPS.1.1.4 Protection Against Malware
Target Object: Information domain/generic aspects / Order: R1
OPS.1.1.4.A1 Creating a Malware Protection Concept (B)
A concept that describes which IT systems must be protected against malware MUST be drawn up. It MUST include IoT devices and production systems. Furthermore, it MUST be specified how protection is to be implemented. If no reliable protection is possible, the identified IT systems SHOULD NOT be operated. The concept SHOULD be documented in a comprehensible manner and kept up to date.
OPS.1.1.4.A10 Using Special Analysis Environments (H)
Automated analyses in a special test environment (based on sandboxes, or separate virtual or physical systems) SHOULD also be used for assessing suspicious data.
OPS.1.1.4.A11 Using Several Scan Engines (H)
To improve detection performance, virus protection programs with several alternative scan engines SHOULD be used for IT systems that require special protection (e.g. gateways and IT systems for data exchange).
OPS.1.1.4.A12 Using Storage Media Locks (H)
Before connecting storage media from third parties to the IT systems of an organisation, the media SHOULD be checked in a storage media lock.
OPS.1.1.4.A13 Handling Untrusted Files (H)
If it is necessary to open untrusted files, this SHOULD only be done on an isolated IT system. In this system, the corresponding files SHOULD be converted into a secure format or printed (for example) if doing so will reduce the risk of a malware infection.
OPS.1.1.4.A14 Selecting and Using Cyber Security Products to Thwart Targeted Attacks (H)
The use and added value of products and services that offer an extended scope of protection compared to conventional anti-virus programs SHOULD be examined. Security products like these SHOULD be used against targeted attacks, such as when running files in special analysis environments, hardening clients, or encapsulating processes. Before a decision is taken to purchase a particular security product, the effectiveness of its protection and its compatibility with the IT environment of the organisation in question SHOULD be tested.
OPS.1.1.4.A2 Using System-Specific Protection Mechanisms (B)
The protection mechanisms provided by the IT systems used, as well as by the operating systems and applications used on them, MUST be checked. Such mechanisms MUST be used unless there is at least an equal substitute or good reasons against their use. If they are not used, this MUST be explained and documented.
OPS.1.1.4.A3 Selection of a Virus Protection Program (B)
A program MUST be selected and installed for the specific purpose of virus protection depending on the operating system used, the other protection mechanisms present, and the availability of suitable virus protection programs. For gateways and IT systems that are used to exchange data, a suitable virus protection program MUST be selected and installed. The products used MUST be designed for enterprise environments and include services and support that are tailored to the needs of the organisation in question. Products for purely home-based users or products without manufacturer support MUST NOT be used for professional production operations. Cloud services designed to improve the detection performance of virus protection programs SHOULD be used. If the cloud functions of such products are used, it MUST be ensured that there are no conflicts regarding data or confidentiality protection. In addition to real-time and on-demand scans, it MUST also be possible to scan compromised and encrypted data for malware with the solution chosen.
OPS.1.1.4.A5 Operation and Configuration of Virus Protection Programs (B)
Virus protection programs MUST be configured appropriately for their operational environment. The focus SHOULD be on detection performance unless data protection or performance reasons influence this in individual cases. If the security-relevant functions of a virus protection program are not used, this SHOULD be explained and documented. In the case of protection programs that are specially optimised for desktop virtualisation, it SHOULD be transparently documented whether certain detection procedures have been omitted in favour of performance. Care MUST be taken to ensure that users are not able to make any security-related changes to the settings of anti-virus programs.
OPS.1.1.4.A6 Regular Updating of Virus Protection Programs and Signatures (B)
The scan engines and malware signatures of virus protection programs MUST be updated regularly and promptly on the corresponding IT systems.
OPS.1.1.4.A7 User Awareness and Obligations [User] (B)
Users MUST be informed regularly of the threats posed by malware. They MUST comply with the basic codes of conduct at hand to reduce the risk of malware infection. Files, e-mails, websites, and other content from untrusted sources SHOULD NOT be opened. Users MUST be aware of the appropriate persons to contact in the event of a suspected malware infection. Users MUST inform their designated contacts if they suspect an infection involving a malicious program.
OPS.1.1.4.A9 Reporting Malware Infections [User] (S)
The virus protection program used SHOULD block and report malware infections automatically. These automatic reports SHOULD be sent to a central location. The employees responsible SHOULD then decide how to proceed based on the current situation. The procedure to be followed in case of reports and alarms from virus protection programs SHOULD be planned, documented, and tested. In particular, the actions to be taken in case of a confirmed infection SHOULD be specified.
OPS.1.1.5 Logging
Target Object: Information domain/generic aspects / Order: R1
OPS.1.1.5.A1 Drawing Up a Security Policy for Logging [Process Owner] (B)
Based on an organisation's general security policy, a specific security policy SHOULD be drawn up for logging. This security policy MUST transparently describe requirements and specifications on how logging is to be planned, set up, and securely operated. This security policy MUST specify what is to be logged, as well as how and where. In this regard, the type and scope of logging SHOULD be based on the protection needs of the information in question. This security policy MUST be drawn up by the CISO together with the Process Owners. It MUST be known to all employees in charge of logging and be integral to their work. If this security policy is changed or deviations from the requirements are allowed, this MUST be coordinated with the CISO and documented. The correct implementation of this specific security policy MUST be regularly reviewed. The results of these reviews MUST be documented.
OPS.1.1.5.A10 Access Protection for Log Data (S)
It SHOULD be ensured that administrators who execute logging have no authorisation to modify or delete recorded log data.
OPS.1.1.5.A11 Increasing the Scope of Logging (H)
If applications or IT systems require increased protection, more events SHOULD be logged so that security-relevant incidents can be traced as completely as possible. To ensure that log data can be evaluated in real time, it SHOULD be stored centrally at shorter intervals by the relevant IT systems and applications. Logging SHOULD enable assessment of the entire information domain in question. Applications and IT systems that do not allow for central logging SHOULD NOT be used in case of increased protection needs.
OPS.1.1.5.A12 Encryption of Log Data (H)
Log data SHOULD be encrypted for secure transfer. All saved logs SHOULD be digitally signed. Archived log data and log data stored outside the corresponding logging infrastructure SHOULD also always be stored in an encrypted manner.
OPS.1.1.5.A13 Highly-Available Logging Infrastructure (H)
A highly available logging infrastructure SHOULD be created.
OPS.1.1.5.A3 Configuring Logging at the System and Network Level (B)
All security-relevant events of IT systems and applications MUST be logged. If the IT systems and applications defined as relevant in a logging policy have a logging function, it MUST be used. When setting up logging, the manufacturer specifications for the relevant IT systems or applications MUST be considered. Spot checks MUST be carried out at appropriate intervals to ensure that logging is still functioning correctly. The intervals of these checks MUST be defined in the logging policy at hand. If events relevant to operations and security cannot be logged on an IT system, additional IT systems MUST be integrated for logging (e.g. for events at the network level).
OPS.1.1.5.A4 Time Synchronisation of IT Systems (B)
The system time of all logging IT systems and applications MUST always be synchronous. It MUST be ensured that the date and time formats of log files are uniform.
OPS.1.1.5.A5 Complying with Legal Framework Conditions (B)
The regulations of the current laws on federal/state data protection MUST be followed during logging (see CON.2 Data Protection). Moreover, any personal rights and/or rights of co-determination of the Employee Representatives in question MUST be observed. Compliance with any other relevant legal regulations MUST also be ensured. Log data MUST be deleted in accordance with a specified process. Technical provisions MUST prevent log data being deleted or changed in an uncontrolled manner.
OPS.1.1.5.A6 Basic Structure of a Centralised Logging Infrastructure (S)
In larger information domains in particular, all collected security-relevant log data SHOULD be stored in a central location. To this end, a central logging infrastructure (read: a log server system) SHOULD be designed and placed in a network segment created for this purpose (see NET.1.1 Network Architecture and Design). In addition to security-relevant events (see OPS.1.1.5.A3 Configuring Logging at the System and Network Level), a central logging infrastructure SHOULD also log general operational events that indicate errors. The logging infrastructure SHOULD have sufficient capacity. The possibility of scaling up this infrastructure to support extended logging SHOULD be considered. To this end, sufficient technical, financial, and personnel resources SHOULD be available.
OPS.1.1.5.A8 Archiving of Log Data (S)
Log data SHOULD be archived. The legally required regulations SHOULD be taken into account in this regard.
OPS.1.1.5.A9 Providing Log Data for Assessment (S)
Collected log data SHOULD be filtered, normalised, aggregated, and correlated. Log data processed in this way SHOULD be made available in a manner suitable for assessment. Logging applications SHOULD have corresponding interfaces for assessment programs so that the data can be assessed automatically. It SHOULD be ensured that the evaluation of log data complies with the security requirements defined in the respective logging policy. Operational and internal agreements SHOULD also be taken into consideration when log data is made available. Log data SHOULD be stored unchanged in its original format.