Ceedo’s Workspace Isolation and Protection Technology

Protects computing runtime environments


Multi-Tiered Virtualization Systems for Isolation

A multi-tiered virtualization-based approach to application isolation and data privacy, allowing secure computing and safe browsing to and from non-secure locations with a natural user experience, without relying on separate bootable OSs, Virtual Machines, remote execution servers or signature databases and threat detection systems.

The Application Launcher

The Application Launcher is the main interface between the user and the Kernel Firewall system components. It relays user actions and configurations to the various components (services, drivers and executables), and the most apparent of all – launching applications in isolation mode. Although coming with its own user interface, the Application Launcher can be completely hidden from the user, with all of its functions running automatically based on configurations, including automatically virtualizing applications, adding desktop icons for running applications in isolated mode, and more.

Ceedo’s Kernel Firewall Technology

At the core of Ceedo’s isolation technology is a component called the “Kernel Firewall.” The Kernel Firewall is made up of a set of specialized drivers that are sandwiched at different locations between the user request for an object and the Kernel component that executes said request. For instance, when a user application sends a ‘write file’ request to the Kernel, before reaching the Kernel itself, the request first passes through the drivers which constitute the firewall which can then decide if and where the file should be written to. The Kernel Firewall can track a transaction’s origin making sure isolation is inherited by all child processes of an isolated process, and denies any non-isolated process from accessing data generated by isolated processes, even if they naturally cross-communicate.

Virtual Drives

Once a call to a process or task has been intercepted by the Kernel Firewall, it can decide to redirect that request to a different volume (or hive), as explained above, or to allow it to fall through to the host (usually in the case of read and execute requests). In most cases, if a write request originated from an isolated process, it will be diverted to the virtual hidden drive, unless it was specifically excluded or blocked entirely by the permissions engine. The VHD files from which Ceedo’s Layers are constructed can be stored on the web and downloaded by our Application Launcher system to the local machine, or they can reside on a network drive with a local child disk, or even on a removable drive.

Permissions and Enforcement Engine

Run-As Function:
Ceedo creates a temporary virtual user account – CWSuser – and runs designated applications under this account, ensuring complete separation between the isolated applications and the rest of the desktop environment at the user session and NTFS permissions level. This allows applications to have their own read and write permissions, network and resource access, etc., which differ from that of the logged on user.

Process and Signature Enforcement:
Ceedo has an integrated process and signature enforcement engine that, based on various rules, can prevent any unsigned process from running, stop processes with specific certificates from running, stop specific process names from running (with and without MD5), and more.

Encrypted Containers

On top of its internal Virtual Drive system, Ceedo has a deep coupling with VeraCrypt (VC) encrypted volume software, which allows the VHD files to be stored inside a VC-encrypted container. The VC container itself is created on-the-fly on the client machine, and when applicable, if an administrator pre-assigned specific Layers to the user, they are downloaded directly into the encrypted volume. Furthermore, to make sure that the VC encrypted container cannot be opened by a different user and/or on a different machine, or opened directly through VeraCrypt itself, the passwords users provide for their own container during creation, are salted with various machine and user-specific parameters, so even with the correct password, the VC container cannot be opened if it is not accessed directly from Ceedo’s interface on the specific machine it was installed, and by the specific user that installed it.