The Column – Cyber Security Week
To rob a bank you can try to force the door or you can do something more elegant: open it for five minutes, close it again and wait for the inspector to arrive and find everything in order. The problem: the thieves have already passed.
Something very similar happened in the world of software. Google Threat Intelligence Group and Mandiant have reconstructed a campaign which, between April and July, affected the update infrastructure of AOMEI, a company specialized in backup, cloning and disaster recovery software, i.e. tools that should help us recover data and systems when something goes wrong. The attackers did not need to keep the servers permanently altered. They modified them for very short intervals, sufficient to distribute malicious instructions, and then returned them to their previous condition. Google documented windows of ten minutes on May 28, six minutes on July 16, and just five minutes on July 20.
The mechanism is quite simple. Its realization, evidently, much less. A computer contacts the manufacturer’s server to check for updates. If he does it at the right time he receives what was expected. If it happens in the wrong five minutes you risk receiving something very different. Shortly afterwards the server returns to normal, but the malicious software may have already achieved its objective. In this story there is a first element that should make us reflect: updates are one of the main security measures that we recommend adopting. In this case, the very mechanism through which we try to protect ourselves has become the vehicle of aggression. Let’s say that discovering a buoyancy defect in your life jacket isn’t exactly good news.
However, I personally believe that the most interesting aspect is another and concerns a rather consolidated habit of ours: thinking of security as a photograph. We check a file, a server, a configuration and, if at that precise moment everything appears correct, we tend to conclude that the system is safe. The problem is that a photograph documents a condition, not a story. Nothing tells us about what happened before the shot and, above all, about what could happen afterwards.
In the AOMEI case the attackers seem to have exploited this weakness. The brevity of the changes reduced the chances of them being detected through system health checks. It doesn’t mean that a thorough IT investigation can’t reconstruct what happened, given that it actually happened. There are event recordings, monitoring systems and analysis tools that allow us to trace even alterations that have now disappeared. Naturally on one condition: that information has been collected and stored. Otherwise, checking a server after the attacker has tidied up can be reassuring, but not particularly useful.
The point is less technical than it might seem. For years we have been investing resources to prevent someone from unauthorized modifications to our systems, but we should be equally concerned about being able to demonstrate that those modifications did not occur. The two things are not equivalent. In the first case we try to prevent an event, in the second we must be able to reconstruct it. And while prevention can fail, a lack of information about what happened risks turning an accident into a mystery. A situation which, for those who have to manage the security of an organisation, does not exactly represent the highest professional aspirations.
Then there is a second aspect that deserves attention. When a computer downloads an update from the software manufacturer, it takes a leap of faith. It assumes that that source is reliable and that what it receives will help improve the operation or security of the program. The attackers exploited this very relationship. They didn’t have to convince the user to click on a suspicious message or install a program of uncertain origin. They tried to use a channel that, by definition, should be reliable. It is a substantial difference, because it reminds us that the security of a system also depends on that of subjects over whom we have no direct control. In other words, we can be very cautious and end up in trouble because of someone we don’t know and will probably never know.
For years we have approached cybersecurity primarily in terms of space: where the malware is located, which server is compromised, which file has been modified. Events like this remind us that there is another coordinate, equally important: time. It is not enough to know that a system is healthy when we monitor it. We should be able to tell whether it was even when we weren’t looking. It means designing controls capable not only of detecting an anomalous condition, but also of preserving its traces. And it means accepting that security is not a property acquired once and for all, but rather a condition that we must be able to verify over time. Five minutes, after all, are very few, except when they are the “right” ones.
