THE ESSENTIALS | If you only have 3 minutes:
Mid-sized companies (ETI) are among the main targets of ransomware attacks, according to a 2023 report by ANSSI, the French cybersecurity agency. To face this threat, the response must be organised in 3 areas:
– First, from a technology standpoint, protecting backups is an absolute priority: without them, no rebuild can take place and the organisation will be in serious danger. Yet attackers can make them inaccessible, although solutions exist. A tactical option and a medium-term action plan must be built.
– Second, from a process standpoint, the essential step is to list the 3 to 5 applications vital to the organisation’s survival: those without which customers cannot be served, invoices cannot be issued, industrial production cannot continue, legal obligations cannot be met, and so on.
– Third, from a skills standpoint, running regular exercises of increasing complexity and realism is key to rehearsing and thereby saving precious time during a real crisis. Start with the technical aspect, i.e. restoring one application, then repeat by bringing several applications into the exercise scope. Next, add functional tests on top of the technical ones. Finally, complete the internal set-up by starting initial discussions with IT service providers who can be called upon urgently in a crisis.
34%. That is the share of very small, small and mid-sized companies among ransomware victims according to ANSSI [1]. This type of organisation is a prime target for ransom extortion by attackers, because they are often less mature in cybersecurity, less prepared to react and less technically protected. Approaching cyber-resilience realistically for a mid-sized company means preparing to withstand an almost total unavailability of its information system for several weeks.
Ransomware: malicious software deployed by an attacker on servers or workstations, aiming to block them (files are cryptographically encrypted and made inaccessible) and to demand a ransom to unblock them.
Let’s dive into the heart of the crisis. The direct, visible impacts of a ransomware attack and the organisational responses they will require are as follows:
– Most workstations and/or servers are blocked and unavailable, with potentially permanent loss of locally hosted files and business data, depending on whether backups were in place and whether the attackers spared them.
– Most business processes are severely disrupted or even at a standstill (invoicing, payment, sales, contracting, order taking, logistics, delivery, service provision, etc.) and employees are unable to work for a few weeks because IT is unavailable.
– A crisis mode to trigger: to manage and monitor the operational and financial risk, the image impact with customers, the legal risks at stake, etc.
– The first days will be unpleasant: crisis management will still be being set up with many imperfections and frustrations (difficulty making decisions, actions not carried out on time, late discovery of major blocking points, etc.). The overall picture of the situation will still be very incomplete, notably from a cyber point of view, where the understanding of the attack will still need to be refined.
Complex trade-offs will have to be made: accepting to spend time strengthening and protecting the IS before restarting it versus restarting activities more quickly as they were. As is often the case, the right decision is probably a nuanced one: take measured, informed risks but keep moving, for the organisation’s survival.
This situation has a non-negligible probability of occurring. The logical approach is therefore to minimise that probability by strengthening protection overall (a multi-year programme if the cyber topic has never been addressed; see our post on the subject), but also, tactically, by preparing for a fast and effective reaction (e.g., drafting reflex sheets) to minimise the duration of the outage. As this is a transformation to carry out, it must be run in project mode (budget, schedule, deliverables, project team, contributing teams, governance and committees, etc.).
Strengthening backup protection: the absolute priority
Because data will be at the heart of concerns during a ransomware attack, protecting it through genuine strategic thinking is paramount. Regular backups are already made? Depending on how they are technically implemented, they could also be missing or made unavailable, just like the rest of the IS.
A good backup strategy must:
– be aligned with the criticality and the RTO / RPO [2] of the applications;
– set the typical retention period, depending on the applications;
– include regular restore tests, to validate the reliability of the backups;
– if it involves outsourcing to a third party, include strong security, territoriality and confidentiality clauses in the contract.
From a technical point of view, a backup infrastructure that can realistically withstand a ransomware deployment must:
– be isolated, physically (e.g. hypervisor and storage) and logically, from the rest of the IS (e.g. dependency on Active Directory (AD), connection via a shared network);
– be protected against data deletion (backups must not be deletable; they must be immutable).
Very often, a backup infrastructure built a few years ago, without taking the current cyber threat into account, probably meets neither of these 2 criteria. Moreover, IS standardisation and architecture standards have also created a dependency between the backup infrastructure and the AD (i.e. the infrastructure is a domain member). Yet the AD is almost always the propagation vector used by attackers, which puts the backups at risk. All this exposes the organisation: it could discover, at the worst moment, that the solution it put in place to cover the risk of unavailability (the backup solution) is itself unavailable.
Tape backups, which have gradually disappeared in recent years, had the advantage of being, by nature, disconnected from the IS, and therefore unreachable by a cyberattack, so they covered the risk natively. But with the modernisation of these backup solutions and the very sharp increase in the volume of data to back up, they have tended to lose this advantage, limiting themselves to covering only unavailability in the IT sense (a scenario such as losing a datacenter to a fire, covered by real-time replication to the second datacenter).
Finally, to cover this new risk, three technical responses can be provided, depending on the application:
– The case of “simple” applications, where data can be re-imported after a quick reinstallation, even from scratch. Example measure: add a regular data extraction and back it up on a platform and through a mechanism different from the classic backup.
– The case of applications with frequent (re)deployment, where, thanks to the modern CI/CD paradigm, these in-house applications relying heavily on automation are already (re)deployed several times a month. Example measure: back up the repository hosting the code and deployment scripts, as well as the databases.
– The case of “complex” applications, where data is not simple to export / import except through specialised tools from the vendor or third parties, or where several interacting servers are involved. Example measure: frequently export the classic VM backup to a third-party platform that is decoupled in every respect.
Where possible and relevant, extracting some critical data, even as a file that can be handled with an office suite, can prove very useful. For example, providing the customer service team with a file of customer data will allow a more complete and contextualised level of response to customers who are probably worried or without visibility, projecting a reassuring and calm image despite the disruption of services caused by the cyberattack.
Knowing the 3 to 5 applications to restart quickly
Depending on its context (industry, type of organisation, types of applications hosted locally versus those in SaaS), each mid-sized company must determine in advance, with its management, which few applications must be restored quickly. At the start of the crisis, this will have the advantage of:
– directing and aligning the efforts of all teams during the rebuild phase, thus eliminating the long moments of dithering often seen in the first days of a crisis;
– providing a framework, clear priorities and objectives that can be closely tracked, with the certainty of heading in the right direction, since this will have been thought through beforehand, away from any pressure or urgency.
Our experience shows that, often, even outside any crisis situation, the project team is met with the supposed impossibility of carrying out this prioritisation exercise. It would be too complex, too tedious, too theoretical, too dependent on the impacts of the crisis: “It all depends on the crisis, we can’t know in advance what will be hit, and plan for every case.”
Yet this will be a mandatory step in resolving the crisis, so it is worth being prepared in advance. It will give a better understanding and control of the organisation’s application ecosystem, a better view of application criticality, and ultimately better alignment between IT and the business. The illustration above shows that drawing up an exhaustive list is the best approach, since it will be useful and relevant whatever the impacts of the crisis.
An application that often comes to mind as critical is the one used to pay salaries. Indeed, the regularity of salary payments is governed by law, and a significant delay could unsettle people and add a crisis to the crisis. Yet this application is probably not that important if we follow a pragmatic approach. It is enough to tell the organisation’s employees that they will receive the same salary as the previous month, and that an adjustment will follow the next month, and the handling of this application is greatly simplified.
And this is the way of thinking to follow for every application. Another example: is it possible to issue invoices “manually”, with a simple extract of orders in a file? It will be much less efficient than usual, obviously. But efficiency is a concern for calm times. In a crisis, managing to send invoices is already a victory!
Questions to ask when building this list:
– Among the locally hosted applications (as opposed to those in SaaS, which will probably be spared by this type of attack, or those redeployable thanks to CI/CD), which are really critical? Which would really put the organisation’s survival at stake? What are the vital business processes: customer acquisition, customer invoicing, supplier orders, etc.?
– How could we achieve 80% of the result with only 20% of IT available? Example: is optimised (just-in-time) management of stock / suppliers critical to the organisation’s survival? Couldn’t we resend the same supplier order as the previous month, with a small safety margin?
– Which applications support a business process but do not allow “No IT” operation (see definition below), and for which restoration will therefore be decisive?
– Is the company listed, and does it have regulatory obligations to publish its results within set deadlines? If so, the financial application may, at certain times of the year, be one of the highest priorities.
Once this list is established, several actions must be carried out. First, think about a “No IT” process (a process that can run temporarily, even in a degraded way, with a simple extract of the application’s data) for the applications that allow it. And for these, are there prerequisites (drafting a simplified operating procedure, awareness-raising, etc.) for this way of working?
Running a full-scale test to get into real conditions
Gradually, a picture of what the crisis might look like takes shape, and the idea of preparing to clear up some grey areas emerges. This preparation must be done step by step. First, so as not to discourage the teams faced with the scale of the exercise. Second, so as not to generate negativity at the large number of corrective actions that will be identified in the exercise debrief.
For example, an approach with the following 3 maturity levels, to be rolled out over, say, 18 months:
– Level 1: run a single technical test of restoring and restarting one of the applications on the critical applications list. Expected benefit: identify the complexity of the operation and the technical problems encountered for each critical application.
– Level 2: run a functional test, with a few business users of these critical applications, to check that the critical operations can be carried out with the defined “No IS” measures. Expected benefit: raise awareness and train business populations, and fine-tune the process for each critical application.
– Level 3: carry out a full technical-functional test of the 5 most critical applications, possibly as part of a broader cyber crisis exercise (covering communication management, legal aspects, technical steering, investigation and cyber remediation, etc.). Expected benefit: identify the interdependencies between applications and rehearse processes already tested once.
Finally, this phase is also when discussions should begin with IT service providers (usual or new) to learn how resources can be mobilised in a cyber crisis. Indeed, for a few weeks, engineers and technicians (expected expertise: systems, network, storage, backup, cyber, etc.) will be needed to carry out the actions, and their number will directly influence the time it takes to get systems running again.
Ultimately, all the work carried out by the project team on these 3 areas feeds a first serious version of a cyber-resilience strategy. For this document of major importance to the company to be relevant and to translate into actions and transformations within the organisation, it must be formalised under the sponsorship of Executive Management. IT teams in the broad sense, notably backup, systems and application teams, must contribute, as must the business teams so that the right priorities are set, and the cyber teams, in their role of shedding light on the threat, the risks and the suitability of countermeasures.
Depending on the size of the organisation, these workstreams could take between 12 and 18 months. Progress and implementation of all the workstreams identified in this strategy must be tracked and reviewed over time by Executive Management, since good preparation and an appropriate reaction by the whole organisation could be decisive for its survival.
[1] https://www.cert.ssi.gouv.fr/uploads/CERTFR-2024-CTI-001.pdf
[2] RTO (Recovery Time Objective) & RPO (Recovery Point Objective)