Kaspersky Lab to create new OS 'to save the world' Kaspersky Lab, the Russian security firm that has garnered headlines with its research into Stuxnet, Flame, Duqu, Gauss, and other sophisticated malware, says it is working on a new operating system designed specifically to shield against attacks by cyber-weapons. The as-yet unnamed OS – internally it's known only as "11.11" …
"China and Russia were never allies and will never be"
Of course they aren't.
They just vote the same way at the UN security council by chance. It's coincidence that they are the key members of the Shanghai Cooperation Organisation (Central Asia's NATO), that the Russians supply nuclear power technology to China. And it's purely arms length commercials that dictate that Russia supplies weapons to China. And Putin didn't mean to say it when he described China as a good friend and a good partner. And the plan to double bilateral trade between the two, that's another thing that means nothing. And Russia being China's largest oil supplier, nothing in that. Or in the plan to jointly develop new civil aircraft.
I believe in meeting people so I can look in their eyes - I get a quicker sense of motivation from that than weeks of email and phone calls(*). I have met Eugene Kaspersky for a one to one about a year ago, and he strikes me as a straight player.
That is, of course, my personal opinion.
(*) it helps that I have studied micro expressions..
"I have met Eugene Kaspersky for a one to one about a year ago, and he strikes me as a straight player."
Berni Madoff struck people as a straight player. Not that I am casting aspersions on your opinion or Kaspersky, merely making the observation that as a general rule the untrustworthy don't have "BEWARE -UNTRUSTWORTHY" tattooed on their foreheads.
If you'll elect me I'll require that they do by law, although this does mean that first time offenders will get away with it. Obviously a proactive eugenics based approach will apply the tattoo at birth to children of known crims, and to anybody unlucky enough to have a "weasly face", close set eyes, or other things I could be judgemental about without much supporting evidence.
Why don't Kaspersky just buy VMS from HP?
It does most of what is required and has done for decades, in a stable, quiet, untrendy, and low-cost way (which is part of why you read about it so rarely).
HP aren't actively marketing it ie it meets Kaspersky's criterion of not being in widespread use although there are customers still using it. HP haven't much of a clue what to do with it, which isn't exactly helping retain (let alone attract) new customers.
Although it wasn't designed with portability in mind it's currently on its third architecture and porting it to AMD64 or even modern ARM is surely merely a matter of dollars and sense,
Hell it's as sensible an idea as anything else in the Kaspersky article.
"Why don't Kaspersky just buy VMS from HP?"
That would be a reasonable thing to do. But you have to ask yourself why DEC couldn't make VMS viable 20 years ago. People voted with their wallets, for Windows and against VMS; for cheapness and eye candy, against more expensive security and reliability.
Now that Windows has been running on top of a version of VMS for 15 years, why would they change their minds?
Good to see you here again Tom.
"why DEC couldn't make VMS viable 20 years ago. People voted with their wallets, for Windows and against VMS; for cheapness and eye candy, against more expensive security and reliability. Windows has been running on top of a version of VMS for 15 years, why would they change their minds?"
Back then, lots of people believed the "Windows is THE answer" kool-aid.
We're all older now, and quite a few of us are wiser, especially post-Stuxnet.
WNT is not, never has been, and by now it should be clear it never will be, VMS++ in any meaningful way.
WNT shared some design goals with VMS. It shared some concepts too (though others were borrowed from VAXELN rather than VMS, see e.g. Custer's Inside Windows NT book). It shared some people too, Cutler being the most obvious one.
Then Gates got his hands on it. The protected independent subsystems which provided robustness and security via external procedure calls and the like meant that WNT, although more productive than W98, seemed to be slower as far as the benchmarketing people were concerned.
Productivity is hard to measure but irrelevant benchmarks are easy. So the independent subsystems became monolithic, stuff that had been kept out of the kernel for reasons of robustness went into the kernel, gaining performance but sacrificing robustness.
Will that answer do for starters? There's lots more similar (e.g compare a VMS active/active multi-site cluster with whatever bodge MS and partners are offering this week - another failed MS promise).
Obviously it would help to change the name from VMS, and to actually invest in a bit of shininess for the newly named product, but the concepts and the code are still mostly as valid as ever, especially for the approaching post-PC era. VMS support's a bit broken relative to what it used to be, but that's fixable if Kaspersky act before the best VMS experts pass their retire-by dates.
Wasn't QNX designed for these niche markets and has been around for 30 years so assume is pretty secure, kind of seems like re-inventing the wheel to start from scratch. No matter how well they write the code there is bound to be some bugs in it. And besides as RIM now owns QNX they could do with some alternative markets since the Blackberry hasn't exactly sold well
"will contain absolutely zero defects or vulnerabilities in the OS kernel"
Mission impossible detected! How come Kaspersky has suddenly developed nous in OS design, development, roll-out, maintenance and most important in this case integration with 3-rd party control systems?
"The new OS will not be based on Linux or any other existing platform."
Why not? Existing platforms exist for a reason. And the fact that they exist in the first place is certainly a big plus. OpenVMS? Why not. PORT IT!
"To retain a degree of security through obscurity..."
Nooooo!
"...Kaspersky says it will be written entirely from scratch."
END OF LINE!
Ohm one additional thing...
"The number of lines of code in the kernel will also be kept to an absolute minimum to reduce the likelihood of defects."
The only good idea in this article.
"Why not VMS? If you've ever had to use it, you'll know why."
Please enlighten us, o learned one.
I learnt VMS at the same time as I learnt UNIX (which at the time was a collection of V7, System V, and BSD4.2).
Both had their place, and still do - for those with open minds as well as those who only TALK about open systems.
One size does not fit all. Windows certainly doesn't fit all. Nor does VMS, nor UNIX. But based on the more sensible crtiteria Kaspersky describe, VMS is at least as close as any slideware OS.
Seems like the Qubes approach might be a little more feasible. I.E. the "OS" is a very narrowly exposed hypervisor, controlling functions segmented into multiple VMs with said segmentation enforced by hardware virtualization controls like VT-D. Using this approach the security can be primarily focused on the hypervisor, which is much less of a Mission Impossible than an entire zero-defect OS. Secure Host OSs are, of course, a great benefit... but a single exploit should not cause the whole system to fall down.
Of course, I don't know squat about ICS... so maybe I'm off base.
Qubes (PDF) - never heard of it but an intriguing idea for sure. Somewhat similar to Bromium.
I took a look-see at IEEE Xplore. There is no entry for the "Qubes" or "Bromium" search terms in metadata, but full-text search for "Qubes" elicits VSK - "Virtual Security Kernel", another secure kernel. The author says:
"The Qubes secure hypervisor presents some similarities with VSK by moving most of the resource management out of the kernel, resulting in a thin OS running over bare metal. In Qubes, a form of security management plane is split between system VMs and the administrative domain (Dom0). However, Qubes mainly tackles isolation, while VSK addresses access control. In Qubes resources are virtualized, whereas simply abstracted as components in VSK. Qubes presents some level of reconfigurability due to dynamic VM spawning, but not the full adaptation capabilities both in and out of the kernel made possible by the VSK component-based design. Finally, Qubes does not address self-protection issues."
It also brings up "TrustBox - A Security Architecture for Preventing Data Breaches" and "SAFE-OS: a Secure and Usable Desktop Operating System" ...
So many things, so little time...
So what language are they going to use to write it in? Unless they really go off the reservation, it would be C, wouldn't it? (And if they choose another language, then it's going to be a lot slower, and possibly come with its own set of vulnerabilities. Unless they decide to go for machine code, which would make development really, really slow.)
Now C is great for what it does - getting low level - but it comes with a lot of dangers, such as buffer overflows. There'll be lots of places where buffers will be involved in kernel code. Kaspersky has to make sure that all the buffers and arrays don't overflow. All of them. Otherwise, you have a nice vulnerability that hackers can play around with - a bit like a competent burglar with a lockpick in a keyhole. And if there's one hole, there's probably two or three more.
Plus the "security by obscurity" - ok, what routines have to be obscured to make the OS secure? Encryption? What. A. Joke. All serious encryption algorithms are peer reviewed, like RSA and Diffie–Hellman. The idea is that the keys are secret, but the algorithms - which often can be expressed in a couple of lines of math - is left open, so that researchers can find vulnerabilities.
This reminds me of the Clipper Chip, the NSA's chip that was meant to be secure because one of its algorithms was obscure. Except that it got hacked in 1994 by someone outside of the agency.
Like others, I'm suspicious of what the obscure code is for. FSB backdoor? Who knows.
> So what language are they going to use to write it in? Unless they really go off the reservation, it would be C, wouldn't it? And if they choose another language, then it's going to be a lot slower.
I can't believe this "anything that is not C is [a lot] slower" is still haunting the meme sphere. It was wrong 20 years ago. It is wrong today.
The only thing that is faster when writing in C is shooting yourself in the foot.
Moreover, if you are going to write anything like Kaspersky pretends to do and you instead on a "bracy" language, you are to a minimum going to use a subset of C only.
Hey, yesterday was Ada Lovelace day. You know know what I'm thinking!
If you really want an OS, or kernel, that puts security first - ahead of everything else - you cannot start with any existing OS, because they weren't. Proper security is not something you can add on; it has to be designed in right from the very start. And it will be a major constraint on everything else thereafter.
If you really want an OS, or kernel, that puts security first - ahead of everything else - you cannot start with any existing OS, because they weren't.
There are operating systems that were designed with security as the primary goal. Some are essentially research projects (see the reference to SAFE-OS above, for example); others are niche products, such as those designed to meet Orange Book A1 requirements (eg Honeywell SCOMP). But they exist.
There are other operating systems that have fundamental security mechanisms in their design, rather than the more common virtual-memory-plus-discretionary-access-labels approach; a capability system like IBM's i (formerly System i, formerly iSeries, formerly OS/400) is one example. A capability OS could be considered one that "puts security first", in the sense that even the most basic operations (memory access, etc) require authorization, and everything is built on top of that. In practice, i doesn't achieve what people would probably imagine when they think of an "OS ... that puts security first", because application vulnerabilities still lead directly to unauthorized activity. But that just shows that "putting security first", or any other bumper-sticker slogan, isn't a sensible criterion for designing an attack-resistant OS. For that, you need an actual threat model and a remediation plan to go with it.
This post has been deleted by its author
It exists? Obligatory Kornheiser Why!
If this ever came to fruition, Ballmer would throw an IP chair at it and that would be that.
...is a fool's errand, particularly for a product as generic as this since the code eventually has to be deployed. It's utter hubris to believe that a small team, no matter how good, can create a truly defect-free kernel.
This sounds much more like KL trying to market their security reputation to the uninitiated.
I believe that the only way to get to a low defect OS is to keep it tight and put in front of as many eyes as possible.
" It's utter hubris to believe that a small team, no matter how good, can create a truly defect-free kernel".
In an otherwise sensible post, that sentence seems incongruously wrongheaded. If you want something done right, the best team size is 1. If there is really too much work for a single person, keep the team as small as you possibly can. Of course, that goes hand in hand with the admirable goal of keeping the OS/kernel as small as possible. Lines of code that do not exist rarely have any bugs.
Seems to me that the absolute best way to achieve the goal of zero defects is through publishing your code and letting world+dog look it over.
If it is a hyper secure OS that actually meets the goals outlined then there should be zero consequences for it to be out in the open. Not only that but having such a thing would give a blackeye to existing OS vendors. Further, the publishing of it would encourage others to follow the lessons learned for incorporation in a much wider range of systems.
On the other hand, if it's all bullshit, as I suspect, then hiding the code is probably best.
While I'm a great fan of Linux for general purpose desktop, embedded systems and server computing, Linux is designed to do many things well and at the same time. As a consequence Linux is a complex and large multitasking system with significant concurrency support etc. These requirements all add complexity, which makes guarantees of security more difficult to achieve. I suspect the requirements being addressed here for secure ICS support are for single tasking systems which run a single program and which does one thing well. If I were trying to guarantee security of an embedded ICS system running a dedicated application (if that were possible), I imagine I'd want a much simpler platform than Linux to run it on. Whether they can bring to bear enough engineering effort to do a better job than would be achievable running Linux with an appropriate firewall and mandatory access control design (MAC) system (e.g. using SELinux) is another matter.
The real problem is likely to be in the conflicting requirements. A really secure ICS should only be controllable on site and with no external network connections. But those who operate ICS are likely to want remote control and monitoring facilities, so the system design is likely to end up as a compromise favouring Linux with a MAC and firewall design anyway. Once you give anything a TCP/IP or some other networking stack it's immediately and automatically less secure than before it had the ability to talk with the outside world.
http://www.ranum.com/security/computer_security/papers/a1-firewall/
'Clive Sinclair promised the ZX80 could do "quite literally anything from playing chess to running a power station."'
Indeed. All it would take is for someone to write a suitable program! 8-)
Reminds me of the old story about the two characters who clean up by selling mug punters a small box prominently marked, "Infallible Inset Killer! Destroys ALL BUGS when used as directed".
Inside the box were two blocks of wood and a small sheet of directions. They read, in full, "Put the damn thing on one block and hit it with the other".
...............or vulnerabilities in the OS kernel and that will make running unauthorized, outside code "a categorical impossibility.""
One assumes then that Kaspersky Labs will not be headhunting anyone from Redmond, Cupertino or Mountain View any time soon.
"One assumes then that Kaspersky Labs will not be headhunting anyone from Redmond, Cupertino or Mountain View any time soon".
Generally speaking, you can optimize an engineering system for only one variable at a time. We have already agreed that the OS under discussion will be optimized for security. So there is no point looking for help to people who take as their prime directive to maximize the long-term integral of profits.
Erm, the world has already been saved. By OpenBSD. Now what's left is to convince the muppets in charge with the development of those industrial control systems to stay away from Windows, and the security muppets to stop allowing those systems to be accessible from Internet (directly or via Windows machines).
""and that their ICS networks are not directly connected to the public internet ("air gap")."
But they WERE directly connected to the public Internet, via sneakernet.
As long as you allow your employees to use removable media, never mind continuous network access to "outside", you are not secure in this kind of scenario.
The other, bigger, problem is that Manglement insists on viewing "what's going on" from their luxury VACA home in Barbados or Tahiti, even though they clearly don't understand the concept of security[1]. And from personal experience, said Manglement has no clue as to the details of the processes involved and probably (from a security perspective) shouldn't have access to "need to know only" info in the first place. But they do lurvs their purty graphs & PDFs, don't they? Numpties ...
Come up with a fix for non-technically inclined managerial arrogant incompetence, and you might have something.
[1] If they did, they'd have a real vacation, sans anything work related ...
Yes but what if you're letting employees go outside and see things before they come in and get their grubby hands on the keyboard? Employees should have their eyes and ears removed to truly close the gap. Or just have a business in a self-contained city. Only babies may enter; only retirees may leave.
Presumably by that they mean they will keep it closed source.
So they're admitting they've failed their goal of producing an OS kernel with zero defects or vulnerabilities already. If it was 100% bug free then releasing the code would only be a good thing. They know as well as anyone that 100% bug free code is impossible, one of the first things I was taught in software engineering years ago was that!
Speaking as a hardware ICS engineer, it's the headlong rush of a lot of control system vendors to embrace commodity technology such as ethernet that has led to a lot of these problems. I've recently been looking at a PLC spec where the vendor has boasted that with the latest firmware upgrade, the Powerlink ethernet port (realtime scheduled ethernet so there are no packet collisions, for comms with field devices), can be used simultaneously as a general purpose ethernet port! Presumably if used as such, anything can dial into a field device(all of which will have IP addresses) without going through the PLC at all (or any non existant security features running on it)!
This announcement has me a little confused.
Stuxnet did not target the PLC's directly, this is simply not possible as a PLC does not have an operating system in the conventional sense, but instead can only execute a series of logic statements. Viruses are really not a concern for PLC manufacturers. There may be a risk of a DDoS, but i'm sure the various manufacturers are working continually to eliminate all such risks of this.
What stuxnet did, was spread between laptops used to program these devices, and look for the project files. it would then modify the logic statements in such a way as to cause damage (e.g spin the centrifuges to full speed, then immediately put the motors into reverse without first slowing down.)
So exactly what part of the stack are Kaspersky trying to replace? Their press release words it as if they are trying to replace the software within the PLC's, but this doesn't need replacing, it is secure enough as it is. The only part that needs replacing is the windows laptops used for programming. Surely it would be far easier to just switch to a stripped down version of linux, or QNX for these laptops?
And how exactly do they intend for their operating system to work with existing software? To do this will require a Windows virtual machine, or at least a partial re-implementation of the Windows API.
I thought the reports said that Stuxnet just set the centrifuges to spin at a rate that was just wrong enough as to be useless for the task they were doing, but not so different from the useful speed as to raise any alarms. These things have to run for significant periods of time (remember they are trying to separate U238 from U235 - better to frustrate your enemy for months without him knowing than alert him to your plans immediately). It may be they only found out something was wrong when one of the centrifuges broke and they traced the controller directives to an infected machine. But I wasn't there, so I'm only repeating what the MSM wants me to know...
the way to break a 50 year cypher is to wait 5 years for the hardware to advance while working on your algorithmic logic. Then buy a bunch of systems, and crack the code in the next 5 years.
Time has proven him largely correct. So to some extent, it doesn't matter how well intentioned or developed the initial ICS is, it will be vulnerable within 10 years of release.
So the Gordian Knot in this problem is actually: How do you build a code base that is secure, stable, and seamlessly upgradeable? Even Torvalds et al. didn't solve that one with their kernel, and he seems to have made the best run at it to date. Seems like you can pick whichever two of the three you want, but you'll never get all of them.
It's all hype, but there may be an element of truth. If Kasperky can create a general purpose, secure VM that can host existing control systems that would be a big step up in security, especially if it can deal securely with inputs that could be coming from modern, sophisticated instruments and 'smart' meters where there is a greater risk than before of unwanted signals coming back from disgruntled types, simply because the attack surface is greater.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
