Funded through the back door by Technology China Ltd and the Federal Russian Security Service.
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" …
Funded through the back door by Technology China Ltd and the Federal Russian Security Service.
Wow a real old fashioned cold war thing.
At least you could educate yourself to learn that China and Russia were never allies and will never be.
"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.
Even in cold war, they had a fierce competition about which communism (!) is the best.
Of course,being brainwashed for decades...
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..
"They just vote the same way at the UN security council by chance".
Only because they both do the right thing by voting against the Americans.
"At least you could educate yourself to learn that China and Russia were never allies and will never be."
Doesn't really matter, though, does it?
"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.
My BSc in determining motivation through micro expressions has never let me down either. I met Kaspersky maybe six months ago, and I was initially wary, but it turned out he had an eyelash trapped under his lower lid.
I love science.
Re "China and Russia were never allies and will never be."
Facts are so inconvenient when predicting the future. Or the past.
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.
With all respect I believe that it is possible to produce a bug free and break proof tank full of code. It requires critical logic at all stages, and hypercritical logic when modifying something already written.
As Kaspersky realises KISS .
"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..."
"...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?
Because it's VMS, that's why. If you've ever had to use it, you'll know why.
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.
"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.
Host Guest OSs are, of course, a great benefit... but a single exploit should not cause the whole system to fall down.
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."
So many things, so little time...
Yeah wonder what he hates about VMS. Is it the fact its virtually uncrashable or the fact that it is as secure an operating system that currently exists. Newer is not always better.
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.
"So what language are they going to use to write it in?"
That is a relatively unimportant implementation detail.
Oh, lovely, they'll write it in (Monty) Python. Oh, what a lovely (interpreted) language. Brings back fond memories of the incredible speed of BASIC. Deep Joy ! Will they write a casette tape storage module for it as well?
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.
They should just use ReactOS, right?
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.
they'll forget to implement any form of USB connection in the kernel or they'll be straight back to fishing bits of iranian centrifuge out of the server box.
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.
"The new OS will not be based on Linux or any other existing platform. To retain a degree of security through obscurity, Kaspersky says it will be written entirely from scratch."
Those who do not understand Unix are condemned to reinvent it, poorly.
-- Henry Spencer
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.
"I suspect the requirements being addressed here for secure ICS support are for single tasking systems which run a single program "
You might want to refresh your understanding of what goes on in a modern ICS.
Clive Sinclair promised the ZX80 could do "quite literally anything from playing chess to running a power station."
'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, my favourite - the bloke on e-bay selling 'air-guitars - an empty box with a warming sticker "Close windows before opening"
As my hometown, Oulu, hosts the "International Air Guitar Championships", that kinda tickled me a bit....
Agree code should be completely in the open for all to see and poke about with, but I'd go further.
The OS itself should be in ROM.
The program should be in flash memory with a physical switch stopping it from being overwritten in 'run' mode.
The OS should disallow any code execution in RAM.
There are already operating systems which claim to be secure, e.g. commercial like Green Hills Integrity and academic like OS' s based on the L4 micro kernel.
What's the unique selling point of the KL secure OS? Developed in Russia?
Often industrial control requires an RTOS, which rules out UNIX, Linux, etc. Apparently the existing RTOS options lack the required sophistication in security. If true, this project seems like a good idea.
...............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. 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.
 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.
You must be a kid. Or manglement. You clearly don't grok security at this level.
fscked by SHA-1 collision? Not so fast, says Linus Torvalds