products
And now, boys and girls, woo-hoo! Today is a day when woo-hoo’ing seems the most appropriate thing to do. Like this: WOO-HOO!!!
Why, you say?
We’ve officially launched our very own secure operating system for network devices, industrial control systems, and the IoT. The OS was originally conceived on November 11; that’s why we refer to it by the code name 11-11. It was a very long development cycle, for sure: we worked on the project for 14 solid years and have even run a real-world pilot test roll-out. Now the OS is ready for consumption is available for deployment by all interested parties in a variety of scenarios.
I’ll spare you all the nerdy detail, but if you do want the techy info — here it is. I’d rather focus on the things we left out of that post, so I’ll answer some frequently asked questions and debunk some myths about our new OS.
Why would we need another Linux?
This is one of the most frequently asked questions. The answer is amazingly simple and straightforward: This is not Linux. It’s literally not Linux; there’s not a single string of Linux code in it. We designed the OS from scratch, for different applications and purposes.
What matters most for Linux, Windows, macOS and the like is compatibility and universality. The developers do their utmost to popularize their solutions by oversimplifying app development and toolsets. But when it comes to our target audiences (hardware developers, SCADA systems, IoT, etc.), this approach is a no-go: What matters most here is security.
In order to create a secure environment, we need to enable global Default Deny at the process level and wrap it into a microkernel. In simple words, it’s a system that does what it’s instructed to and is unable to do anything else. With traditional operating systems, that’s impossible.
However, it’s possible to build security mechanisms into an already functional system. In essence, that’s our core business. What we do is enough for many applications. However, with some applications, even the smallest risk of a cyberattack is a disaster. When security has to be guaranteed, we have to build something new. Something that is secure by design.
Oh come on, a secure OS is not news! So what?
Well, we don’t claim to have created something completely new. Of course there have been other attempts to create a secure OS. At times some projects even succeeded, but the cost of their implementation is on a par with that of an airplane (curiously, such systems were indeed used on airplanes), so such projects were never destined to produce widely applied kit.
Other projects were mostly limited to the realm of academic research. In other words, some bright minds would build a microkernel and celebrate with champagne and speeches, and that would basically be it. No project has ever reached the stage of full-scale deployment or commercialization. But a functional vehicle does not end with an engine; it can’t function without wheels, suspension and myriad other important stuff.
We decided to design the system so as to be relevant in different spheres, allowing customization on a granular level, based on application. Basically, we created three products. They are: an OS (KOS), a standalone secure hypervisor (KSH), and a dedicated system for secure interaction among OS components (KSS). They can address various challenges on their own too, depending on the application.
For example, SYSGO, a German company, licensed KSS to use it in its own operating system, PikeOS. Some vendors are interested only in the hypervisor (KSH), which lets them securely run existing applications without modifying them. But for Kraftway switches, this level of integration was not enough, so they decided to deploy the operating system in full.
In other words, the key advantage of our operating system is its practical, accessible nature; it’s purpose-built rather than designed for generic hypothetical scenarios.
How would you prove the OS allows only listed operations to run?
Naturally, as soon as we claimed the system was secure by design, some people refuted the claim, not believing it. That’s absolutely fine: in the world of cybersecurity one should not take anything at face value.
Our operating system’s architecture is based on the principle of dividing objects into the maximum number of isolated entities. Customers may examine the source code to make sure there are no undocumented capabilities inside the system. The rest is in effect configured together with the customer in the shape of various security policies designed to substantiate literally every tiny thing.
The system will do only the things you want it to do. Thus, adversaries won’t be able to take advantage even of a bug in an app created for this OS. Of course, you can write lengthy code with a lot of bugs. But for the code to work, it has to comply with strict policies that define what code can and can’t do.
Do you really think anything will work on that OS?
Sure, because our system is extremely flexible! In general, it could be further tweaked to become a mass-market product, but that would require quite a lot of time and resources. Right now we haven’t planned that far ahead, and we see our solution as a niche offering.
Also, keep in mind that it’s possible to port third-party code to the OS. Our solution includes a secure hypervisor, which allows customers to run virtually any operating system as a guest OS and custom application (such as an Linux running Apache server).
Yes, if we could take this server, divide it into many isolated instances and write policies on how they would interact with each other, we’d get a far higher level of security. But it’s an awful lot of work. At the same time, anything is possible if you have enough guts and resources 🙂
That’s why we enabled custom applications in the hypervisor. Yes, we’ll get an initially secure OS with initially insecure customization. Anything happening inside this customization will be unclear. But we’ll be able to control its interactions with hardware, other customizations, and the outside world. That is already something. With such a configuration, escape from the sandbox is highly unlikely.
Oh come on, it will collect data anyway
The kernel does not transmit anything anywhere — that can be easily checked by looking at the source code (see above). The microkernel has practically nothing in it. All drivers are kept isolated. So to pass any data, one has to write another piece of code. It will be seen quite clearly — you don’t even have to look at the source code to see it. All of this is written in security policies. And the customer will always be able to audit those policies, regardless of the code. If the policies contain no instructions to send data, the system doesn’t do it.
Well, OK, but it must cost an arm and a leg
Frankly, I don’t remember ever buying arms or legs, so I’m not quite up to date on current street prices. But actually this comparison is dubious one. Our OS is not an out-of-the-box product; it’s a project offering.
We’re not selling a boxed solution with a cure-all for everyone. Instead, we collaborate with vendors and developers who provide, say, networking equipment, industrial automation systems, automotive solutions, even smart fridges. We provide the code and help configure the system based on their requirements. Consequently, the cost of the solution depends on application and the labor that needs to be invested in the final product.
Everything can be hacked, and your OS is no exception!
I agree, no answer is perfect – except for the number 42 🙂 Anything can happen. However, that’s no reason to give up! The very essence of cybersecurity is to make cybercrooks’ lives as difficult as possible, and make cyberattacks so costly that they become unprofitable business. In this respect, our OS is ahead of any competition.
That’s all for now. Please send any questions via social networks and check out our website to learn more.
Tips