Pt. 2: PC Containers – What are they good for?
Q & A: Securing Your Windows Workspace
Part one | Part two | Part three
Q:: Is it protected at the end point?
A:: Yes! The security architecture is designed on the principle that the container is residing on an unmanaged or un-trusted host, for maximum protection even if it is a corporate owned and secured device. As such, the Moka5 container can be encrypted with up to AES 256-bit to protect all apps, data, and files inside. Encryption uses a different random initialization vector (IV) for each block, and all blocks are encrypted in CBC mode with a SHA-256 or SHA-512 HMAC. In addition, metadata blocks have additional tamper protection. Unique identifiers are hashed into the keys so blocks cannot be moved between disks or within a disk, and blocks are not susceptible to replacement attacks. This security exceeds the requirements in IEEE P1619.1 Standard for Authenticated Encryption with Length Expansion for Storage Devices. It is more secure than TrueCrypt and similar full-disk encryption technologies. Even if an attacker obtains the files for the container, they will not be able to decrypt the data without breaking the AES encryption. In the diagrams below you can see how encryption is implemented and keys are managed for initial set-up, when the user is offline, and when passwords are changed.
Q:: Can I continue to control access to the workspace?
A:: Absolutely! Remote revoke or kill allows you to wipe the encrypted container from lost or stolen devices over the Internet or through a timeout mechanism.
Q:: What about other aspects of host and guest interaction? Copy and paste, drag and drop?
A:: There are over 130 management and security policies for governing the container and the workspaces inside that can be applied and changed dynamically as needs change and new capabilities are added. Moka5 organizes policies into two types: container and the workspace. Default policy settings apply to all instances, unless otherwise covered by a custom policy setting, and are configured to the most secure option out-of-the-box. Custom policy settings are targeted based on AD/LDAP groups and do not change when there is a change to the default setting. Group ordering will determine which policies and image version are operative if there is a conflict (i.e., a user who is a member of two groups). Container Policies: allow you to control the Moka5 container itself. For example, the level of encryption is a container policy. These controls apply independent of the workspace images that are subscribed on by the user. Workspace Policies: allow you to control the workspace images. These policies control the image behavior and security. For example, the ability to drag and drop data between the host and workspace is such a policy - or a policy that allows users to access more than one workspace from within a single M5 container, but only one at a time.
Q:: How do I make sure that the host machine is in a good enough security state to run the container?
A:: The Moka5 design principle assumes an unsecured host, which is why the system will prevent the operation of the container on a compromised machine. With the Moka5 container separated from the host by virtualization and protected through encryption, the three types of host vulnerabilities (other than the user, of course) that can compromise data inside a Type 2 hypervisor are keyloggers, screenscrapers, and host memory access. The anti-malware scanners included in M5 Player (AVG for Windows, ClamAV for Macs) are compiled into the container — meaning they won’t interfere with any other AV tools on the host or included in the corporate workspace. These AV scanners check for trojans, viruses, and other malware before decrypting the container and allowing the user access to the corporate workspace. If malware is detected, the user is never even presented with the login screen, so there is no opportunity for a keylogger to capture a password. It can also be configured to run periodically throughout the session where it will shutdown the container as soon as a host infection is detected. If additional host compliance checks are required – like validating the presence of tools to protect host memory, presence and currency of anti-malware suites including a personal firewall, or compliance with company configuration and patch standards – custom host check scripts can also be invoked prior to access.
Stay tuned for the final piece of “PC Containers – What are they good for?” next week!
Part one | Part two | Part three
Comments are closed.
