On 26 July 2024, the Agency for National Cybersecurity (ACN) published the ‘Guide to Reporting Incidents to CSIRT Italy’. It is a 56-page document that gathers some interesting information that we are going to analyse.
The notification process
In the following sections, some aspects of computer incident reporting will be discussed. In particular, aspects related to notification timing, incident types and also the notification process will be addressed.
Before starting, it is worth mentioning that the document published by the ACN can be found by clicking here and includes many relevant aspects concerning the process of notifying a cyber incident . The document is overall well written but, as often happens in Italian legislation, it obliges the user to jump from one regulatory reference to another: in this case, for example, DPCM no. 81/2021 which includes the taxonomy of incidents in Annex A, or the ACN Determination of 3 January 2023.
For convenience, this taxonomy will be listed below, but it is important to understand what these taxonomies include:
- the table with the ‘ICP-A’ identifiers indicates the types of incidents impacting ICT assets or contiguous assets to be notified within 6 hours (defined in Annex A of Prime Ministerial Decree No. 81/2021);
- the table with the “ICP-B” identifiers indicates the types of incidents impacting ICT assets or contiguous assets to be notified within 1 hour (defined in Annex A of Prime Ministerial Decree No. 81/2021);
- the table with the ‘ICP-C’ identifiers indicates the types of incidents with impact on networks, information systems and information services other than ICT goods (defined in Annex A of the ACN Determination of 3 January 2023)
For greater clarity, please refer to the following table taken from the image produced by ACN on page 16 of the Guide.
| TYPE OF EVENT | ASSET IDENTIFICATION | ACCIDENT IDENTIFICATION CLASS | TYPE OF NOTIFICATION | TEMPISTICS |
|---|---|---|---|---|
| Incident falling within the classifications of the taxonomy | WELL ICT OR CONTIGUOUS | ICP-B | OBLIGATORY | WITHIN 1 HOUR of incident detection |
| Incident falling within the classifications of the taxonomy | WELL ICT OR CONTIGUOUS | ICP-A | OBLIGATORY | WITHIN 6 HOURS of incident detection |
| Incident falling within the classifications of the taxonomy | OTHER THAN BENE ICT | ICP-C | OBLIGATORY | Reporting: WITHIN 24 HOURS Notification: WITHIN 72 HOURS of incident detection |
| Incident falling within the classifications of the taxonomy | OTHER THAN ICT ASSET AND CONTIGUOUS ASSET | ICP-A/B | VOLUNTARY | NO TIMING |
| Incident that does not fall within the classifications of the taxonomy | ICT WELLS | – | VOLUNTARY | NO TIMING |
The notification process consists of four main phases, which are preparation of the notification, notification to the Italian CSIRT, management of the notification, andclosure of the incident. Some details for each phase are provided below.
| Phase | Description |
|---|---|
| Preparation of the notification | At this stage it is necessary to communicate at least: – the type of ICT asset impacted. – the type of incident in relation to the taxonomy defined by ACN (ICP-A, ICP-B, ICP-C). It is also necessary to proceed to: – Collection of evidence related to the incident. – Self-assessment of the impact on the systems and the provision of business services. – Planning of a recovery plan. Finally, the incident report must be prepared, where applicable |
| Notification to the CSIRT | The notification to the CSIRT requires information on the Type of impact according to the following criteria: – impact on ICT asset (notification art.3, paragraph 1 DPCM n. 81/2021); – impact on contiguous networks/systems (notification art.3, paragraph 3 DPCM n .81/2021) – impact on other assets (notification art.1, paragraph 3-bis of Legislative Decree no. 105/2019); – impact for which there is no reporting obligation; – date and time of detection of the accident; further details of the incident; – list of IOCs (Indicators Of Compromise); evidence found (logs, samples, etc.). |
| Notification Management | Following the report, if any, and/or notification, a direct communication channel will be opened through which CSIRT Italia will provide support for incident handling activities, and may request further information to supplement the notification. integration of the notification. |
| Closing the incident | Once the restoration activities of the impacted ICT assets have been defined and started, the PSNC subject shall promptly notify the CSIRT Italia, which, at this point, will be entitled to request from the subject a technical report of the incident concerning significant aspects. |
Taxonomy of DPCM No. 81/2021 accidents
The taxonomy of incidents includes a mapping of the main types of ‘computer incident’ with their identifier, category and description. The taxonomy consists of two tables: incidents with identifier ICP-A are part of TABLE 1, incidents with identifier ICP-B are part of TABLE 2.
TABLE 1
| Identifier (Impact Incident-ICP) | Category | Description |
|---|---|---|
| ICP-A-1 | Infection (Initial exploitation) | The subject has evidence of the actual unauthorised execution of code or malware conveyed through infection vectors or by exploiting vulnerabilities of exposed network resources. |
| ICP-A-2 | Violation of the expected level of service | Defined by the entity included in the perimeter in accordance with the security measures in Annex B, in terms of computing resources, memory and/or bandwidth. |
| ICP-A-3 | Defined by the entity included in the perimeter pursuant to the security measures in Annex B, hot-replica and/or cold-replica and/or disaster recovery site(s), if any. | |
| ICP-A-4 | Defined by the entity included in the perimeter in accordance with the security measures in Annex B, in terms of unavailability, irreversible loss or irreversible corruption of data from the field components (actuators and sensors). | |
| ICP-A-5 | Hot-replica and/or cold-replica data and/or disaster recovery site(s) and/or backup, if any, lost or irreversibly corrupted. | |
| ICP-A-6 | Loss of confidentiality or integrity. | |
| ICP-A-7 | Irreversible data loss and/or corruption. | |
| ICP-A-8 | Loss and/or compromise of encryption keys and/or certificates. | |
| ICP-A-9 | Loss and/or compromise of user credentials. | |
| ICP-A-10 | Violation of the expected level of service, defined by the entity included in the perimeter in accordance with the provisions of the security measures in Annex B, in terms of impossibility of physical access to the components. | |
| ICP-A-11 | Establish persistence | Obtaining higher-level privileges (Privilege Escalation). The subject has evidence of the unauthorised use of techniques, conducted from within the network, to obtain higher-level privileges. |
| ICP-A-12 | Persistence. The subject has evidence of the unauthorised use of techniques, conducted from within the network, to obtain persistence of malicious code or access. | |
| ICP-A-13 | Defence Evasion. The subject has evidence of the unauthorised use of techniques through which security systems were effectively evaded. | |
| ICP-A-14 | Command and Control. The subject has evidence of unauthorised communication outside the network. | |
| ICP-A-15 | Lateral Movement | Exploration (Discovery). The subject has evidence of the unauthorised use of techniques, conducted from within the network, to carry out reconnaissance activities. |
| ICP-A-16 | Credential Access. The person has evidence of unauthorised use of techniques to acquire, from within the network, valid credentials for authentication to network resources or finds unauthorised copies of them. | |
| ICP-A-17 | The subject has evidence of the unauthorised use of techniques to access or execute code between internal network resources. | |
| ICP-A-18 | Actions on Objectives | Collection. The person has evidence of the unauthorised use of techniques to collect, from within the network, data of interest to third parties or finds unauthorised copies of such data. |
| ICP-A-19 | Exfiltration. The subject has evidence of the unauthorised use of techniques to exfiltrate data from within the network to external resources. |
TABLE 2
| Identifier | Category | Description |
|---|---|---|
| ICP-B-1 | Inhibit Response Function | The person has evidence of the unauthorised use of techniques to inhibit the intervention of safety, security and quality assurance functions of industrial control systems designed to respond to a malfunction or abnormal state. |
| ICP-B-2 | Impairment of Control Processes (Impair Process Control). The subject has evidence of the unauthorised use of techniques to manipulate, disable or damage the physical control processes of industrial control systems. | |
| ICP-B-3 | Intentional Disruption (Impact). The subject has evidence of the unauthorised use of techniques to manipulate, degrade, disrupt or destroy systems, services or data. This includes, for example, Denial of Service/Distributed Denial of Service events impacting ICT assets. | |
| ICP-B-4 | Failure | Violation of the expected level of service, defined by the entity included in the perimeter pursuant to the provisions of the security measures in Annex B, especially in terms of availability, of the ICT asset. |
| ICP-B-5 | Disclosure of corrupt data or execution of corrupt transactions via the ICT asset. | |
| ICP-B-6 | Unauthorised disclosure of digital data relating to ICT assets. |
Taxonomy of ACN Determination 03/01/2023
| Identifier | Category | Description |
|---|---|---|
| ICP-C-1 | Initial exploitation | Initial access. The subject has evidence of actual unauthorised access within the network through infection vectors, exploitation of vulnerabilities of publicly exposed resources or any other known technique. |
| ICP-C-2 | Execution | Execution. The person has evidence of the actual unauthorised execution of code or malware within the company network. |
| ICP-C-3 | Establish persistence | Obtaining higher-level privileges (Privilege Escalation). The person has evidence of the unauthorised use of techniques, conducted from within the network, to obtain higher-level privileges on a system or network. |
| ICP-C-4 | Persistence | Persistence. The person has evidence of the unauthorised use of techniques, conducted on a system or within the network, to obtain persistence of malicious code or to grant access. |
| ICP-C-5 | Defence Evasion | Defence Evasion. The subject has evidence of the unauthorised use of techniques, circumvention of security policies and/or systems, designed to avoid detection during an attempted compromise. |
| ICP-C-6 | Command and Control | Command and Control. The subject has evidence of unauthorised communication outside the network. |
| ICP-C-7 | Lateral Movement | Exploration (Discovery). The subject has evidence of the unauthorised use of techniques, conducted from within the network, to carry out reconnaissance activities to gain knowledge about the system and the internal network. |
| ICP-C-8 | Credential Access | Credential Access. The person has evidence of unauthorised use of techniques to acquire, from within the network, valid credentials for authentication to network resources or finds unauthorised copies of them. |
| ICP-C-9 | Lateral Movement | Lateral Movement. The subject has evidence of unauthorised use of techniques to access, control or execute code among internal network resources. |
| ICP-C-10 | Actions on objectives | Collection. The person has evidence of the unauthorised use of techniques to search and/or collect, from within the network, confidential and/or sensitive data or detect their presence outside the systems authorised to process them. |
| ICP-C-11 | Exfiltration | Exfiltration. The subject has evidence of the unauthorised use of techniques to exfiltrate data from within the network to external resources. |
| ICP-C-12 | Inhibit Response Function | Inhibit Response Function. The subject has evidence of the unauthorised use of techniques to inhibit the intervention of safety, security and quality assurance functions of industrial control systems designed to respond to a failure or abnormal state. |
| ICP-C-13 | Impair Process Control | Impairment of Control Processes (Impair Process Control). The subject has evidence of the unauthorised use of techniques to manipulate, disable or damage the physical control processes of industrial control systems. |
| ICP-C-14 | Intentional Disruption (Impact) | Intentional Disruption (Impact). The subject has evidence of the unauthorised use of techniques to manipulate, degrade, disrupt or destroy systems, services or data. This includes, for example, Denial of Service/Distributed Denial of Service events impacting ICT assets. |
| ICP-C-15 | Reconnaissance related to spearphishing activities | Reconnaissance consists of techniques that adversaries adopt to gather, actively or passively, information that can potentially be exploited for subsequent activities. This specific category includes campaigns, even if they have no impact on corporate assets, detected via e-mail (PEO and/or PEC) and consisting of messages, highly personalised (spearphishing), addressed to multiple users of the same organisation and aimed at capturing information, for instance through the use of malicious attachments or web links. |
Compulsory and non-compulsory
Notification of an incident can be of two categories: essentially, notification is mandatory when it falls within the above taxonomies of incidents, and non-mandatory when it does not:
- the ICT asset affected by the accident does not fall within one of the typologies of the taxonomy set out in Annex A to Prime Ministerial Decree No. 81/2021.
- when it relates to networks, information systems and computer services pertaining to its own assets other than ICT assets and contiguous assets and falling under one of the typologies of the taxonomy in Annex A to Prime Ministerial Decree No. 81/2021.
The notification can be made online at: https://www.csirt.gov.it/segnalazione
Some conclusions
The document is certainly useful but suffers, in my opinion, from some chronic problems.
It is not an autonomous document
The first aspect is the dependence on other standards, circulars, documents, which forces the user not to be able to really use the document as a tool. On the contrary, the reader must prepare himself for a ‘jumping’ reading between one standard and another, hoping that in the meantime the information has been kept up-to-date on all sources. For this reason, the ACN guide cannot be regarded as a‘stand-alone‘ document but owes its validity to two other documents such as:
- The ACN Determination 03/01/2023
- Annex A of Prime Ministerial Decree No. 81/2021
With regard to the completeness of the taxonomies, it must be said that both sources (the Determination and Annex A of the DPCM) are very complete and include various relevant aspects, including lateral movements typical of dwell-time.
Increasingly complicated timelines
Notification is becoming a complex process, involving multiple authorities and multiple time intervals, especially if the subject is subject to several regulations/directives.
| Regulation | Notification Times | Subject of Notification |
|---|---|---|
| GDPR (General Data Protection Regulation) | Notification within 72 hours of becoming aware of the data breach. | Competent supervisory authority (e.g. Garante per la protezione dei dati personali in Italy). |
| NIS2 (Network and Information Security Directive) | Initial notification within 24 hours, followed by a detailed report within 72 hours. | National Computer Security Incident Response Team (CSIRT) or the designated competent authority. |
| DORA (Digital Operational Resilience Regulation) | Immediate notification (usually within a few hours, although the specific deadline is not explicitly defined). | National or European competent authorities (such as the European Banking Authority or other financial supervisory authorities). |
It would have been useful to have had a single process that, depending on the type of data involved (for example), would have proceeded to an automatic report to the Data Protection Authority. This would have facilitated the reporting of the incident and made the process more efficient.
Restoration would require more
During the notification process, in the‘notification preparation‘ phase to be exact, ACN lists‘planning a recovery plan‘ as one of the activities to be performed. Following a computer incident, while the structure is busy figuring out ‘what to do’, ‘how to do it’, ‘to whom to notify’, in one of the greatest moments of excitement and crisis, ACN asks to‘plan a recovery plan‘.
It would have been better to transform that“plan a recoveryplan” into“implement a recovery plan” because with the verb implement the ACN would have given more importance to the recovery phase. Indeed, it must be considered that the actors subject to AgID’s Circular 2/2017 (the minimum ICT security measures for P.A.) provide for the establishment of recovery strategies.
| ABSC_ID | |
|---|---|
| 10.2.1 | Periodically check the usability of copies by means of test restoration |
Rule 10.2.1 speaks of implementing a periodic activity that verifies the usability of copies by means of a test restore. In essence, during the incident response activity one should not plan a recovery plan but implement a recovery plan, designed and kept up-to-date prior to the moment of crisis.
To‘plan a plan‘ is to waste time by worsening the potential damage caused by the incident. It also means legitimising people not to do risk analysis, since the purpose of a risk analysis is not only to know the threats but to prepare an adequate response. It does away with the concept of business continuity plan, disaster recovery plan, and all those planning activities that should be carried out ex-ante before the incident.
Finally, this ‘planning a plan’ comes into perfect conflict with the GDPR and NIS2 paradigm that attempt to anticipate the incident through threat identification and response planning.
Final considerations
The standardisation of directives and regulations generates a redundancy of time and procedures to the detriment of the final actors already fully engaged in the management of the incident from a technical, organisational and communication point of view.
The notification activity, which should be reasonably streamlined and practical given the crisis situation, risks becoming a complex, tortuous and mediating process between several actors, each with its own sub-procedures and timeframes.
Italy scrambles to create steering cabins, single tables, central agencies, ‘once only’ principles, but then distributes information on more regulations, concerning more subjects, with more timeframes and different responsibilities.
The question arises as to whether those who design all these structures have any real understanding of what it might mean to handle a data breach.
