Incident Detection and Response

Incident detection and response are the process and activities involved in the identification, analysing, and reacting to potential security incidents within an organisation's IT infrastructure. Incident detection refers specifically to the continuous monitoring of an organisation's infrastructure to detect any signs of malicious activity. For more information related to continuous monitoring or vulnerability management, see the relevant sections of this guide.

The following sections within the NIS 2 may be best suited to fall into the Incident Detection and Response category:

  • Article 21(2) (b): Incident Handling: Incident Management and Reporting

Incident response encompasses several key aspects:

  • Analysis - The investigation and assessment of the scope of the incident to understand what happened and how.

  • Containment - Taking immediate action to prevent additional assets within the organisation from being affected.

  • Eradication - The removal of the threat or vulnerability, which may involve patching systems and/or updating configurations.

  • Recovery - The restoring of data to a known good state or re-installing software.

  • Post-Incident Analysis - The reviewing of the process to identify lessons learned, and improve future security measures.

Effective incident detection and response are crucial for reducing the impact of security incidents on an organisation's operations, reputation, and integrity. Good incident detection response plans include a variety of technologies, a solid vulnerability management program, and well-defined policies and procedures.

Tenable OT Security provides the following capabilities for incident detection:

System Abnormalities for Attack Detection: Tenable OT defines examples of abnormalities in system behaviour that provide practical ways of detecting malicious activity that is otherwise hard to identify. Both a statistical anomaly detection system and a rules-based whitelist/blacklist system to identify system behaviours indicative of compromise where the initial compromising event may not have been detected are used.

Proactive Attack Discovery: Tenable OT uses an informed understanding of more sophisticated attack methods and normal system behaviour to monitor proactively for malicious activity. This includes sophisticated detection not just of attack events, but also the consequences of such events, such as command and control traffic, malware transmission, etc. The event data can be used in frameworks such as MITRE ATT&CK and other TTP frameworks.

Tenable OT tracks and alerts across the following 16 event categories:

  • Code/Configuration/Firmware Transfer - Uploading and downloading code, configurations, and firmware for various PLCs and controllers.

  • Delete - Deleting code, configurations, and firmware from devices.

  • Device Operation - Starting, stopping, restarting, and potentially going online/offline for devices. This might include cold/warm start events.

  • Modifying of Device Configurations - Modifying device configurations, including code edits, renames, sequence resets, and enabling/disabling unsolicited responses.

  • Device Status - Monitoring and reporting on devices’ health, configuration, and operational state. This includes status changes like module state changes.

  • HA and Redundancy - Switching or resetting redundancy.

  • Suspicious Network Activity (Operational/Security) - Events requiring attention due to potential security concerns or operational anomalies.

  • Version Change - Version change.

  • Abnormal Network Activity - Abnormal behaviour in the network.

  • Access Control - Authentication-related activities, including successful/failed login attempts and file authentication.

  • Device Error - Events indicating unexpected device behaviour, such as DNP3 errors and Telnet failures.

  • PLC Programming - Changes the logic of the PLC.

  • Communication Establishment - Typically, these events occur during system startup or when a new connection is initiated.

  • Communication Management - Management of data exchange formats (datasets and tables) within established communication protocols.

  • Diagnostics and Maintenance - Events used for various diagnostic and maintenance purposes, such as troubleshooting control logic, testing PLC functionality, simulating process conditions, and preparing a PLC for operation or taking the PLC out of service.

  • PLC Operation - Ensuring proper functionality before integrating the PLC into the control process.

Specific events which are of particular importance to this section are: New Asset/Module discovery or removal, inactive/stopped assets, event start/resolution times, and vulnerability identification/resolution times.

In this example, from the Events page select Network Threats. On this page, we can set the status to all Unresolved events. Here we can identify a series of Intrusion Detection events. Selecting the first of these events we can view the details box. The details provide information on the type of event, why this event is important, and suggested mitigation techniques.

The incident handling widget for Tenable OT within the compliance dashboard, is a crucial tool that provides an immediate overview of the assets at risk by their criticality. The dashboard allows analysts to drill down into high risk areas and investigate security events.

Event Mean Time To Respond (MTTR) is a critical key performance indicator (KPI). A shorter MTTR indicates a more efficient incident resolution process. Minimising downtime and disruptions is crucial for maintaining productivity and service availability.

Each widget is mapped to the relevant area of the NIS 2 framework, assisting organisations to easily improve specific areas of focus. The information icon presents details on which framework measures are being addressed within each widget.

The Show/Hide Asset List link provides organisations with a deeper level of asset assessment by expanding out a list of assets vulnerable under this category. Selecting the link provides details which focus on the most critical action you have to take first, in this case Critical assets associated with Network and TD events.

Detailed asset information is available in the Single Asset View.

The Events section provides information on any associated events, which can be reviewed and investigated further. Included are details on the identified vulnerabilities, and suggested mitigation strategies. These details are available when an item is selected.

For more information on using Tenable OT Security reference the Tenable OT Security Getting Started Guide.

Service Level Agreements (SLA) play an important role in the reporting process. If the organisation has an SLA established for remediation, those can be set into Tenable Vulnerability Management and Tenable Security Center to make reporting SLA progress a simple task. There is no set timetable to resolve vulnerabilities that fits every situation. SLAs can vary from organisation to organisation, and even vary between business units within the organisation. Tenable recommends aligning SLAs with technology or business objectives, starting with the most important assets.

To view or adjust the SLA reporting period within Tenable Vulnerability Management, navigate to Settings > General. From there, selecting Service-Level Agreement (SLA) will provide you with the page which allows you to define the proper SLA for your organisation.

To view or adjust the SLA reporting period within Tenable Security Center, the widget filter must be set. For this example, provided the SLA for critical vulnerability remediation is 30 days, adding and setting the Days to Mitigate filter to “Within 30 Days” sets the correct reporting timeframe for this widgets cell.

Tenable Lumin summarises key assessment maturity metrics to help improve assessment capabilities and security responsiveness. Tenable Lumin provides detailed analysis into asset scan distribution, frequency, and vulnerability age to strengthen program effectiveness and focus on process maturity. Interactive widgets allow analysts to drill into assessment maturity data to investigate the security posture of underlying assets. Tenable Lumin measures remediation responsiveness, remediation coverage, and provides the proper context for an organisation’s process risk mitigation efforts.

The metrics provided by Remediation Maturity scores allow organisations to pinpoint the specific strengths and weaknesses of their remediation efforts. They can use this information to better understand their processes and modify them accordingly - either by changing those processes and/or making further investments.

Remediation maturity metrics include:

  • Remediation Maturity Grade (A-F) for Org and Business Contexts

  • Remediation Maturity Trending (Organizations vs Industry vs Population)

  • Remediation Responsiveness Grade → Remediation Time Since -- Recovery and Remediation Time Since Vulnerability Publication

For more information on how Tenable Lumin can help see this guide. More information on Tracking and Reporting SLA progress can be found in this document.

The following cross-reference information is provided to derive a more comprehensive and effective approach to managing information security requirements. NIS 2 Article 21(2) (b) references Incident Handling and Reporting.

Security domains define how information is classified, categorised, or administered. The following Security Domains, Sub-Domains, and Measures are related to NIS 2 Article 21(2) (b), and can assist organisations already using other standards and frameworks to comply with NIS 2.

SECURITY DOMAIN: Defence.

SECURITY SUB-DOMAIN: Computer Security Incident Management.

SECURITY MEASURE: Information system security incident response.

In an effort to foster higher consistency and reliability across multiple frameworks and the NIS 2, Article 21(2) (b) can be associated with the ISO 27001, NIST CSF, and ISA/IEC 62443 utilising the following cross-references for incident handling. The following cross-references cover the processes and procedures related to information system security incident response.

CROSS REFERENCES:

The ISO 27001 references sections within Annex A, Information Security Controls Reference, specifically the following sections:

  • ISO 27001(A.16.1.1, A.16.1.4, A.16.1.5, A.16.1.6, A.16.1.7)

The NIST CSF references the following sections within Identify, and Protect.

  • NIST CSF (ID.AM -5, ID.RM-2, 3, PR.IP -7,8, PR.DS -4, ID.BE -5)

The ISA/IEC 62443 references the following sections within System Integrity and Data Confidentiality.

  • ISA/IEC 62443 (SR 3.4, SR 4.1)