Once an incident is reported and an attack confirmed, a forensic analysis may yield information about how the compromise took place, and a team is responsible for eliminating the exploited threat and recovering systems to a healthy state.

This article outlines the opportunity to learn that arises when experiencing a hack. Every computer has a chance of being hacked. Attacks are characterized by damage sustained by a party with stakes in the computer’s resources or the assets it operates on. Damages received, in particular, by the computer owner or the organization it belongs to. But there is typically a flipside to this damage, which could be paraphrased as “getting up and coming out stronger.”

We follow to browse over different aspects of the damage faced by victims. We further analyze the upside of learning of a threat, be it the outcome of a security audit or a forensic analysis of a previous attack.

The attack

Be it a computer system, breached via a vulnerability, social engineering, or any other means; be it an Internet account that a hacker accessed without permission, a system has been breached. The hacker may traverse many paths before he is discovered and kicked out or before he forgets this system he compromised. As part of the attack, he may steal valuable data, lateralize to other systems belonging to the same organization or household, or simply leave, causing little to no harm.

Different kinds of damages

Damage is rarely quantifiable in one or two numbers. Yet, of course, we can estimate damage by metrics including money loss or opportunity loss. There is bound to be a probability distribution over these values, where some computers will receive a very small (maybe negligible damage) while others will be higher. “On the cost of data breaches” (here) analyzes damage a company faces after a data breach measured as the loss of capitalization, or even measured as the probability of bankruptcy. Indeed, a computer attack can be extremely devastating.

Ultimately, these measures of damage can be estimated after the repercussions of the attack have occurred, including loss of business, fines, fees paid in forensic analysis and response, et cetera.

Dwell time

Dwell time can be characterized as the time the attacker remains undetected in a network. For example, one company may detect a data breach immediately, containing the damage, while the other company may take months to detect the attack.

While ransomware is reducing attacker dwell time, a good percentage of the attacks will remain undetected for months. This trend is strongly correlated with current preferred use of ransomware for attack monetization, but unrelated to progress in detection and prevention technologies. This is important for several reasons as, for example, a company may be exposed to intellectual property theft for a short period of time to data breaches before they launch a product or file a patent application, and the damage is reduced after the patent is filed or the product sees the public.

Ransomware not only helps reduce dwell time, which is a good-to-have property, but also allows victims to first know that an attack has occurred, and also, somehow know in advance the cost of this attack.

Between breach time and dwell time

Once an incident is reported and an attack confirmed, a forensic analysis may yield information about how the compromise took place, and a team is responsible for eliminating the exploited threat and recovering systems to a healthy state.

So that if the attack exploited a vulnerability in the company’s systems, then it is in the company’s best interest to isolate and eliminate the vulnerability. Also, the attacker’s path in the organization’s network should also be assessed. That is, was the breached device the only one that was compromised, or had the attack reached any lateral assets.

Lessons learned

One may thus ask, could I have done something differently to reduce this amount of damage? Certainly, if the company did not go bankrupt, while this did happen to other companies, then the outcome was not the worst possible. It is somewhere lower in the damage spectrum.

Recently there’s been cases of repeated ransomware attacks where one victim pays two or three times after being repeatedly breached by the same hacker group through the same vulnerability. Indeed, some companies will pay and learn nothing from an attack. Surveys tell us this is because companies fail to fix the vulnerabilities that led to the first attack, or attackers which persist (and aren’t kicked out) after the initial attack.

Easier said than done, detecting an ongoing attack, when it started, the entry point, vulnerabilities exploited, what type of attacker was involved, and the complete list of compromised assets are hard to get. They require a preparation in a setup of tools generating security-relevant logs, followed by a forensic analysis which takes both time and expertise. In short, we could say that in order to learn from an attack, companies must be prepared for this to happen. That is the flipside!

Moreover, reducing dwell time and efficiently learning the attacker’s actions, can also be achieved with preparation and in particular, by setting up effective detection means and lining up incentives to herd the attacker towards minimal damage and detection. This is why learning from attacks must be part of the threat modeling within security-aware companies.