Kaspersky’s “Unhackable” OS Will Face Challenges


Last week’s coverage of a forthcoming “Ultra-Secure” OS from Kaspersky’s Labs has raised a number of serious doubts in the security community.  The top-secret project is reportedly developing this operating system to provide a secure platform designed for critical infrastructure across a number of critical industries.  The system reportedly will make it impossible to execute third-party code.  That’s just the beginning of where the doubts start.

Let me back up a little bit, one of the major questions that comes up is based on doubts about reliance on a company that with its Russian roots, has been tied to the Russian government, and ultimately to Vladmir Putin.  Its founder, Eugene Kaspersky is a former Soviet Army officer, trained by the KGB as a teenager in computer science, and is the most prominent name in computer security today.  His group “Kaspersky Labs” has repeatedly uncovered the most significant cyber-weapons being used in a global cyberwar.  Most of the uncovered weapons have been unofficially attributed to the U.S.: Flame, Stuxnet, miniFlame, and Duqu.  Let me restate that – “American” cyber-weapons are being regularly uncovered in public by a Russian-based research firm.  Does anyone see an issue there?  Kaspersky’s official goals as a company are to curb cyber-crime by exposing the tools and systems being used to execute these crimes.  Malware is a big part of this world, and just so happens to have grown beyond a criminal base into state-sponsored weaponry in an ongoing global cyberwar campaign.  The question remains in many minds about the very nature of having a highly secure operating system with such a profile at the heart of critical infrastructure.

Have you ever put off installing updates so you can work the rest of the day?  Industry does it too, but on a larger scale, and longer.  The next major concern focuses on knowledge of security practices in these core industries.  History shows us that such companies suffer from serious security practice deficiencies, with built-in aversion to warnings about flaws, or at the very best, an inability to update or upgrade consistently.   Production is first, security, if we’re lucky is second.  Let’s step into the world of industrial control systems (ICS),  Supervisory Control and Data Acquisition (SCADA) is a prevalent type of computer system that controls and monitors industrial processes.  Among a great number of ongoing security issues, SCADA vendors rarely if ever fix XSS and overflow vulnerabilities, giving birth to the term “Forever Day Bugs”.   Vendors are reluctant to patch live industrial systems.  The scope of risk is broad, and beset by any number of configuration variables, making testing difficult to say the least.  For a “greenfield” installation, it is reasonable to expect that full up-to-date security is implemented, including the latest revisions of software.   Given the choice of accepting that a system has vulnerable, yet intact software in place and the alternative – accepting downtime, risking compatibility issues, time and resources it will take to repair issues should they come up, and reintroduction time of the control systems into the environment – most industries just choose to keep going.

Stuxnet taught people in those environments a few things, for example – avoid connecting systems that serve in these roles to networks, never plug in USB drives, and lock down the operating system.  SCADA systems also suffer from other realities – the specifications for programming environments are often dictated by marketing, typically in a fixed-bid, and on tight time constraints for delivery.  Requests for security features are regularly ignored, particularly if they are not part of the contract.  The focus is typically on functionality, for example, the very insecure notion of remote access to controllers.  That’s the world they are operating in.  Very uphill and cordoned off from secure practice, it is simply not very affordable or realistic.  How this proposed new OS will be positioned to overcome these issues will be interesting to see.

The building of a purpose-built secured OS is certainly intriguing.  Simply put, most commodity operating systems have little in the way of formal security design and an unending amount of active code to really qualify as a ‘secure OS’.  Even the most locked-down system has a number of yet-to-be exploited vectors within that code.  However, similar OS projects have come up before and inevitably have been found that the products can run, well nothing.    Therein lies the issue – the operating system truthfully matters little.  At the end of the day, a secure kernel sitting there, unable to do anything has no value because the interest is in software.  It still faces the same combination of downtime and updating.  So hopes of “Saving the World” with this new secured operating system.  We will see.