The term “thin client” often refers to a low-power computer with a functionally limited operating system running in a network terminal or client-server architecture. There are several reasons for using a thin client instead of a full-fledged computer in the workplace, one being to increase the level of information security.
Kaspersky Thin Client (KTC), Kaspersky’s thin client, was developed in accordance with the Cyber Immune methodology, and the purpose of this article is to explain how KTC’s Cyber Immunity is implemented to protect it from both known and unknown threats.
In order to answer the question “How does Kaspersky Thin Client achieve Cyber Immunity?” and to assess its benefits, we need to understand what Cyber Immunity is and why it’s needed. In this section, we will only touch upon these issues briefly; they will be discussed in more detail in a series of articles about the Cyber Immune design approach.
The modern cyberworld is characterized by the interpenetration (convergence) of all kinds of operational (OT) and information (IT) technologies. Not only have cars and airplanes, and transportation, industrial and management systems become “smart”, but so have people’s homes. Converged solutions are characterized by complexity, heterogeneity of components, high connectivity, global availability, high speed and large volumes of data transfer, as well as a large volume of program code, including borrowed code.
In such an environment, it is no longer sufficient to use only usual measures to protect inherently insecure cybersystems. An alternative approach – Secure by Design – has not yet become ubiquitous for two main reasons. First, designing a system that is structurally secure, as opposed to one that “just works”, requires cybersecurity expertise, and such expertise is expensive and scarce. Second, the Secure by Design approach is still poorly supported methodologically.
The Cyber Immune approach provides a methodology for developing a structurally secure cybersystem that combines a description of the development process and its architectural requirements. The goal of the Cyber Immune approach is to create a Cyber Immune software product whose stated values remain secure even under attack. In general, the Cyber Immune approach helps to formulate a security specification and build an appropriate architecture using security architecture patterns that provide demonstrably high-quality security properties for a cybersystem.
In this section, we describe the top-level architecture and basic functions of KTC, how its Cyber Immunity is achieved and what KasperskyOS contributes to it.
The following diagram shows the interaction of Kaspersky Thin Client with virtualization platforms:
Typical Kaspersky Thin Client operation (see the diagram below) is as follows:
The practical purpose of a Cyber Immune product is to ensure that the values claimed to be associated with the product in one way or another are maintained under all circumstances. Therefore, we have described KTC values as well as undesirable events related to them:
Based on this description of values from the consumer’s perspective, and in accordance with the provisions of the Cyber Immune methodology, the technical team developed the following security objectives, effectively a formalized KTC “security contract”:
Constraints on the implemented protection measures (a priori security assumptions), which are also part of the “security contract”, have also been defined:
What is the technical support strategy for achieving the established security objectives for KTC, considering the specified constraints? To define it, let’s summarize the top-level thin client architecture to visualize its problem areas in terms of formulated security objectives.
By mapping this schema to the KTC security objectives, we see the components that directly affect them:
A few comments need to be made about the library that implements the RDP protocol. It has a direct impact on security objectives – in particular, vulnerabilities in it can be exploited both to violate the integrity and confidentiality of received and transmitted data, and to gain unauthorized access to local data storage, which, among other things, stores sensitive key information such as access attributes, public key certificates, and so on. On the other hand, a proprietary “secure” implementation of a standard library is impractical from any point of view: commercial, maintenance and support, and compatibility.
A traditional approach would take all known vulnerabilities in the RDP library (there are currently several dozen) and develop responses to prevent threats. The Cyber Immune approach, however, is not so much about protecting system assets that have already fallen into a compromised state, but rather about eliminating the possibility of assets falling into such states. This is significant because, on the one hand, the standard library is constantly updated and new vulnerabilities will appear in the future, and on the other hand, there is no guarantee that even in a “frozen” version all the vulnerabilities have been identified. This is a very large volume of non-trivial code, and its deep verification is not commercially viable.
In accordance with the Cyber Immune approach, a potentially dangerous component should be isolated from the protected values. That’s exactly what we did, “overshadowing” the standard RDP library with our own standard trusted component with fairly simple functionality – TLS terminator – and limiting all interactions between components with security policies. Everything stated here about the RDP implementation library also applies to the audio streaming library. As well as for any other third-party library that implements any typical functionality.
As for local data storage, the approach to solving this problem is similar: first, instead of a single shared storage, multiple isolated partitions are used, and second, access to these isolated partitions is allowed only to a limited set of specialized trusted components, with all communication with them governed by security policies.
The technical strategy for achieving the security objectives is therefore as follows:
Achieving objective 1
Objective: in operating mode the device ensures the confidentiality and integrity of data transmitted between the device and a remote desktop; between the device and a remote desktop connection broker; between the device and a KSC server; between the device and a logging server.
Strategy: data confidentiality and integrity are ensured by the TLS protocol implemented by the trusted component template. When operating in trusted mode, remote desktops, connection brokers, KSC servers, and logging servers can only connect using public key certificates provided by the KSC admin.
Achieving objective 2
Objective: ensuring the integrity of data stored on the device, received from the user working directly with the device (certificates, connection details) and from the KSC server (configurations, certificates, licenses, details for disconnecting from the KSC server).
Strategy: public key certificates, connection details to desktops and KSC servers, configuration files, licenses are accepted only from trusted components and are stored in separate isolated storages, each accessible only by specialized trusted components.
Achieving objective 3
Objective: a thin client software update is only performed if the authenticity and integrity of the update is confirmed.
Strategy: the update image is digitally signed by the vendor’s trusted build system, which is verified twice – when uploaded to the trusted KSC server and by a specialized trusted component immediately before being applied to the local device. The “Secure Update” security template, implemented with the help of the KasperskyOS security monitor, is used for local verification of the update image signature before it is applied. As a result, after modifying the original top-level architecture in accordance with the technical strategy for achieving security objectives, we get the following version:
It should be noted that all interactions between system processes of a product running on KasperskyOS are defined by the product architecture policy, all other interactions are prohibited and impossible due to isolation. Process isolation and control of interactions between them through authorized IPC channels are ensured by the KasperskyOS microkernel. During interaction, the security policies of processes controlled by a dedicated trusted KasperskyOS service – the Kaspersky Security Module (KSM) security monitor – are checked. The monitor checks the methods, interfaces, parameters, system states and security models used by each participating process.
Analysis of known vulnerabilities from available vulnerability databases and technical threat modeling has shown that the developed architecture meets the stated security objectives, provided that the specified security assumptions are met.
KTC trusted application components are small specialized modules with simple interfaces and parameterization. In general, trusted components are responsible for implementing secure (TLS) connections and guaranteeing their authenticity, integrity, and restricting access to specialized isolated storages (signature certificates, authentication data, etc.). This is consistent with the strategy of achieving security objectives. Trusted components have undergone thorough verification: static code analysis, dynamic code analysis with test coverage analysis, code hardening, external independent fuzzing testing, and the final product has been subjected to independent penetration testing.
The Cyber Immune approach is conceptual, i.e., it is not tied to a particular operating system or platform – in particular, it is not synonymous with the use of KasperskyOS. However, KasperskyOS was originally developed within the ideology of Cyber Immunity, and today it is one of the most suitable tools for creating Cyber Immune software products. The architectural requirements of the Cyber Immune approach are implemented in KasperskyOS at the level of its own architecture, which makes the task of creating a Cyber Immune product much easier.
KasperskyOS is a microkernel operating system that implements the principles of deep process isolation and includes among the trusted system services a security monitor (Kaspersky Security Module) that controls the interaction of isolated system processes based on security policies. For each individual process, a policy is created that describes the rules of interaction with it, and the overall security policy of the product is formed as a set of these private policies collected into a single coordinated structure by a common architectural policy. Security policies are formalized using the Property Specification Language (PSL), i.e., the policies are actually code that undergoes testing and verification.
The KasperskyOS kernel is actually a microkernel with a relatively small amount of code (about 100,000 lines) and a very small set of functions. The main task of the microkernel is to organize isolated security domains (processes) and execute security decisions, whose calculation is the responsibility of the KSM security monitor, which is separate from the kernel.
Practical research by Kaspersky’s cybersecurity specialists has shown that KasperskyOS, due to its architectural features, prevents the vast majority of common threats “out of the box”. For example, KasperskyOS processes are not associated with any user, so threats related to unauthorized privilege escalation of executable code are basically irrelevant.
The Cyber Immune specifics of KTC are achieved not by developing a special functional architecture, but by modifying one of the typical functional architectures in accordance with the strategies for achieving the established security objectives. In other words, KTC is a full-fledged thin client with a variety of options for direct connection to remote desktops via RDP protocol, with the help of SCALA-R connection brokers, and connection to Citrix infrastructure. KTC also supports the safe use of audio conferencing. To ensure a high level of security and monitor the status of the KTC pool deployed in an organization, Kaspersky Security Center (KSC) is used to manage their configurations and updates. KSC has a Kaspersky Security Management Suite plug-in for organizing centralized administration of thin clients through a unified KSC management console.
The term “thin client” often refers to a low-power computer with a functionally limited operating system running in a network terminal or client-server architecture. There are several reasons for using a thin client instead of a full-fledged computer in the workplace, one being to increase the level of information security.
Kaspersky Thin Client (KTC), Kaspersky’s thin client, was developed in accordance with the Cyber Immune methodology, and the purpose of this article is to explain how KTC’s Cyber Immunity is implemented to protect it from both known and unknown threats.
In order to answer the question “How does Kaspersky Thin Client achieve Cyber Immunity?” and to assess its benefits, we need to understand what Cyber Immunity is and why it’s needed. In this section, we will only touch upon these issues briefly; they will be discussed in more detail in a series of articles about the Cyber Immune design approach.
The modern cyberworld is characterized by the interpenetration (convergence) of all kinds of operational (OT) and information (IT) technologies. Not only have cars and airplanes, and transportation, industrial and management systems become “smart”, but so have people’s homes. Converged solutions are characterized by complexity, heterogeneity of components, high connectivity, global availability, high speed and large volumes of data transfer, as well as a large volume of program code, including borrowed code.
In such an environment, it is no longer sufficient to use only usual measures to protect inherently insecure cybersystems. An alternative approach – Secure by Design – has not yet become ubiquitous for two main reasons. First, designing a system that is structurally secure, as opposed to one that “just works”, requires cybersecurity expertise, and such expertise is expensive and scarce. Second, the Secure by Design approach is still poorly supported methodologically.
The Cyber Immune approach provides a methodology for developing a structurally secure cybersystem that combines a description of the development process and its architectural requirements. The goal of the Cyber Immune approach is to create a Cyber Immune software product whose stated values remain secure even under attack. In general, the Cyber Immune approach helps to formulate a security specification and build an appropriate architecture using security architecture patterns that provide demonstrably high-quality security properties for a cybersystem.
In this section, we describe the top-level architecture and basic functions of KTC, how its Cyber Immunity is achieved and what KasperskyOS contributes to it.
The following diagram shows the interaction of Kaspersky Thin Client with virtualization platforms:
Typical Kaspersky Thin Client operation (see the diagram below) is as follows:
The practical purpose of a Cyber Immune product is to ensure that the values claimed to be associated with the product in one way or another are maintained under all circumstances. Therefore, we have described KTC values as well as undesirable events related to them:
Based on this description of values from the consumer’s perspective, and in accordance with the provisions of the Cyber Immune methodology, the technical team developed the following security objectives, effectively a formalized KTC “security contract”:
Constraints on the implemented protection measures (a priori security assumptions), which are also part of the “security contract”, have also been defined:
What is the technical support strategy for achieving the established security objectives for KTC, considering the specified constraints? To define it, let’s summarize the top-level thin client architecture to visualize its problem areas in terms of formulated security objectives.
By mapping this schema to the KTC security objectives, we see the components that directly affect them:
A few comments need to be made about the library that implements the RDP protocol. It has a direct impact on security objectives – in particular, vulnerabilities in it can be exploited both to violate the integrity and confidentiality of received and transmitted data, and to gain unauthorized access to local data storage, which, among other things, stores sensitive key information such as access attributes, public key certificates, and so on. On the other hand, a proprietary “secure” implementation of a standard library is impractical from any point of view: commercial, maintenance and support, and compatibility.
A traditional approach would take all known vulnerabilities in the RDP library (there are currently several dozen) and develop responses to prevent threats. The Cyber Immune approach, however, is not so much about protecting system assets that have already fallen into a compromised state, but rather about eliminating the possibility of assets falling into such states. This is significant because, on the one hand, the standard library is constantly updated and new vulnerabilities will appear in the future, and on the other hand, there is no guarantee that even in a “frozen” version all the vulnerabilities have been identified. This is a very large volume of non-trivial code, and its deep verification is not commercially viable.
In accordance with the Cyber Immune approach, a potentially dangerous component should be isolated from the protected values. That’s exactly what we did, “overshadowing” the standard RDP library with our own standard trusted component with fairly simple functionality – TLS terminator – and limiting all interactions between components with security policies. Everything stated here about the RDP implementation library also applies to the audio streaming library. As well as for any other third-party library that implements any typical functionality.
As for local data storage, the approach to solving this problem is similar: first, instead of a single shared storage, multiple isolated partitions are used, and second, access to these isolated partitions is allowed only to a limited set of specialized trusted components, with all communication with them governed by security policies.
The technical strategy for achieving the security objectives is therefore as follows:
Achieving objective 1
Objective: in operating mode the device ensures the confidentiality and integrity of data transmitted between the device and a remote desktop; between the device and a remote desktop connection broker; between the device and a KSC server; between the device and a logging server.
Strategy: data confidentiality and integrity are ensured by the TLS protocol implemented by the trusted component template. When operating in trusted mode, remote desktops, connection brokers, KSC servers, and logging servers can only connect using public key certificates provided by the KSC admin.
Achieving objective 2
Objective: ensuring the integrity of data stored on the device, received from the user working directly with the device (certificates, connection details) and from the KSC server (configurations, certificates, licenses, details for disconnecting from the KSC server).
Strategy: public key certificates, connection details to desktops and KSC servers, configuration files, licenses are accepted only from trusted components and are stored in separate isolated storages, each accessible only by specialized trusted components.
Achieving objective 3
Objective: a thin client software update is only performed if the authenticity and integrity of the update is confirmed.
Strategy: the update image is digitally signed by the vendor’s trusted build system, which is verified twice – when uploaded to the trusted KSC server and by a specialized trusted component immediately before being applied to the local device. The “Secure Update” security template, implemented with the help of the KasperskyOS security monitor, is used for local verification of the update image signature before it is applied. As a result, after modifying the original top-level architecture in accordance with the technical strategy for achieving security objectives, we get the following version:
It should be noted that all interactions between system processes of a product running on KasperskyOS are defined by the product architecture policy, all other interactions are prohibited and impossible due to isolation. Process isolation and control of interactions between them through authorized IPC channels are ensured by the KasperskyOS microkernel. During interaction, the security policies of processes controlled by a dedicated trusted KasperskyOS service – the Kaspersky Security Module (KSM) security monitor – are checked. The monitor checks the methods, interfaces, parameters, system states and security models used by each participating process.
Analysis of known vulnerabilities from available vulnerability databases and technical threat modeling has shown that the developed architecture meets the stated security objectives, provided that the specified security assumptions are met.
KTC trusted application components are small specialized modules with simple interfaces and parameterization. In general, trusted components are responsible for implementing secure (TLS) connections and guaranteeing their authenticity, integrity, and restricting access to specialized isolated storages (signature certificates, authentication data, etc.). This is consistent with the strategy of achieving security objectives. Trusted components have undergone thorough verification: static code analysis, dynamic code analysis with test coverage analysis, code hardening, external independent fuzzing testing, and the final product has been subjected to independent penetration testing.
The Cyber Immune approach is conceptual, i.e., it is not tied to a particular operating system or platform – in particular, it is not synonymous with the use of KasperskyOS. However, KasperskyOS was originally developed within the ideology of Cyber Immunity, and today it is one of the most suitable tools for creating Cyber Immune software products. The architectural requirements of the Cyber Immune approach are implemented in KasperskyOS at the level of its own architecture, which makes the task of creating a Cyber Immune product much easier.
KasperskyOS is a microkernel operating system that implements the principles of deep process isolation and includes among the trusted system services a security monitor (Kaspersky Security Module) that controls the interaction of isolated system processes based on security policies. For each individual process, a policy is created that describes the rules of interaction with it, and the overall security policy of the product is formed as a set of these private policies collected into a single coordinated structure by a common architectural policy. Security policies are formalized using the Property Specification Language (PSL), i.e., the policies are actually code that undergoes testing and verification.
The KasperskyOS kernel is actually a microkernel with a relatively small amount of code (about 100,000 lines) and a very small set of functions. The main task of the microkernel is to organize isolated security domains (processes) and execute security decisions, whose calculation is the responsibility of the KSM security monitor, which is separate from the kernel.
Practical research by Kaspersky’s cybersecurity specialists has shown that KasperskyOS, due to its architectural features, prevents the vast majority of common threats “out of the box”. For example, KasperskyOS processes are not associated with any user, so threats related to unauthorized privilege escalation of executable code are basically irrelevant.
The Cyber Immune specifics of KTC are achieved not by developing a special functional architecture, but by modifying one of the typical functional architectures in accordance with the strategies for achieving the established security objectives. In other words, KTC is a full-fledged thin client with a variety of options for direct connection to remote desktops via RDP protocol, with the help of SCALA-R connection brokers, and connection to Citrix infrastructure. KTC also supports the safe use of audio conferencing. To ensure a high level of security and monitor the status of the KTC pool deployed in an organization, Kaspersky Security Center (KSC) is used to manage their configurations and updates. KSC has a Kaspersky Security Management Suite plug-in for organizing centralized administration of thin clients through a unified KSC management console.
