Last year, the Mirai botnet showed just how vulnerable the Internet of Things device landscape is. Mirai is an executable Linux file in the ELF (Executable and Linking Format) format. It primarily targets DVRs (digital video recorders), routers, web IP cameras, Linux servers and other devices running Busybox, which is frequently used for embedded devices in the IoT environment. The botnet was used, for example, to carry out DDoS attacks. The 'advantage': IoT devices are normally online 24 hours a day.

Security can be further increased by integrating tools that make it more difficult to exploit vulnerabilities - including gaps that are inherent in a less secure design. Examples of this would be Grsecurity, Hardened Gentoo, Atlix, Yanux and again Astra Linux and AppArmor. Just a few years ago, so-called 'security guarantees' consisted of scanning the software for existing errors and vulnerabilities and testing its integrity with the help of checksum comparisons.

The measures listed above may have made conventional operating systems somewhat more secure, but they do not meet the specific requirements of systems that are part of a critical infrastructure. Even operating systems that are designed to be particularly secure from the outset cannot always guarantee the implementation of special security guidelines. For a relatively flexible IT product such as an operating system, targeted security requirements can only be specified precisely if it is operated for specific purposes on more or less precisely defined hardware, on which only certain software runs under precisely defined operating scenarios. In this case, a threat model can also be created to describe possible threats, which describes a specific set of security and trustworthiness requirements. Examples of this are specialized embedded systems based on LynuxWorks, Wind River or Green Hills.

Providing the same guarantees using a conventional operating system is much more difficult, as there are many more scenarios to cover for the secure execution of programs. In addition, there is usually the effort involved in creating policies for different types of access control (arbitrary, mandatory or role-based), the usual authentication mechanisms and other protective measures that do not require any special knowledge to manage. All in all, universal protection mechanisms need to be implemented. Provided the operating system runs on a defined hardware platform, usually from the same manufacturer, the compliance of these mechanisms with certain standards or a certain security profile can be reliably guaranteed. There are also examples of this, such as Oracle Solaris with Trusted Extensions, XTS-400 and OpenVMS, AS/400.

The biggest threats to industrial computers in the second half of 2016: Internet connections, removable storage devices and email clients.

© Caspb

Another aspect that should not be neglected: It is easy to overlook something in a classic operating system. This is because many software modules go far beyond the limitations to which they should actually be subject. This can be avoided with the aforementioned whitelisting approach, in which programs in the system are only allowed to do what they were developed for. A further advantage of this approach is that if something has fallen by the wayside, the worst that can happen is that a program does not run - damage to the overall system cannot be caused as a result.

These strict guidelines on which actions are permitted increase security on the one hand and make life easier for developers on the other, as IT security guidelines (policy) and application programming are separated from each other.
This means that these two components of a secure software application can also be developed separately and the policy and code can be modified independently of each other. This also simplifies the checking, verification and testing of the application code.

Microkernel architecture increases modularity

Against this background and aware of the shortcomings of previous approaches, Kaspersky Lab has now developed its own operating system from scratch based on security principles. The underlying approach is based on a modular system of trustworthy components that are very small or consist of only a few lines of code and have standardized software interfaces, for example to a guest operating system. The architecture of a secure system set up in this way makes it possible to port lean software code to different hardware platforms. The result is Only this code needs to be verified there, while the 'top-level modules' are kept in such a way that they can be easily reused. A first step towards such a modular operating system is an architecture based on a dedicated microkernel. It alone determines interaction and data exchange and has full access control.

However, even this does not yet provide the features that the system needs to support certain security guidelines. KasperskyOS - the name of the new operating system - therefore separates access-relevant decisions based on security policies from those that are specified by the access control in the microkernel. The implementation of security policies based on compliance requirements is realized with a separate component, the Security Server. The best-known example of such an architecture is Flux Advanced Security Kernel (FLASK). The FLASK architecture has already been used to implement a whole range of operating systems, such as SELinux or SEBSD, but these systems have a large monolithic kernel.

Although KasperskyOS does not fully replicate the FLASK architecture, it uses its concepts for greater security and flexibility when used in target systems. In FLASK, the interfaces and descriptions for two main components are specified: for the Security Server, which makes the security-relevant decisions, and the Object Manager, which then provides the actual access based on these decisions. In this way, trustworthy decisions can be calculated and applied correctly. More complex rules, which are formulated with the help of a separate configuration language, bundle individual basic security guidelines.

The rules are implemented in a component located between the security server and the microkernel. The calculation of the security-relevant decisions can thus map the desired functional logic. This enables the configuration of comprehensive parameters for security policies (system-wide configuration at security server level) and the application of access rules for all operations in all system components (through the configuration of rules for calculating corresponding decisions).

This configuration ultimately results in trustworthy code that links the applications to the system's security model, because it is precisely defined which operations a program is allowed to perform under which security policies. The important thing here is: This information is not stored in the code itself, it is merely referenced.

Admittedly: Such a FLASK-like architecture with a microkernel is not an invention of the developers of KasperskyOS. There are already successful examples of such microkernels (seL4, PikeOS, Feniks/Febos) and some also have formally verified security properties. This allows operating systems to be developed that guarantee security domain isolation - an architecture that is also known as Multiple Independent Domains of Safety/Security (MILS).

However, such an architecture requires not only the development of the microkernel, but also a fully functional operating system that separates security domains and isolates information process environments. It must also monitor compliance with security guidelines in all domains. It is important that both the microkernel and the infrastructure of the operating system based on it and the security guidelines come from the same provider. The use of third-party components would always result in restrictions, regardless of their quality.

However, the biggest shortcoming of operating systems that are developed from scratch remains the lack of support for existing applications. If the operating system is compatible with common programming interfaces, this shortcoming can be partially compensated for, as the well-known example of POSIX shows. This disadvantage can also be remedied with virtualization. If a hypervisor for the virtualization of a common operating system can be started in the environment of the secure operating system, then its applications can also be executed in the secure environment. KasperskyOS in conjunction with Kaspersky Secure Hypervisor offers exactly this possibility. Under certain circumstances, a common, insecure system inherits the secure properties of the system running on the host.

The possible areas of application

There are many areas of application for such a secure operating system by design - including in various industrial applications or in systems that are used to control technological processes. Such systems do not require many different programs and each network node has its purpose and specific functions.

One of the core components of KasperskyOS - Kaspersky Security System - already protects programmable logic controllers in industrial environments. Together with BE.services, Kaspersky Lab has developed an implementation (Embedded Security Shield) that protects the main communication channel used in Codesys technology, the Codesys gateway.

The approach described is also ideally suited to the requirements of the connected car sector. Automotive and parts manufacturers can thus design and develop cyber-secure electronic units that are connected (to the Internet). The aforementioned Kaspersky Secure Hypervisor enables applications to run under strict control of their communication behavior. This solution can be used, for example, for in-vehicle infotainment, where one domain runs the critical software (e.g. CAN bus systems that connect all the control units in the vehicle) and another runs the entertainment software. The two virtual environments are completely independent and isolated from each other. Shared hardware units (network cards, GSM or WLAN) can also be integrated. An update of the infotainment software has no (dangerous) effects on critical components in the car.

Author:
Holger Suhl is General Manager DACH at Kaspersky Lab.