Understanding EU's NIS2 Cybersecurity Directive
What is the NIS2 Directive for Cybersecurity in the European Union and how should critical infrastructure entities address their OT security program?
Learn MoreAt the end of 2022, the European Union published the final version of “Measures for a high common level of cybersecurity across the Union”, also called “NIS2”. This is the successor of the “Network and Information Security Directive” (NISD), which was released in 2016. The directive provides legal measures to improve overall cybersecurity across the EU. This includes obligations for businesses, government authorities and cooperation between EU member states on security risks and incidents. We have published an overview of the final NIS2 directive in which we outline the key elements of NIS2, its coverage for different entities, and the controls covered.
In summary, the NIS2 standards will eventually be implemented by each country with their own specific guidelines that meet the overall NIS2 higher-level requirements. Those requirements include both basic security guidelines of operations as well as monitoring and reporting guidelines to ensure incidents are rapidly reported and resolved.
The following measures represent the minimum requirements to be covered:
- Asset management
- Basic cyber hygiene practices and cybersecurity training
- Incident handling (we discuss potential expected measures in Chapter II)
- Policies for risk analysis, information system security, and access control
- Policies and procedures to assess the effectiveness of cybersecurity risk-management measures
- Business continuity, such as backup management, disaster recovery, and crisis management are in place
- Supply chain security of relationships between the entity and it’s direct suppliers/service providers are in place and consider…
- … vulnerabilities specific to each supplier/service provider, and
- …product quality and cybersecurity practice of their supplier including secure development procedures
- … results of coordinated security risk assessment of critical supply chains
- Security in network and information systems lifecycle, including vulnerability handling and disclosure
- policies and procedures regarding the use of cryptography and, where appropriate, encryption
- Use of multi-factor authentication or continuous authentication solutions, secured voice, video, and text communications, and secured emergency communication systems within the entity, where appropriate
An overview of a timeline with preventive and detective risk management measures (A3) an security incident, and the following reporting duties (A2) was provided in the presentation we gave on the final NIS2 directive.
Details on how to comply with NIS2 in detail are not yet published by the commission, and each country will eventually define their own specific standards for how to comply. We, therefore, mapped major NIS2 requirements with the already existing and established security framework from one EU country. The reason for this is that it provides a solid grounding of the types of controls that may go from “recommended” to “required” once NIS2 takes effect in October 2024.
The table and analysis below is based on the security framework and methodology used by the German BSI (“IT-Baseline Protection Compendium”). Each control-set is either a minimum requirement (MUST), a standard requirement (SHOULD) or suggested when a high level of security is required (SHOULD).
What is the IT-Grundschutz compendium:
The Compendium is a set of guidelines and good practices for security management, developed by the German Federal Office for Information Security (BSI). The main purpose is to provide organizations with a structured, systematic, risk-based, and maturity-related approach to IT, OT, and IoT security. We will just cover incident management and OT protection. The compendium is designed to be flexible and adaptable and to be used by organizations of any size. The guidelines are updated once a year to reflect changes in the threat landscape and technological progress.
This compendium provides hundreds of control-sets (>1000 controls), organized in dozens of categories (“modules”). For the purpose of mapping only the most relevant for NIS2 requirements, we focus only on a set of modules around the topics
- Incident detection and reporting, and
- OT security
All modules have a specific order (marked with R1-R3 in the table below) in which they should be implemented, this leads to the following coverage and order:
- System logging is a prerequisite, its measures are the foundation of the later processes of event collection and detection. Logging is also referred to in the Industrial IT chapter as a baseline requirement.
- Event detection and incident handling are two related process steps: Every security event has the potential to compromise security. Security incidents are those type of events that involves an actual or potential security breach. Not every event leads to an incident, but the ones that do are incidents.
- Operational Technology (OT) is a dedicated chapter of the compendium and deals with security measures to protect industrial equipment down to specific components like PLC. We only included the most generic controls related to NIS2, the OT modules also require a system logging (position #1) to be in place.
- The last area of incident handling from the compendium is the remediation of large-scale incidents. These can be complex and far-reaching breaches, like those from Advanced Persistent Threats (APT) that require a systematic approach to removal, recovery, and future attack prevention.
For each security aspect from the list above, the compendium includes a set of basic, standard, and high protection measures.
Based on our exchange with a local authority, it can be expected that all basic and standard measures of the list below will be required by NIS2 for both, essential and important entities. Basic measures should be implemented first. We added a description how Verve helps its clients in achieving this control within their OT environments. Finally, it includes some comments on how an organization might implement each of the controls.
This is offered as one detailed view of how NIS2 may be implemented in a specific geography to provide some guidance as organizations seek to get ahead of what is likely to be a busy 2024 and 2025.
| Control ID | Title | Description | Order | Requirements | Verve Solution | Comments |
|---|---|---|---|---|---|---|
| OPS.1.1.5 | System Logging (Overall responsibility: IT Operations Department) | R1 | ||||
| OPS.1.1.5.A1 | Drawing Up a Security Policy for Logging | Based on an organization’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. The security policy MUST specify what is to be logged, as well as how and where. Here, the type and scope of logging SHOULD be based on the protection needs of the information in question. The 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 the security policy is changed or deviations from its 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. | Basic Standard High | Services | Verve’s OT security professional services team can help to define the appropriate logging policies for OT to align with IT policies. Verve’s asset detection and management capabilities can be used to ensure the policy is applied across the environment. Verve’s logging capabilities allow to perform a regular and automated log review. | |
| OPS.1.1.5.A3 | Configuring Logging at the System and Network Level | All security-relevant events pertaining to 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). | Basic Standard High | Supports | Verve can collect time series log data like system, security, and network logs. Verve’s logging and storage and analytics capabilities can be used to store log data, and Verve can provide an overview that all relevant asset logs are collected. | |
| OPS1.1.5.A4 | Time Synchronization of IT Systems | The system time of all IT systems and applications that generate logs MUST always be synchronous. It MUST be ensured that the date and time formats of log files are uniform. | Basic Standard High | Supports | This is more an organizational process (ensure time server is setup) Verve provides information which time server is setup for OS-based endpoints, or alternatively request the system time from OS-based assets. | |
| OPS1.1.5.A5 | Complying with Legal Framework Conditions | The regulations of the current laws on federal- and state-level data protection MUST be followed during logging (Compliance with the legal provisions like GDPR on data protection MUST be ensured). 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. | Basic Standard High | Supports | Verve’s software can be aligned to whatever policy the organization has taken regarding log collection and storage. | |
| OPS1.1.5.A6 | Basic Structure of a Centralised Logging Infrastructure | All security-relevant logging 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. 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 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. | Standard High | Supports | Verve supports central logging functions on a per site, region or enterprise level. Verve can also collect and forward log data to a central log server. To support legacy and proprietary log sources, Verve has developed a number of data collectors. IT parses them to alert on security-relevant events. | |
| OPS1.1.5.A8 | Archiving of Log Data | Log data SHOULD be archived. The relevant legal regulations SHOULD be taken into account in the process. | Standard High | Supports | Verve supports archiving of log data in relation to legal regulations. | |
| OPS1.1.5.A9 | Providing Log Data for Assessment | Collected log data SHOULD be filtered, normalized, 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 to programs capable of automatic data analysis. 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 making log data available. Log data SHOULD be stored unchanged in its original format. | Standard High | Supports | As part of the data aggregation process all data is normalized, aggregated and correlated. Verve security analytics are applied across the log data and enriched with additional security context information (like e.g. vulnerabilities, exiting exploits, etc.) to provide a comprehensive risk picture. Automatic and manual data analysis can be performed based on log data. | |
| OPS.1.1.5.A10 | Access Protection for Log Data | It SHOULD be ensured that administrators who execute logging have no authorization to modify or delete recorded log data. | Standard High | Supports | For log data stored and processed by Verve this can be ensured. | |
| OPS1.1.5.A11 | Increasing the Scope of Logging | If applications or IT systems require increased protection, more events SHOULD be logged so that security-relevant incidents can be traced as comprehensively 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. | High | Supports | Verve processes log data near real time and generates automated alert based on hundreds of detection roles which can be extended. | |
| OPS.1.1.5.A12 | Encryption of Log Data | 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. | High | Supports | All security-related log and analytical data that Verve processes is encrypted and transferred as securely as possible. | |
| OPS.1.1.5.A13 | Highly Available Logging Infrastructure | A highly available logging infrastructure SHOULD be created. | High | Supports | The central components of the Verve Security Center (including logging) support HA operations. | |
| DER.1 | Detecting Security-Relevant Events (Overall responsibility: IT/OT Operations, CISO) | R1 | ||||
| DER.1.A1 | Creation of a Security Policy for the Detection of Security-Related Events | 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. | Basic Standard High | Supports | Verve’s professional services team can support in development of these standards for OT and Verve’s software can enable Verve’s asset detection and management capabilities can be used to help ensure technical elements of the security policy are applied across the environment and includes all relevant assets. Verve can report on technical non-compliance across all assets from the library, including embedded systems. | |
| DER.1.A2 | Compliance with Legal Conditions When Analysing Log Data | When analyzing 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. | Basic Standard High | Supports | Verve’s software can be aligned to whatever policy the organization has taken regarding log collection and storage. | |
| DER.1.A3 | Definition of Reporting Paths for Security-Relevant Events | 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. | Basic Standard High | Supports | Contact information can be added for each asset of the library. A report can assure that all detected assets/network segments/OEM vendor equipment has contact information for security events. Multiple contact information can be stored. Asset data, like security context information can be provided by Verve with ticketing or service management systems like ServiceNow. | |
| DER.1.A4 | Raising Employee Awareness | 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 below DER.2.1 Security Incident Handling). Every employee MUST immediately report a security incident they have detected to the incident management department. | Basic Standard High | Services | Verve’s professional services can communicate and train OT personnel on this requirement. | |
| DER.1.A5 | Use of Detection Features Included in Systems (Process Owner) | 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 person responsible. The responsible parties MUST evaluate and investigate these messages. | Basic Standard High | Supports | Verve’s Think Global: Act Local approach identifies log-ready systems and applications, because Verve provides an asset and risk picture across a global organization. Verve also alerts if events information changed or are suddenly absent. Verve integrates information from major malware scanners and incorporates the information into a vendor-agnostic and integrated asset risk picture. Verve assures malware on local scanners are actually in operation. | |
| DER.1.A6 | Continuous Monitoring and Analysis of Log Data | All log data SHOULD be actively monitored and analyzed 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. | Standard High | Supports | Verve reporting swiftly monitors, prioritizes and resolves security risks at early stages. The event detection capabilities detect potential malicious behavior, and analytic capabilities are used to alert on single or a series of potential harmful activity across different log sources. Verve provides several hundred automated alert rules. | |
| DER.1.A7 | Training of Responsible Persons | The people 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. | Standard High | Services | Verve provides enablement and training services as part of the software deployment. Verve’s clients are enabled to operate the solution in the most effective way and with limited resources. | |
| DER.1.A9 | Use of Additional Detection Systems | 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). | Standard High | Supports | Verve supports collecting asset and security data from OS-based systems, embedded systems and network equipment. The data (like OS patch level information) is directly copied from the endpoint which assures high data accuracy. With network device information Verve is capable to provide near real time data on network topology and communication relations. The data from NIDS can be incorporated. | |
| DER.1.A10 | Use of TLS/SSH Proxies | 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. | Standard High | Supports | Verve provides professional services in networking to ensure OT networks are properly architected to ensure this requirement. Verve’s software supports the integration of proxy system logs into the Verve Security Center. | |
| DER.1.A11 | Use of a Central Logging Infrastructure to Evaluate Security-Relevant Events (Process Owner) | 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. | Standard High | Supports | Log data as well as the analytic information is centrally stored and can be filtered and exported with standard data exchange formats at the wanted level of granularity. Detection signatures provided by Verve are regularly updated. | |
| DER.1.A12 | Evaluation of Information from External Sources (Process Owner) | 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. | Standard High | Supports | Verve automatically uses public domain information for vulnerabilities, published exploits, MITRE ATT&CK information and software/firmware patch information. For targeted attacks (like Wannacry) or complex vulnerabilities (like Log4j), additional tools are provided to quickly detect and remediate the threat. All data is parsed during the import process. Verve can also incorporate OEM vendor security advisories to determine the most appropriate response to an event. (Escalations are usually done in connected ticketing systems.) | |
| DER.1.A13 | Regular Audits of Detection Systems | 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. | Standard High | N/A | This is an audit process. Verve is audit proof and can be used to determine a base asset count on which the audit evidence size can be built on. Statistical information can be provided to evidence events are detected and reported (and remediated). Verve provides flexible drill-down and filtering reporting capabilities to audit specific portions of the event detection. | |
| DER.1.A14 | Evaluation of Log Data by Specialised Personnel | 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. | High | N/A | Verve makes best use of the limited expertise that analyze log and event data by pre-processing events and prioritizing potential risks. | |
| DER.1.A15 | Central Detection and Real-Time Examination of Event Messages | 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. | High | Supports | Verve provides centralized event detection and automated reporting capabilities. Further analysis on endpoints on collected endpoint related security data determines the risk and evaluates potential remediation measures. All events from the environment are available at a central platform which allows quick and deep event analysis. Verve provides capabilities to automatically alert to predefined or custom events, chain of events or events across different platforms. Flexible alert thresholds can be defined and improved over time. Triggering of event communication can be achieved by integrating Verve with a ticketing or service management system. | |
| DER.1.A16 | Use of Detection Systems in Accordance with Protection Requirements | 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. | High | Supports | Verve identifies installed or running applications at the OS-level. This information is incorporated to identify assets with higher protection needs. In that case, the Verve platform is leveraged to perform endpoint security changes (e.g. system hardening) that lead to a higher technical protection level. | |
| DER.1.A17 | Automatic Reaction to Security-Relevant Events | 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 data flows in order to prevent a possible security incident. | High | Supports | An automated reaction (like quarantining malware in AV solutions) control have unpredictable impact and usually is not accepted in OT environments. Verve's approach to prevent an incident in operational environments is to provide rich endpoint security information to address risks before they become a threat. Verve has also included the MITRE ATT&CK framework into it’s reporting to detect potential breaches early in the process. | |
| DER.1.A18 | Performance of Regular Integrity Checks | 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. | High | Supports | Verve performs automated self-checks to assure detection capabilities are operational and 3rd party data connectors are functional. | |
| DER.2.1 | Security Incident Handling (Overall responsibility: CISO) | R1 | ||||
| DER.2.1.A1 | Definition of a Security Incident | 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. | Basic Standard High | N/A | Security policy aspect. | |
| DER.2.1.A2 | Drawing Up a Policy for Handling Security Incidents | A policy governing the handling of security incidents MUST be prepared. This policy MUST define its purpose and objective and govern all aspects of handling security incidents. It MUST therefore describe codes of conduct for the different types of security incidents. In addition, there MUST be target-group-oriented and practically usable instructions for all employees. Furthermore, the interfaces with other management areas SHOULD be taken into account, including in business continuity management. All employees MUST be familiar with the policy. It MUST be agreed by the IT Operation Department and approved by the organisation’s Top Management. The policy MUST be reviewed and updated regularly. | Basic Standard High | N/A | Verve provides OT guidance, but this is primarily an enterprise task. Verve handles security incidents in a highly efficient way due to the capability (e.g. remove services/libraries and make changes to the security configuration of an endpoint). These capabilities then can be considered which leads to a more sophisticated and OT-accepted way to handle security incidents. | |
| DER.2.1.A3 | Specification of Responsibilities and Contact Persons in the Event of Security Incidents | It MUST be specified who will be responsible for what in the event of security incidents. The tasks and competencies applicable in the event of security incidents MUST be defined for all employees. In particular, the employees who will handle security incidents MUST be informed of their tasks and competencies. In this context, it MUST be specified who will make the eventual decision regarding a forensic examination, the criteria to be followed in carrying it out, and when this should take place. The employees MUST know the contact persons for all types of security incident. Contact information MUST always be updated and easily accessible. | Basic Standard High | Services | Verve professional services communicate these policies, and the Verve software can be configured to maintain a database of responsible parties for each OT system. | |
| DER.2.1.A4 | Notification of Entities Affected by Security Incidents | When a security incident occurs, all the internal and external entities affected MUST be informed of the incident promptly. In this process, it MUST be checked whether the Data Protection Officer, the works council and personnel council, and employees from the legal department must be consulted. The reporting duties for public authorities and regulated industries MUST be taken into consideration, as well. Furthermore, it MUST be guaranteed that the entities affected are informed of the actions they need to take. | Basic Standard High | N/A | This is a process, not a function of software. Asset information that allows quick and complete identification of internal/external notification receivers can be maintained with the asset data in the Verve Asset Manager. | |
| DER.2.1.A5 | Remedial Action in Connection with Security incidents | the person responsible MUST initially contain the problem and find the cause. They MUST then select the safeguards necessary to fix the problem. The head of the IT Operation Department MUST approve the safeguards before they are implemented. The cause MUST then be eliminated and a secure state established. There MUST be a current list of internal and external security experts who may be consulted in the event of security incidents to answer questions from the subject areas involved. Secure communication methods with these internal and external entities MUST be established. | Basic Standard High | N/A | This is a process, not a function of software. | |
| DER.2.1.A6 | Recovering the Operating Environment After Security Incidents | After a security incident, the affected components MUST be removed from the network. In addition, all necessary data that could provide information about the nature and cause of the problem MUST be backed up. On all the components affected, the operating systems and all applications MUST be checked for changes. The original data MUST be reinstalled from write-protected data storage media. In so doing, all security-related configurations and patches MUST also be implemented. If data from backups is reimported, it MUST be ensured that the data was not affected by the security incident. After an attack, all access data on the affected components MUST be changed before they are put back into operation. The components affected SHOULD be subjected to a penetration test before they are used again. When recovering the secure operating environment, the users MUST be involved in the functional tests of the applications. After everything has been recovered, the components (including the network transitions) MUST be monitored in a targeted manner. | Basic Standard High | Supports | This is a broad recovery and containment process which requires different solutions (backup recovery, re-configuration, system restart). Verve centrally orchestrates the system recovery by performing changes to OS-based systems. Also the monitoring of the recovery status of an OT environment is provided by Verve. | |
| DER.2.1.A8 | Design of Organisational Structures for Handling Security Incidents | Appropriate organisational structures SHOULD be defined for handling security incidents. A security incident team SHOULD be established with members who may be called in depending on the type of incident. Even if the security incident team only meets when a specific incident has occurred, appropriate members SHOULD be appointed in advance and instructed on how to perform their tasks. Regular checks SHOULD be carried out to ensure that the composition of the security incident team is still appropriate. Changes SHOULD then be made to the security incident team as required. | Standard High | N/A | This is primarily an enterprise procedure. | |
| DER.2.1.A7 | Establishment of a Procedure for Handling Security Incidents | A suitable procedure SHOULD be established for handling security incidents. The procedures and specifications for different security incidents SHOULD be clearly stipulated and documented appropriately. An organisation’s Top Management SHOULD implement the agreed procedure and make it accessible to everyone involved. Regular checks SHOULD be carried out to ensure that the procedure is still up to date and effective. The procedure SHOULD then be amended as required. | Standard High | N/A | This is primarily determined by the enterprise process. | |
| DER.2.1.A9 | Definition of Reporting Paths for Security Incidents | Reporting channels SHOULD be established that are appropriate to the different types of security incidents. These SHOULD ensure that employees can report security incidents quickly and easily using reliable and trustworthy channels. If a central contact point for reporting failures or security incidents is established, this SHOULD also be communicated to all employees. There SHOULD be a communication and contact strategy. This strategy SHOULD specify who must be informed as a matter of principle, who may be informed, who is responsible for handling this and in what order, and the level of detail of the information provided. It SHOULD specify who will pass information about security incidents on to third parties. It SHOULD ensure that no unauthorised persons forward information on security incidents. | Standard High | N/A | This is primarily an enterprise procedure. | |
| DER.2.1.A10 | Limiting the Effects of Security Incidents | 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. | Standard High | Supports | Verve software enables these scenarios by developing them in advance to be used during response to identify potential risks and possible remediation paths. | |
| DER.2.1.A11 | Classification of Security Incidents | 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. | Standard High | N/A | This is primarily an enterprise procedure. | |
| DER.2.1.A12 | Specification of Where Security Incident Handling Overlaps with Fault Management | 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. The security management SHOULD have read-only access to the incident management tools used. | Standard High | Services | Verve’s professional services support in the communication and training of OT personnel on these areas. | |
| DER.2.1.A13 | Integration into Security and Business Continuity Management | 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. | Standard High | Services | Verve’s professional services support in the communication and training of OT personnel on these areas. | |
| DER.2.1.A14 | Escalation Strategy for Security Incidents | An escalation strategy SHOULD be formulated that goes beyond the communication and contact strategy at hand. This escalation strategy SHOULD be coordinated among the persons responsible for fault management and information security management. It SHOULD contain clear instructions on who is to be involved in what way and when for each type of identifiable or suspected security incident. It SHOULD also specify the safeguards that are to follow an escalation and how those involved are to respond. Suitable tools (e.g. ticket systems) SHOULD be selected for the defined escalation strategy. These SHOULD also be suitable for processing confidential information. It SHOULD be ensured that the tools will also be available during security incidents and emergencies. The escalation strategy SHOULD be reviewed regularly and updated as required. The checklists (matching scenarios) for fault management SHOULD be complemented by security-relevant topics and updated regularly. The defined escalation paths SHOULD be tested by means of drills. | Standard High | Services | Verve’s professional services support in the communication and training of OT personnel on these areas. | |
| DER.2.1.A15 | Training Service Desk Employees | Service desk employees SHOULD have appropriate tools at their disposal to enable them to identify security incidents. They SHOULD be sufficiently trained to use the tools themselves. Service desk employees SHOULD be familiar with the protection needs of the IT systems in question. | Standard High | N/A | Enterprise service desk responsibility. | |
| DER.2.1.A16 | Documentation for Remedying Security Incidents | The process of remedying security incidents SHOULD be documented in accordance with a standardised procedure. All actions performed and the respective times SHOULD be documented along with the log data of the components affected. In so doing, confidentiality SHOULD be guaranteed while documenting the information and archiving the reports. The necessary information SHOULD be entered into the respective documentation systems before the disruption in question is considered over. The necessary quality assurance requirements SHOULD be defined in advance with the CISO. | Standard High | N/A | Likely enabled through enterprise or OT-specific change management procedures. | |
| DER.2.1.A17 | Evaluation/post-processing of Security Incidents | Security incidents SHOULD be evaluated in a standardised manner. This SHOULD examine how quickly security incidents are detected and remedied. It should also investigate whether the reporting channels worked, whether sufficient information was available for evaluation, and whether the detection safeguards were effective. It SHOULD also check whether the implemented safeguards and activities were effective and efficient. The experience gained from previous security incidents SHOULD be used to develop instructions for comparable security incidents. These instructions SHOULD be announced to the relevant groups of persons and updated at regular intervals on the basis of new findings. An organisation's Top Management SHOULD be informed of the security incidents at annual intervals. If there is a need for immediate action, the Top Management MUST be informed immediately. | Standard High | N/A | This is mostly a procedural and organizational element, but the Verve software provides data on when alerts/logs are created for use in calculating time to respond or remediate. | |
| DER.2.1.A18 | Further Development of Processes Based on Findings from Security Incidents and Industry Developments | After a security incident has been analysed, there SHOULD be an investigation of whether the procedures for handling security incidents need to be changed or developed further. All those involved in the incident SHOULD report on their respective experiences. Whether there are new developments in the field of incident management and forensics and whether these can be incorporated into the respective documents and procedures SHOULD be examined. If checklists and auxiliary resources are being used (e.g. by service desk members), a check SHOULD be carried out on whether these should be complemented by relevant questions and information. | Standard High | N/A | This is an organizational requirement for the enterprise. | |
| DER.2.1.A19 | Specifying Priorities for Handling Security Incidents | Priorities for handling security incidents SHOULD be established in advance and updated regularly. This SHOULD also take into account the classification of security incidents. The priorities SHOULD be approved and implemented by an organisation’s Top Management. All those with decision authority who are involved in handling security incidents SHOULD be familiar with them. The defined priority classes SHOULD also be stored in an incident management system. | High | Supports | Verve’s professional services support the ranking of OT incidents. In addition, Verve software provides insight into the ranking based on criticality of the assets and networks in question. | |
| DER.2.1.A20 | Creation of a Dedicated Reporting Office for Security Incidents | A dedicated office SHOULD be established for reporting security incidents. It SHOULD be guaranteed that the reporting office is available during normal office hours. However, it SHOULD also be possible for employees to report security incidents outside of normal office hours. The reporting office employees SHOULD be adequately trained and aware of issues related to information security. All information on security incidents SHOULD be treated confidentially within the reporting office. | High | N/A | Enterprise office/organization. | |
| DER.2.1.A21 | Assembling a Team of Experts for Handling Security Incidents | A team of experienced and trusted experts SHOULD be established. Along with technical expertise, the members of the team SHOULD also have competences in the field of communication. The trustworthiness of the members of the team of experts SHOULD be checked. The composition of the expert team SHOULD be checked regularly and changed as necessary. The members of the team of experts SHOULD be included in the escalation and reporting channels. The team of experts SHOULD be trained to analyse security incidents in the systems deployed in their organisation. The members of the team of experts SHOULD receive regular training in both the systems used and detecting and responding to security incidents. The team of experts SHOULD have access to any existing documentation and the financial and technical resources required to handle security incidents quickly and discretely. The expert team SHOULD be appropriately considered and integrated into the organisational structures at hand. The responsibilities of the expert team SHOULD be coordinated in advance with those of the security incident team. | High | N/A | Enterprise office/organization. | |
| DER.2.1.A22 | Reviewing Management System Efficiency in Handling Security Incidents | Regular checks SHOULD ensure that the management system for handling security incidents is still up to date and effective. To this end, both announced and unannounced drills SHOULD be conducted. The drills SHOULD be coordinated in advance with the Top Management of the organisation in question. The parameters that are measured when security incidents are recorded, reported, and escalated (e.g. the time from the initial report to the binding confirmation of a security incident) SHOULD be evaluated. In addition, simulation exercises SHOULD be conducted on the handling of security incidents. | High | N/A | Enterprise office/organization. | |
| IND.1 | Process Control and Automation Technology (Overall responsibility: ICS Information Security Officer) | R2 | ||||
| IND.1.A1 | Integration into the Security Organisation | An information security management system (ISMS) for the operation of OT infrastructure MUST exist either as a stand-alone ISMS or as part of an overall ISMS. A person MUST be appointed with overall responsibility for OT information security. The details of this appointment MUST be publicised within the organisation in question. | Basic Standard High | Supports | This is a process, however Verve provides the technology and services that uniquely support 3 key ISMS processes for OT: 1. Performing a risk assessment and management: Our platform allows clients to establish a continuous and automated risk assessment including risk remediation. 2. Security Incident Management: By providing tools that supporting processes to detect, report and respond to security incidents 3. Continuous Monitoring and Improvement The quality and amount of assets and security-related data detected and simultaneously supporting a security response allows Verve to measure the security performance like no other solution. | |
| IND.1.A3 | Malware Protection | When using anti-virus software on OT components, consideration MUST be given to whether and in which configuration the operation of anti-virus software is supported by its manufacturer. If this is not the case, the need for alternative protection methods MUST be checked. Virus signatures MUST NOT be obtained by OT systems directly from the Internet. | Basic Standard High | Supports | Verve integrates operational data from AV solutions as a data point to determine the risk for an asset. Verve provides malware protection by hardening the operating system. We detect active malware based on its impact on the system (spawned processes, opening ports) or hardware impact (CPU/network load). | |
| IND.1.A4 | Documentation of OT Infrastructure | All the security-relevant parameters of the OT infrastructure at hand SHOULD be documented. All software and system components SHOULD be documented in an inventory list. This list SHOULD state the product and protocol versions used, as well as the respective responsibilities. For the components used, any applicable manufacturer restrictions or regulatory conditions SHOULD be defined. This documentation and a system inventory SHOULD be maintained—for example, in a control system. In addition to this, an up-to-date network plan SHOULD document zones, zone transitions (conduits), and the communication protocols and methods used, as well as the external interfaces. For the interfaces, active network components and manual data transfer methods (e.g. using removable media) SHOULD be taken into account. Automation solutions SHOULD be structured into cells and communication channels to enable the zones and conduits at hand to protect the OT infrastructure. | Standard High | Supports | Verve provides comprehensive hardware, software and configuration data for assets within the OT environment. Verve’s data collection and reporting allows clients to identify and enforce network topology and segmentation needs. Verve provides alerts on changes to network protections or where communications breach intended network segmentation. | |
| IND.1.A5 | Development of Appropriate Zone Concept | OT infrastructure SHOULD also be segmented horizontally into independent functional areas such as facilities. The individual zones SHOULD be as independent of one another as possible during operations. In particular, the zones where the respective technical process is controlled SHOULD continue to function for a certain period of time if the other zones fail. Decoupling SHOULD also continue to function after an attack. This period SHOULD be suitably defined and documented. The network SHOULD be designed to be resistant to errors and manipulation. | Standard High | Supports | Verve’s professional services support clients in designing and implementing segmentation across IT/OT and within OT. In addition, the Verve software provides detection capabilities on changes that might impact that segmentation and alerting on potential communications across segments. | |
| IND.1.A6 | Change Management in OT Operations | A suitable change process SHOULD be defined, documented, and used actively when making changes to OT. | Standard High | Supports | While this is a procedural requirement, Verve software provides a comprehensive change management capability to detect and alert on changes. It includes detecting changes to the security configuration, installed software and user accounts. | |
| IND.1.A7 | Establishing Comprehensive Authorisation Management Across OT and Office IT | An organisation SHOULD establish a process for managing user access and assigned authorisations for OT. A corresponding authorisation management system SHOULD cover this process, along with the implementation and documentation of activities involved in applying for, configuring, and withdrawing authorisations. The authorisation management system SHOULD ensure that authorisations are granted according to the minimum principle and checked at regular intervals. In the authorisation management system, access to IT systems SHOULD be regulated for employees, administrators, and third parties. Everyone involved SHOULD be made aware of the rules to be followed at regular intervals. Compliance SHOULD be checked. Misconduct SHOULD be sanctioned. | Standard High | Supports | User authentication in OT is often complex with shared accounts, multiple OEM-based domains, etc. Verve aggregates user and access information across systems to provide the data to enable the appropriate authorization management functions. | |
| IND.1.A8 | Secure Administration | For the initial configuration, administration, and remote maintenance of OT, either secure protocols or separate administration networks with corresponding protection needs SHOULD be used. Access to these interfaces SHOULD be restricted to the persons authorised. The access granted to systems and functions SHOULD be limited to the requirements for the respective administration tasks. The systems and communication channels used to carry out administration or remote maintenance SHOULD have the same level of protection as the OT components administered. | Standard High | N/A | This is a secure setup process, not a technology function. The network and endpoint data gathered by Verve reviews if the process is followed. Verve sets up and configures secure remote administration at the endpoint OS-level. | |
| IND.1.A9 | Restrictive Use of Removable Media and Mobile Devices in ICS Environments | Rules for handling removable media and mobile devices SHOULD be established and communicated. The use of removable media and mobile devices in ICS environments SHOULD be restricted. For the media and devices of service providers, an approval process and a requirements list SHOULD be available. Each service provider SHOULD be familiar with the specifications and confirm them in writing. On OT components, all interfaces that are not required SHOULD be disabled. The usage of active interfaces SHOULD be restricted to certain devices or media. | Standard High | Supports | Rules are a procedural item. However, Verve can restrict mobile media access at OS level and detect and alert on attempts to use USB or Bluetooth. In case operations is working exclusively with engineering offices, a Verve sensor can be applied to the service technician’s computer to review and alert on technical aspects of the corporate security policies. | |
| IND.1.A10 | Monitoring, Logging and Detection | Operational and security-relevant events SHOULD be identified promptly. For this purpose, a suitable approach to log and event management SHOULD be developed and implemented. Log and event management SHOULD include adequate measures to detect and record security-relevant events. It SHOULD also include a security incident response plan. The response plan SHOULD define procedures for handling security incidents. This plan SHOULD cover the classification of events, reporting channels and the definition of the organisational units to be involved, response plans to limit damage, the analysis and restoration of systems and services, and the documentation of and follow-up process for incidents. | Standard High | Supports | Verve provides OT-relevant logs and event management and identifies and maps alerts according to the MITRE ATT&CK framework. Risks are detected from logged events, OS and software versions, patch level and security configurations, running services and dormant user accounts. The incident response plan described here is mainly a procedure and not covered by technology. Verve’s response and remediation functions defines a mature, semi-automated and orchestrated response procedure that is both, operationally safe and OT accepted. | |
| IND.1.A11 | Secure Procurement and System Development | If OT systems are to be procured, planned, or developed, information security regulations SHOULD be established in this regard. The documents SHOULD be part of any related tender. During procurement, planning, or development, information security SHOULD be taken into consideration through the entire lifecycle. Prerequisites and implementation instructions for the secure operation of ICS components by manufacturers SHOULD be planned and implemented at an early stage. Uniform requirements for information security that correspond to the protection needs at hand SHOULD be defined for ICS components. These SHOULD be taken into consideration when procuring new ICS components. Compliance and implementation SHOULD be documented. The organisation in question SHOULD document how the system fits into its concepts for zoning, authorisation, and vulnerability management (as well as for virus protection) and adapt them if necessary. A plan for maintaining operations should a given partner stop providing its services SHOULD be formulated. | Standard High | N/A | Secure procurement is an organizational process with procedures across different divisions and not covered by technology. Other aspects are OEM vendor or responsibilities of the integrator. | |
| IND.1.A12 | Establishing Vulnerability Management | To ensure the secure operation of its OT environment, an organisation SHOULD establish a vulnerability management approach. Vulnerability management SHOULD identify gaps in software, components, protocols, and external interfaces in the environment under consideration. It SHOULD also make it possible to derive, assess, and implement necessary actions. This SHOULD be based on reports on vulnerabilities from manufacturers and publicly available CERT messages. In addition, organisational and technical audits SHOULD be performed for vulnerability analysis. | Standard High | Supports | Verve uses its deep asset inventory, software and patch data to provide vulnerability assessments in an OT-safe manner without the need for vulnerability scanning which can harm sensitive OT systems This approach identifies software and configuration risks. The Verve Security Center provides several actionable reports for vulnerability management. | |
| IND.1.A13 | Contingency Planning for OT | Business continuity plans SHOULD be defined, documented, tested after each major change, and drilled regularly for each zone to address the possibility of it failing or becoming compromised. An effective substitute procedure SHOULD also be defined, documented, and tested in case the option of (remote) administration fails. | High | N/A | BCP should be defined as a procedural element. | |
| IND.1.A14 | Strong Authentication at OT Components | A central directory service SHOULD be set up for the secure authorisation of privileged users in the control systems at hand. Authentication SHOULD be secured further using several factors, such as knowledge, ownership, or biometrics. During planning, it SHOULD be ensured that any resulting dependencies in user authentication are known and taken into consideration when implementing a corresponding solution. It SHOULD be ensured that operationally required technical accounts can be authorised in emergencies. | High | Services | Verve’s professional services team supports the deployment of directory services that are OT-safe and effective. | |
| IND.1.A15 | Monitoring of Wide-Ranging Authorisations | cOrganisations SHOULD maintain an inventory of all the access rights that have been granted for critical systems. This inventory SHOULD list the rights a particular user effectively has and who has what rights on a particular system. All critical administrative activities SHOULD be logged. The IT Operation Department SHOULD NOT be able to delete or manipulate the logs. | High | Supports | Verve supports local user account reporting. A check could be performed if all local user accounts of critical systems are noted in the according inventory. Verve can review, report or enforce the policy of logging administrative activities and assuring IT Operation Department is not able to delete or manipulate logs. | |
| IND.1.A16 | Strong Separation of Zones | Interface systems with security checking functions SHOULD be used as a preventive measure in ICS environments that are highly sensitive or are difficult to secure. Continuous external connections SHOULD be terminated by implementing one or more connection zones (DMZ) in a P-A-P structure. Required security checks SHOULD be carried out in such a way that the respective ICS system does not have to be adapted. | High | Services | Verve’s professional services team provides network segmentation and design services to ensure this control. | |
| IND.1.A17 | Regular Security Assessment | The security configurations of OT components SHOULD be checked regularly and as needed in the case of sudden threats which were previously unknown. This security vetting SHOULD at least cover exposed systems that involve external interfaces or user interaction. The implemented security concept SHOULD also be checked at regular intervals. Security vetting SHOULD be carried out as a configuration review, or also through automated conformity evaluations. | High | Supports | Verve provides configuration monitoring and creates a baseline against OT secure standards. Changes are alerted on, and if a security baseline configuration is established, non-compliance can be reported on. All this is continuously provided near real time. | |
| IND.1.A18 | Logging | Every change made to ICS components MUST be logged. In addition, all attempts to access to ICS components MUST be logged. | Basic Standard High | Supports | Verve detects a wide range of changes made to endpoints, including embedded systems. Access attempts, as long as they leave an audit trail, are detected. | |
| IND.1.A19 | Create Backups of Programs and Data | Programs and data MUST be backed up regularly. A backup MUST also be made after each system change made to OT components. | Basic Standard High | Supports | Verve provides OT backup solutions in coordination with leading IT backup partners. | |
| IND.1.A20 | System Documentation | Advanced system documentation SHOULD be drawn up. It SHOULD record particularities in operations and options for system administration. In addition, any changes made to ICS components SHOULD be documented. | Standard High | Supports | Verve provides many of the details for such documentation such as asset inventory, connections, etc. | |
| IND.1.A21 | Documentation of Communication Relations | The systems with which an ICS component exchanges data and the data exchanged in this regard SHOULD be documented. Furthermore, the communication links of newly integrated ICS components SHOULD be documented. | Standard High | Supports | Verve provides connection data on which networks a device is connected. It can also provide through integrations detailed information on communications between devices. | |
| IND.1.A22 | Central System Logging and Monitoring | Log data of ICS components SHOULD be stored centrally. In case of security-critical events, alarms SHOULD be raised automatically. | Standard High | Supports | Verve is capable and used as a central log storage, analytics and log data and endpoint data is correlated, analyzed and alerted on. | |
| IND.1.A23 | Disposal of ICS Components | Sensitive data SHOULD be erased prior to the disposal of old or defective ICS components. In particular, it SHOULD be ensured that all access data has been permanently removed. | Standard High | N/A | This is an organizational process. However, Verve is capable of tracking the lifecycle status per asset and alert on conditions like sunset systems still active. | |
| IND.1.A24 | Communication in Case of an Incident | Alternative and independent communication options SHOULD be established and operated. | High | N/A | Organizational requirement. | |
| IND.2.1 | General ICS Components (Overall responsibility: ICS Information Security Officer) | R2 | ||||
| IND.2.1.A1 | Restricted Access for Configuration and Maintenance Interfaces | Passwords set by default or by the manufacturer MUST be changed. These changes MUST be documented. Passwords MUST be stored securely. It MUST be ensured that only authorised employees are allowed to access the configuration and maintenance interfaces of ICS components. The configuration of an ICS component MUST ONLY be changed after the approval or authentication of the person in charge. | Basic Standard High | Supports | Verve supports the process of User Account Reviews by providing a list of all active accounts on OS-based systems. Changes to accounts can be reported on. Password security settings from the registry and deviations from any baseline password can be reported on. | |
| IND.2.1.A2 | Leverage Secure Transmission Protocols for Configuration and Maintenance | Secure protocols MUST be implemented for configuring and maintaining ICS components. Information MUST be protected during transmission. | Basic Standard High | Supports | Verve provides information on ports and services to determine if there are security risks in the configuration of OT systems. | |
| IND.2.1.A4 | Disabling or Uninstalling Unused Services, Functions and Interfaces | All services, features, and interfaces of ICS components that are not being used MUST be disabled or uninstalled. | Basic Standard High | Supports | Verve provides information on ports and services to determine if there are security risks in the configuration of OT systems. | |
| IND.2.1.A6 | Network Segmentation | ICS components MUST be separated from office IT. If ICS components depend on other components in the network in question, this SHOULD be documented sufficiently. ICS components SHOULD communicate as little as possible with other ICS components. | Basic Standard High | Supports | Verve's professional services design and implement such required segmentation. In addition, Verve software monitors for changes to network elements as well as communications that violate the separation. | |
| IND.2.1.A7 | Creating Backups | Backups MUST be created prior to each system change in an ICS component. | Standard High | Supports | Verve provides OT backup solutions in coordination with leading IT backup partners. | |
| IND.2.1.A8 | Malware Protection (with and without AV) | ICS components SHOULD be protected against malware by suitable mechanisms (see OPS.1.1.4 Protection Against Malware). If an anti-virus protection program is used in this regard, the program and the virus signatures approved by the manufacturer SHOULD always be up to date. If the resources on the ICS component are not sufficient or real-time requests could be endangered by the use of anti-virus protection programs, alternative safeguards (such as the isolation of the ICS component or the production network) SHOULD be implemented. ICS components SHOULD be protected against malware by suitable mechanisms (see OPS.1.1.4 Protection Against Malware). If an anti-virus protection program is used in this regard, the program and the virus signatures approved by the manufacturer SHOULD always be up to date. If the resources on the ICS component are not sufficient or real-time requests could be endangered by the use of anti-virus protection programs, alternative safeguards (such as the isolation of the ICS component or the production network) SHOULD be implemented. | Standard High | Supports | Verve integrates with all leading providers of Anti-virus and provides a single data view across these vendors to allow for status review of signatures and versions. In addition, Verve’s professional services team deploys and manages AV and application whitelisting in OT environments. | |
| IND.2.1.A11 | Maintenance of ICS Components | The latest approved security updates SHOULD always be installed when maintaining an ICS component. Updates for the respective operating system SHOULD only be installed following approval by the manufacturer of a given ICS component. Alternatively, updates SHOULD be checked in a test environment before they are used in a productive ICS component. Maintenance SHOULD be performed on short notice for critical security updates. | Standard High | Supports | Verve offers a patch and software update management capability, specifically designed to be safe, effective and efficient within OT environments. | |
| IND.2.1.A13 | Appropriate Commissioning of ICS Components | Before they are commissioned, ICS components SHOULD correspond to the latest internally approved firmware, software, and patch status. New ICS components SHOULD be integrated into existing operating, monitoring, and information security management processes. | Standard High | Supports | This is in part a procedural requirement before devices are connected. However, Verve provides detection of newly connected devices and tracks their firmware and patch status to ensure they meet the latest versions with no known vulnerabilities. | |
| IND.2.1.A16 | Protection of External Interfaces | Externally accessible interfaces SHOULD be protected against misuse. | Standard High | Services | Verve’s professional services team can establish segmentation to enable this. | |
| IND.2.1.A17 | Use of Secure Protocols for the Transmission of Measurement and Control Data | Measurement or control data SHOULD be protected against unauthorised access or changes during transmission. Whether this is necessary or feasible SHOULD be checked in situations involving applications with real-time requirements. If measurement or control data is transmitted using public networks, it SHOULD be protected appropriately. | Standard High | Services | Verve’s professional services team in architecting and implementing OT networks can ensure this requirement. | |
| IND.2.1.A18 | Communication in the Event of Incidents | There SHOULD be alternative and independent communication options that an organisation can use to maintain its ability to function in the event of malfunctions. | High | Services | Verve’s professional services team in architecting and implementing OT networks can ensure this requirement. | |
| IND.2.1.A19 | Security Testing in Maintenance Intervals | Verve’s professional services team in architecting and implementing OT networks can ensure this requirement. | High | N/A | Procedural requirement for third party. | |
| IND.2.1.A20 | Trustworthy Code Integrity of Firmware Updates | Firmware updates or new control programs SHOULD ONLY be installed after their integrity has been checked. They SHOULD only come from trusted sources. | High | N/A | Procedural requirement. | |
| DER.2.3 | Clean-Up of Extensive Security Incidents (Overall responsibility: IT/OT Operations) | R3 | ||||
| DER.2.3.A1 | Creation of a Management Committee | In order to clean up an APT incident, a management committee MUST be created to plan, coordinate, and monitor all the necessary activities. The committee MUST be provided with all the managerial authority necessary for its tasks. If a management committee of this kind was already in place when the APT incident was detected and classified, the same committee SHOULD also plan and oversee the cleaning process. If a specialised forensic service provider has already been brought in to analyse the APT incident, it SHOULD also be involved in the clean-up effort. The idea of setting up a crisis team SHOULD be examined if the IT systems in question are too compromised to continue operating or the clean-up measures are very extensive. In this case, the management committee MUST monitor the clean-up measures. The management committee MUST then report to the crisis team. | Basic Standard High | N/A | Organizational element as part of the overall enterprise security program design. | |
| DER.2.3.A2 | Deciding on a Cleaning Strategy | Before an APT incident is actually cleaned up, the management committee MUST define a cleaning strategy. Here, it MUST be decided in particular whether the malware can be removed from the compromised IT systems and whether certain IT systems have to be reinstalled or replaced completely (including their hardware). Furthermore, the IT systems to be cleaned MUST be defined. These decisions MUST be based on the results of a previous forensic examination. All the IT systems affected SHOULD be reinstalled. Afterwards, the organisation's recovery schemes MUST be followed. Before backups are restored, however, forensic examinations MUST be performed to ensure that no manipulated data or programs will be transferred to a reinstalled IT system. If the organisation decides that it does not want to reinstall all of its IT systems, a targeted APT clean-up process MUST be implemented. To minimise the risk of overlooked backdoors, IT systems MUST be specifically monitored after the clean-up to see if they are still communicating with the attacker. | Basic Standard High | N/A | Organizational element as part of the overall enterprise security program design. | |
| DER.2.3.A3 | Isolation of Affected Network Segments | The network segments affected by an APT incident MUST be isolated completely. In particular, these network segments MUST be cut off from the Internet. In order to effectively lock out the attacker and prevent them from covering their tracks or sabotaging other IT systems, the network segments MUST be isolated simultaneously. The network segments to be isolated MUST be determined in advance through forensic analysis. This MUST identify all the segments affected. If this cannot be guaranteed, all suspicious network segments MUST be isolated along with all those that are only theoretically infected. To effectively isolate network segments, all local Internet connections (e.g. additional DSL connections in individual sub-networks) MUST be documented as comprehensively as possible and taken into account. | Basic Standard High | Supports | Verve can be used to analyze network segments in advance of a threat/incident. Then in the course of an incident, Verve ensures those segments are properly protected. | |
| DER.2.3.A4 | Blocking and Changing Access Data and Cryptographic Keys | All access data MUST be changed after an affected network is isolated. Furthermore, access data managed in a centralised manner MUST also be reset, including in Active Directory environments or when the Lightweight Directory Access Protocol (LDAP) has been used. If the central authentication server (domain controller or LDAP server) has been compromised, all the users on it MUST be blocked and have their passwords changed. This MUST be implemented by experienced administrators and with the help of internal or external forensics experts, if necessary. If TLS keys or an internal certification authority (CA) has been compromised by the APT attack, corresponding keys, certificates, and infrastructures MUST be regenerated and redistributed. The compromised keys and certificates MUST also be reliably blocked and withdrawn. | Basic Standard High | Supports | Verve can be used to address the need to reset passwords as required in OT. | |
| DER.2.3.A5 | Closing the Initial Entry Route | If a forensic examination determines that the attackers used a technical vulnerability to penetrate the network of the organisation in question, this vulnerability MUST be closed. If the attackers were able to compromise the IT systems as a consequence of human error, organisational, personnel-related, and technical measures MUST be taken to prevent similar incidents in the future. | Basic Standard High | Supports | Verve’s patch and configuration management can be used to close these vulnerabilities in OT. | |
| DER.2.3.A6 | Returning to Production Operations | After the affected network has been cleaned successfully, the IT systems MUST be returned to production operations in a controlled manner. In so doing, all the previously used IT systems and installed programs that were used to observe and analyse the attack MUST either be removed or incorporated into the productive environment. The same MUST be done with communication and collaboration systems procured for the purpose of cleaning. Evidence and decommissioned IT systems MUST either be deleted or destroyed securely, or archived appropriately. | Basic Standard High | N/A | In OT, this is a procedural requirement that requires close coordination with process control personnel. | |
| DER.2.3.A7 | Targeted System Hardening | After an APT attack, all the IT systems affected SHOULD be hardened. This SHOULD be based on the results of forensic examinations. In addition, there SHOULD be a further check on whether the affected environment is still secure. If possible, IT systems SHOULD already be hardened as they are being cleaned. Safeguards that cannot be performed on short notice SHOULD be added to an action plan and implemented in the medium term. The CISO SHOULD draw up the plan and check that it has been implemented properly. | Standard High | Supports | Verve can be used to both analyze OT systems for current security status as well as harden those systems as necessary. | |
| DER.2.3.A8 | Establishing Secure, Independent Communication Channels | Secure communication channels SHOULD be established for the management committee in question and the employees charged with cleaning. If third-party communication services are used, care SHOULD be taken to ensure that a secure communication channel is selected. | Standard High | N/A | This is an organizational enterprise requirement. | |
| DER.2.3.A9 | Hardware Replacement in Affected IT Systems | Whether hardware needs to be replaced completely after an APT incident SHOULD be considered. If suspicious behaviour is still observed after cleaning the individual IT systems affected, the respective systems SHOULD be replaced. | High | N/A | Supply chain requirement. | |
| DER.2.3.A10 | Modifications to Help Thwart a Repeat Attack | If an organisation wants to prevent a previous attacker from performing another APT attack on its IT systems, the organisation SHOULD change the internal design of its network environment. Furthermore, mechanisms SHOULD be established that can be used to quickly detect a recurring attacker. | High | Services | Verve supports this through Verve’s professional services network architecture and deployment team. | |
Related Resources
Whitepaper
Whitepaper
5 Principles for Designing a Successful Governance Model for OT Cyber Security
In today’s large and complex industrial organizations, the right cyber security governance structure depends on the culture and existing model of the rest of the organization, as well as coordination and shared decision-rights across IT, security/risk management, operations, and finance. Download the “5 Principles for Designing a Successful Governance Model for OT Cyber Security” to discover the five guiding principles…
Learn More Webinar
Understanding the NIS2 Directive for OT Cyber Security
In this webinar, we discuss the NIS2 directive and examine mandatory and optional NIS2 requirements.
Learn More