Ceedo Workspace – Main Components
When installed on an endpoint, CeedoWorkspace will include the following components:
- The Container Engine
The Container Engine is in charge of the following tasks:
- Virtualizing applications by using a set of services and drivers that intercept and manipulate Kernel transactions and provide the medium that captures their result (i.e. write/read/modify file system and registry objects). This procedure is at the core of Ceedo’s Containerization process.
- Ensure endpoint compliance by checking that a host machine withstands some basic minimum security standards. Additionally the Container Engine can also close unauthorized processes and/or deny user actions (such as opening a configuration window in an application, or shutting down a VPN client while CeedoWorkspace is running).
- Container Images
One or more Virtual Hard Disk (VHD) files and their respective configuration files. The Container Image is the foundation of Ceedo’s Containers. The Container Image can be clean with no data, or contain pre-installed applications working out-of-the-box with no need to install anything outside the container.
- Application Launcher
The Application Launcher is the main interface between the user and the Container Engine. It relays user actions and configurations to the various components (services, drivers and executables) and allows for launching applications to run inside the container.
The Application Launcher can run “headless” (completely hidden from the user, with all of its functions pre-configured), or with a Graphic User Interface that allows launching applications, exploring the contents of the Container, and more.
Container Engine Flow and Features
- The Container Engine is loaded into Windows in one of two modes:
- Container On-demand
In On-demand mode, the Container is initialized by a user or admin triggered action (for instance launching a specific application, clicking a URL link, etc.). Once initiated, the Container Engine envelops specifically chosen processes, and isolates them from the rest of system and from other non-containerized processes. When triggered in-demand, the Container Engine can latch onto already running processes, launch applications installed on the host while capturing their read/write functions, or run entire applications that were installed into the container within its sealed environment.
The user and/or his admin can choose which applications will be containerized and which will be excluded, what parts of the OS will be accessible and how much control the end-user will have over the containerization process.
This is useful for example in a Bring-Your-Own-Device scenario. It ensures the privacy and security of a work session, while allowing users the freedom to use their computer for private needs outside the container, risk-free.
- Container On-Startup
When the Container is initiated On-startup, it captures and isolates the entire user session, meaning any and all read and write functions the operating system is trying to perform will be intercepted and contained, regardless of its originating process. inside the Container.
In this mode, the isolation isn’t coating specific processes, but rather creates an isolation layer between the whole container and the host PC. This is especially useful for capturing and delivering applications, supporting user-installed applications, extending and managing user profiles, and deploying entire workspaces on desktops beyond the organization’s reach.
- Ensuring Endpoint Compliance
- When the Container Engine loads it can run a security compliance test, checking the status of the host’s Antivirus, Firewall, Windows updates, and other minimum standards set by the administrator. If the host fails the test, the admin can decide whether the session should be terminated or a warning will suffice.
- Endpoint Monitoring
- The Container Engine can continue to ensure the session integrity all throughout the session. It can terminate any unauthorized processes and even close the entire container environment in certain cases (VPN disconnected, for example).
- Attaching Container Images
- Container Images can be stored in various locations:
- Locally, for instance the User’s local profile folder
- On the Network, for instance a shared NAS folder
- Or on portable devices, such as USB flash drives.
- In order to ensure integrity, the Container Engine also goes over all the binaries and Container Images to make sure they were not tampered with.
- Container Images can be stored inside encrypted volumes for increased security.
- Container Images can be loaded without a mount point. In that case it does not appear as a separate drive in Windows, which makes it harder to access in case of attacks.
- Launching Applications from within the Container
- The Container Engine supervises new applications the end user launches (regardless if they were originally packed into the container or installed onto the PC) and it can also latch already-running applications and make sure they run inside the container.
- Access Control and privileges
- The Container Engine can launch applications normally with the logged-on user’s account, or run them under a separate user account (run-as). Running containerized processes under a different user account adds additional separation between the runtime environment of containerized and non-containerized processes by configuring access permissions to and from the container according to the account privileges, elevation and read\write security permissions.
- Disaster recovery and forensics
- Container Images have child disks that store the data captured by the Container Engine. Each disk can be kept at the end of a session as a snapshot, which allows for easy rollback and post mortem investigations. It can also be deleted after each round, returning the container to its original state (i.e. stateless).