On 19 December 2024, the National Cybersecurity Agency (NCA) published a document entitled‘Ransomware. Characteristics, preparation and response to ransomware attacks‘ with the aim of defining good practice for managing and responding to a well-known and dangerous threat in the cyber domain. The paper explains the activities following an infection, both from the attacker’s point of view and from the point of view of defence activities. This article is a critical reflection on what the Agency has described.
The document also contains a process outlining the activities required for risk mitigation: analysis, containment, remediation, countering and communication to be implemented. This process was created from the NIST IR 8374 ‘Ransomware Risk Management77‘ standard and the NIST SP 800-61 Rev.278 ‘Computer Security Incident Handling Guide‘ framework.
The activity carried out by ACN is part of a very serious cybersecurity framework, in which hacker attacks using ransomware represent a major problem for Italian companies and public administrations. A cyber attack entails reputational and economic damage amounting to several thousand euros and often the impossibility of completely restoring operations prior to the attack. It is therefore obvious that a process of this kind is absolutely essential, as well as expected by Italian companies seeking an institutional support response.
Reading ACN’s document sparked a number of critical remarks regarding the actual sustainability and implementation of the process, especially in a country composed of small and medium-sized enterprises and local public administrations that often lack adequate (human and financial) resources. In some cases, for instance, in order to cope with the cyber threat, some municipalities have had to eat into the following year’s budget items to pay professionals and companies to counter threats on their behalf. It is therefore legitimate to question the value of a process that, however excellent, is then difficult to apply due to the unavailability of resources and expertise. This analysis stems from this point of observation: how sustainable is the process produced by ACN and reported below.
Ransomware threat management process
The process consists of 17 steps belonging to analysis, containment, recovery, hardening (customisation of security measures) and communication. The complete table is given below.
| Phase | Description | Type |
| 0 | A suspected ransomware attack incident is triggered by one or more of the following conditions: Detection of known ransom and/or downtime or performance impacts on an extended fleet of machines;Notification on public leak sites and/or communications received directly indicating a possible compromise of information;Notification by detection systems | Containment |
| 1 | The Incident Manager initiates incident response activities on the basis of the prepared plans, assessing the impact, even potential, of the attack in terms of services provided and in terms of consequences on assets. The business continuity plan is activated, if necessary. The IM also organises the response team, assigns responsibilities and monitors the implementation of procedures and strategies. Any implementation of new technology is suspended by the IM until the incident is closed. | Containment |
| 2 | Distribute or complete EDR coverage and establish a minimum monitoring service where it is not present. | Recovery |
| 3 | Start analysis activities in order to confirm the possible security incident by collecting the first parameters regarding the extent of the cyber event, also in time. | Analysis |
| 4 | Analysing the available information, identifying the systems, applications and accounts involved in the incident as well as the network areas particularly impacted. Also analyse the propagation and communication mechanism with the outside world (for exfiltration and control). | Analysis |
| Collect the necessary information for reporting the incident in line with current regulations, including an assessment of the impact on the services provided. | Communication | |
| 5 | If possible, initiate immediate containment activities to defuse the propagation mechanism. | Analysis |
| Initiate the external reporting process to the competent institutional bodies (Postal Police, CSIRT Italy, Data Protection Authority and other bodies according to the regulations in force) by sending updates as defined. | Communication | |
| 6 | Initiate analysis activities. Data from the analysis should be used to feed the monitoring and response mechanisms. Also initiate forensic analysis activities by preparing support to authorities for the acquisition, compliant storage and identification of traces in disk images, memory, logs and other artefacts. | Analysis |
| Initiate internal and external (stakeholders, suppliers, customers and employees) communication processes according to the communication strategies in place. | Communication | |
| 7 | In the case of human-operated ransomware: disable compromised users where possible; verify the consistency of domain controller backups and any other critical services in an isolated environment; reset all administrative credentials and those involved in the incident; reset the Kerberos ticket (twice) in order to invalidate all tokens issued using the compromised account. In the process, make sure to maintain access to the administrative user; finally, proceed with the application of MFA on the exposed systems and conduct hardening activities on remote access services (such as VPNs and remote access tools). In the case of automated ransomware: assess whether it is possible to counteract malware propagation by inhibiting the replication mechanism, e.g. by isolating the network, or by distributing patches or rules on the EDR system; reclaim any compromised accounts; verify the possibility of closing different logical network areas into separate compartments. If more specific actions cannot be performed, immediately disconnect infected devices from the network, the Internet and other devices. If it is not possible to disconnect infected devices from the network, the last option is to switch them off, but this may compromise the possibility of retrieving useful information. | Containment |
| 8 | Conduct patching of critical systems, such as firewalls and domain controllers | Containment |
| 9 | Save all further information that can be acquired on the malware and the changes made by the attacker. Ensure that antivirus definitions are up-to-date. Before removing any identified malware, be sure to record its characteristics. | Analysis |
| 10 | Identify and remove any presence of the attacker, as well as any persistence mechanisms, exfiltration channels and control channels from outside that the attackers may have created to ensure they can re-access and control the affected network and/or system. | Recovery |
| 11 | Proceed with the deployment or redeployment of the dedicated administrative clients, ensuring that the EDR is installed, patched to the latest version and navigation restricted. | Recovery |
| 12 | Restore services according to business priorities from a reliable snapshot prior to the first trace of compromise. Apply all measures defined during containment to the restored servers. Conduct tests on the correct functioning of the assets and services provided. | Recovery |
| 13 | Depending on the emergency activities adopted, consider a gradual return to the initial configurations, e.g. Internet surfing or VPN shutdown. | Recovery |
| 14 | Monitor assets for a defined period of time (e.g. at least 24 or 48 hours), applying stringent controls and allowing limited activities to verify that they are indeed free of threats. | Recovery |
| 15 | Optional: assess the need to perform some of the containment activities again, such as resetting credentials. | Recovery |
| 16 | Initiate post-incident hardening activities. They include: Improving the security posture of critical infrastructure services, e.g. virtualisation, backup, systems management, patching;Consolidating monitoring solutions and defining SOC procedures;Reviewing networking policies, e.g. firewall rules and network segmentation;Consolidating and possibly re-engineering services implemented in an emergency, ensuring documentation and scalability of implemented services;Gradually implementing the principle of Least Privilege;Replacing all obsolete and/or out-of-support systems;Reviewing management processes for recommendations from authorities. | Hardening |
| 17 | The Incident Manager declares the incident closed, prepares a report highlighting lessons learned and informs the relevant authorities. | Communication |
Elements of attention
The idea of adopting (and revising) a process based on NIST standards is not wrong but may be difficult to adhere to on structures that:
- They may not have the financial resources to equip themselves with the necessary tools.
- They may not have the human resources available to cope with the crisis in the manner expressed by the methodology.
- They may not have the technological resources required by the process due to the lack of the previous two resources or due to the sizing of the infrastructure.
The question therefore arises as to how many organisations are able to actively and effectively deploy the 17 steps suggested by the ACN and how much of this process, on the other hand, is in danger of remaining a dead letter due to the unavailability of resources. Let us try to examine some of these aspects:
“Distribute or complete EDR coverage and establish a minimum monitoring service where not present.” (Phase 2)
Already phase two places an emphasis on the fact that the affected target has an Endpont Detection and Response system at its disposal, which cannot be counted as antivirus but as a real platform for monitoring, detecting and countering the threat. Such a resource is not necessarily present in a small municipality, a local health authority or a company in the Italian business fabric. Another step that should deserve special attention is number 6.
“Initiate analysis activities. The data from the analysis should be used to feed the monitoring and response mechanisms. Also initiate forensic analysis activities by preparing support to authorities for the acquisition, compliant storage and identification of traces in disk images, memory, logs and other artefacts‘ (Step 6)
At this stage, the affected organisation should be able to develop an adequate analysis capacity and offer support to the authorities for forensic analysis activities. It is by no means taken for granted that an organisation has the knowledge, resources, and tools to perform these actions, which, more often than not, are complex and the prerogative of very specific figures. Bear in mind, for example, what is prescribed by ISO 27037 on the figures in charge of forensic intervention. The standard clearly tells us about two profiles: the DEFR and the DES:
Digital Evidence First Responder (DEFR): individual who is authorised, trained and qualified to act first at an incident scene in performing digital evidence collection and acquisition with the responsibility for handling that evidence.
Digital Evidence Specialist (DES): individual who can carry out the tasks of a DEFR and has specialized knowledge, skills and abilities to handle a wide range of technical issues.
In both cases, we are talking about specialised professionals, with special training and able to use specific tools to facilitate the isolation, acquisition and analysis of evidence and elements of interest. On the other hand, if a technical operator, however good, lacked the correct forensic knowledge, he or she could irreparably compromise the evidence and/or worsen the operational condition of the system. Again, wanting to comply with these specifications, the question arises as to what might happen if there were no economic resources available to finance an external forensic analysis activity. Without resources and guidance, what would happen to that evidence?
Conclusions and suggestions
The ACN has produced a document that is technically safe and complete but probably inapplicable by many smaller realities, and this opens up an interesting front for analysis: what can you do in an emergency if you do not have the requirements described in those 17 steps?
A first suggestion would be to create shorter checklists, aimed at handling a high-level emergency immediately. Documents designed to contain activities that are certainly feasible for those who do not have an EDR, for instance, or who do not have computer forensic expertise within their staff, or who have to pull up a line of defence and management without sufficient economic resources to ask for outside help. In short, first-line emergency checklists.
A second suggestion would be to describe ‘how‘ to perform certain operations. If a system is infected and basic information needs to be captured, it is important to do so safely and without compromising other devices/memory carriers. Reporting tips is really relevant, for instance: using the smartphone/tablet’s camera to capture ransom notes may be an answer within everyone’s reach and is not as obvious as one would think. One has to reflect on the fact that many practitioners have never come face to face with the need to manage an IT crisis.
A third suggestion is to better articulate how to carry out these activities: consequentiality is not always the best action. Working in parallel, perhaps by identifying one or more ‘action delegates’ to perform a single (elementary but important) action can radically change the impact of the incident on the infrastructure. So can keeping an up-to-date and easily accessible list of external contacts to whom support requests can be addressed.
A fourth suggestion concerns credential management (more specifically steps 7 and 15), since the process recommends replacing administrative credentialsby ‘resetting all administrative credentials and those involved in the incident‘. Nowhere in this procedure is the term dwell-time mentioned, with which the hacker could have stolen the credentials of systems but also of services (also external to the infrastructure). The change of passwords may therefore not be limited to the administrative credentials involved in the incident, but also to the main services/platforms in use that were apparently unharmed.
Ultimately, what is suggested is to simplify the method of approach, creating checklists and better specifying those ‘basic’ actions to be performed in the moment of an emergency, without taking for granted the presence of resources (human, economic, technological) that may be insufficient if not absent. It is clear that a situation that is able to meet the process described above will have little difficulty in getting back up after the impact. But what happens to those who fail to follow those 17 steps? Creating ‘first aid’ documents can really make the difference between a severe impact and a more moderate one.
