Kaspersky Lab Developing Its Own Operating System? We Confirm the Rumors, and End the Speculation!

Hi all!

Today I’d like to talk about the future. About a not-so-glamorous future of mass cyber-attacks on things like nuclear power stations, energy supply and transportation control facilities, financial and telecommunications systems, and all the other installations deemed “critically important”. Or you could think back to Die Hard 4 – where an attack on infrastructure plunged pretty much the whole country into chaos.

Alas, John McClane isn’t around to solve the problem of vulnerable industrial systems, and even if he were – his usual methods of choice wouldn’t work. So it comes down to KL to save the world, naturally! We’re developing a secure operating system for protecting key information systems (industrial control systems (ICS)) used in industry/infrastructure. Quite a few rumors about this project have appeared already on the Internet, so I guess it’s time to lift the curtain (a little) on our secret project and let you know (a bit) about what’s really going on.

But first – a little bit of background about vulnerable industrial systems, and why the world really needs this new and completely different approach of ours.

The Defenselessness of Industrial Systems

Though industrial IT systems and, say, typical office computer networks might seem similar in many ways, they are actually completely different beasts – mostly in terms of their priorities between security and usability. In your average company, one of the most important things is confidentiality of data, and IT administrators are encouraged to isolate infected systems from non-infected systems to that end, among others. Thus, for example, if on the corporate file server a Trojan is detected, the simplest thing to do is disconnect the infected system from the network and then later start to tackle the problem.

In industrial systems that can’t be done, since here the highest priority for them is maintaining constant operation come hell or high water. Uninterrupted continuity of production is of paramount importance at any industrial object in the world; security is relegated to second place.

Another challenge to securing an “always on” environment arises due to software at an industrial/infrastructural installation only being updated after a thorough check for fault-tolerance – so as to make sure not to interrupt the working processes. And because such a check requires loads of effort (yet still doesn’t provide a guarantee of non-failure) many companies often simply don’t bother to update ICS at all – leaving it unchanged for decades. Updating software might even be expressly forbidden by an industrial/infrastructural organization’s safety policy. Just recently I read a nice piece about this, which listed 11 ICS security rules; rule #1 is “Do not touch. Ever.” What more of an illustration do you need?!

Still, even if the possibility to update software and patch up “holes” does exist, this doesn’t always help much. Manufacturers of specialized software aren’t interested in constant source code analysis and patching holes. As experience has shown, corners (costs) are normally cut on this kind of activity, and patches are released only if a certain exploit has been found and put on the Internet. In fairness, this is true for common, garden variety software, not just specialized software; still, today we’re talking about specifically industrial software.

The problem consists in the following: the vulnerability of control software, programmed controllers, and industrial communication networks leads to operators of industrial/ infrastructural systems not actually having the ability to receive reliable information about the systems’ total operation!Theoretically a situation is possible where, let’s say, a system for distributing electricity is attacked, as a result of which somewhere at a distant installation the other side of the country a breakdown occurs. But the control center doesn’t know anything about it: the attackers have sent to its computers false data.

Examples

You don’t need to look far to find examples of this actually happening in real life. The first method used – an example of cyber-sabotage at its potentially most dangerous – was in a direct attack on SCADA systems as far back as the year 2000 in Australia. An employee of a third-party contractor who was working on the control systems of Maroochy Shire Council carried out 46 (!) attacks on its control system, which caused the pumps to stop working or work not as they should have. No one could understand what was happening, since the communication channels inside the system had been breached and the information traveling along them distorted. Only after months did companies and the authorities manage to work out what had happened. It turned out that the worker really wanted to get a job at the sewage firm, was rejected, and so decided to flood a huge area of Queensland with sewage!

There are plenty of other such examples; they’re just not reported in the media. After all, victim companies are generally not too keen on letting the whole world know their systems have been compromised. (Public interest issues abound, but I’ll save those for another day and another post…) And in many incidents even the victims themselves don’t know they’ve been attacked. Not long ago a hole was found in RuggedCom industrial routers that permitted any average user to simply increase his/her access rights up to administrator level and gain control over the device. By who, when, how, and where else the hole could have been exploited can only be guessed at. Plus how many similar holes exist and are possibly being exploited in secret – we can only guess at.

For a bit of personal-development I recommend reading about attacks on ICS that succeeded in fulfilling their missions – here, here and here.

So who else – apart from blackmailers, disgruntled job applicants, etc. – might get access to the source code of ICS software, controllers, operating systems and the like? Of course there are the respective government and industry authorities – namely those with a department that certifies software for critically important systems. But in recent years there have been departments created for developing cyber-weapons used for attacking opponents’ systems, whomever they may be – perhaps commercial competitors, but more likely other countries in general.

I mean things like Stuxnet and the subsequent Duqu, Flame and Gauss – malware so vastly complex that it’s clear it was developed with the support of nation states. And it doesn’t really matter who’s being targeted at present; what matters is that such cyber-weapons are being developed and deployed at all. And once Pandora’s Box is open, there’s no way of getting it closed again. The building up of armaments for attacks on the industrial systems and infrastructure of enemies sooner or later will affect us all. So it turns out that the biggest threat to the planet today comes not from the regular cyber-riff-raff, and not even from organized cyber-criminals, but from nation state-backed creators of cyber-weapons.

Protection Today: Alas, Not Effective

At the same time as arming themselves, both infrastructure companies and various government authorities aren’t forgetting about protection. Indeed, they started protecting themselves long ago. But how do they actually go about it?

There are really just two methods. The first – isolating critically important objects: disconnecting them from the Internet, or physical isolation from the outside world in some other way. However, as experience has shown, if a technician during the night shift wants to watch films from an infected USB stick on the control computer – nothing’s going to stop him (we have working methods for blocking such activity, but I won’t go into that here).

Second – keeping secrets. Collective and large-scale attempts to keep secret everything and anything. Developers of ICS keep the source code secret, owners of factories and infrastructure place a “SECRET” stamp on the schematics of information and control systems, the types of used software are kept secret, and so on. However, at the same time, information about vulnerabilities in, for example, the majority of popular SCADA systems, is freely available on the Internet. And if we dig deeper we find that for several years already the SHODAN search engine has been up and running – designed for, among other things, seeking out vulnerable industrial systems (including SCADA), whose owners decide to connect them to – or forgot to disconnect them from – the Internet.

In parallel, specialists at industrial/infrastructure organizations also apply traditional methods of protection of vulnerable software and operating systems through control over program behavior and also over actions of users. But a 100% guarantee of protection can’t be provided, again because of vulnerability-by-default in the software doing the controlling. But for critical infrastructure a guarantee is what is needed most of all.

Protection as It Should Be

Ideally, all ICS software would need to be rewritten, incorporating all the security technologies available and taking into account the new realities of cyber-attacks. Alas, such a colossal effort coupled with the huge investments that would be required in testing and fine-tuning would still not guarantee sufficiently stable operation of systems.

But there is fully realizable alternative: a secure operating system, one onto which ICS can be installed, and which could be built into the existing infrastructure – controlling “healthy” existing systems and guaranteeing the receipt of reliable data reports on the systems’ operation.

First I’ll answer the most obvious question: how will it be possible for KL to create a secure OS if no one at Microsoft, Apple, or the open source community has been able to fully secure their respective operating systems? It’s all quite simple really.

First: our system is highly tailored, developed for solving a specific narrow task, and not intended for playing Half-Life on, editing your vacation videos, or blathering on social media. Second: we’re working on methods of writing software which by design won’t be able to carry out any behind-the-scenes, undeclared activity. This is the important bit: the impossibility of executing third-party code, or of breaking into the system or running unauthorized applications on our OS; and this is both provable and testable.

More details about the system, its requirements and background to its development you can read here.

In closing, in anticipation of the multitude of questions from colleagues, partners, media and simply curious folks, a few basics: the development is a truly secure environment. It’s a sophisticated project, and almost impracticable without active interaction with ICS operators and vendors. We can’t reveal many details of the project now because of the confidentiality of such cooperation. And we don’t want to talk about some stuff so competitors won’t jump on our ideas and nick the know-how. And then there are some details that will remain for certain customers’ eyes only forever, to ward off cyber-terrorist abuses. But as soon as any possibilities do appear, we’ll tell you all we can about the project in more detail.

Till next time!