“We are keeping our computers offline. That way, they are safe.” I don’t know whether the IT professionals at French carmakers, British NHS hospitals, or German train operators believed this. What I do know is: “WannaCry” has probably infected many tens of thousands of computers in more than 100 countries.
One common tactic of cybercriminals is to send emails with viruses hidden in a deceptively trustworthy attachment. Careless users might download and open the attached file. If their virus scanners are not kept up to date or if they have the bad luck to be one of the first victims of an attack (before the virus scanners have learned about the attack), the virus will infect their systems.
But “WannaCry” did not affect personal computers. It affected ticket machines and digital timetables. It is quite reasonable to assume that nobody used a ticket machine to read their emails while waiting for their train to arrive. Let us consider other attack scenarios. Viruses on websites work not unlike their email counterparts. Again, the entire disaster begins with a single action on the part of the user: They visit an affected website. An error in the browser, specifically a flaw in a browser plugin. The malware is executed and the computer infected. One high-profile example is the infamous “BKA-Trojaner” in Germany. While the email attack would seem to be 100% the fault of the unwitting, this scenario exploits a weakness in the software itself.
Another, even more insidious scenario needs no actions on the part of the user at all. Almost every modern computer has certain services and processes that accept and process data. These processes and services sit in the background and wait to be called. If an attacker finds a way to call such a process and get it to accept manipulated data that gives him access to other parts of the system, he can take over the entire machine. This attack can happen at any time when the computer is connected to a public network or when the attacker is already in the internal network.
Complex software like operating systems mean that such weak spots will always be around. There are experts tasked with finding them. Some of them might be motivated by the wish to improve the systems they are working with: They tell the software developers about the possible exploits and give them the time they need to patch the problem with an update. After that time, they publish their findings and warn the public about the problem. And then there are their criminal brethren: They might sell their findings to the highest bidder. An exploit known only to an exclusive group of people can be used and abused by them without fear of repercussions until it becomes known to the actual software developer. This is big business. Still, it is easy for users to protect themselves against known exploits, simply by installing all security updates as soon as they are published. This goes for every operating system and is definitely not limited to Windows.
“We are keeping our computers offline. That way, they are safe.” This might be true if, that is, the computer is indeed completely and absolutely offline, never goes online, and never comes into contact with other devices that are or have ever been online. The second condition already shows us that this is virtually impossible in current practice. Even the most highly classified environment, like a nuclear reprocessing plant, will have visits from service technicians who install updates to the systems. And where do the updates come from? They might come directly from the technicians’ laptops or from a CD that was produced on a different computer. Even if you took the time to print out the update code and type it manually into the target machine, a virus might well be hidden in that code itself.
The greatest and most fatal drawback of the “keeping offline” strategy is that it bars the gates to immediate security updates. In essence, once the attacker has a foot in the door, everything is there for the taking, and there is nobody to stop him.
“Going online” in a closely controlled fashion might be an appealing alternative. The computer that needs to be protected is connected to a closed network, which is fenced off with a firewall. The firewall only allows outgoing connections that the computers on the inside need to establish themselves. These connections can then be used to download and install updates.
But can you trust the official update servers? What if they are infected as well? In these cases, a “proxy strategy” might help, with the updates only released to the network after an internal inspection. The update is installed and tested on a fenced-off trial computer. After clearance and an appropriate wait, the update is then put on the internal “proxy server”, from where the computers on the network can get it. The greater the testing resources you are prepared to invest, the less time you need to wait before releasing the update. After two to five days, other users in the wild will have encountered problems with the update if there are any. Waiting for longer than five days seems like gross negligence.
But even this strategy of controlled sourcing and releasing is no panacea. The necessary checks cost valuable resources and time – time during which the systems in the network are not protected by the updated software. And the outgoing connection might be enough for criminals to steal data if they managed to get even a single infected computer into the network. That is why even outgoing communication needs to be as limited and closely controlled as possible. It should only allow named computers and only the essentially required ports. The old rule holds true: As little as possible, as much as necessary.
In today’s age of Industrie 4.0 and the Internet of Things, true offline computers are a relic of a bygone age. Last week’s attack shows that the strategy indeed exacerbates the risks because of the many older un-patched and un-updated systems that are caught in the fray. A “proxy strategy” with the manual checking and releasing of updates is an effective, but costly solution. A securely controlled outbound connection for security updates is a cheaper alternative. It also requires a certain amount of effort, because its rules need constant supervision and some critical thinking. However, it could also be used for installing updates to the licenses on the connected computers, both device-bound CmActLicenses and licenses on secure CmDongles.
