Create microzones for finer granularity separation: The granularity of separation based on zoning approaches is typically fairly coarse. For example, it usually limits a set of users and their machines to accessing other sets of machines and their content. File system and user identity are also fairly course in that they typically allow access to all of the content readable by any given user within the available file systems. Finer granularity becomes a complex matter and is poorly supported at the enterprise level by technical mechanisms. Microzones created by virtualization and encryption offer a finer grain of separation by allowing each virtual machine to run a subset of programs with access to a subset of file system areas over a portion of time. It does so with finer granularity than other zoning approaches, and is more rapid to deploy in small special purpose applications.
Create microzones to limit risk aggregation: Risk aggregation may come in many forms. In addition to reduction of aggregated risk by limiting the total accessible information from a given location (e.g., a zone, subzone, machine, storage area, etc.) risk is also aggregated over time by the presence of mechanisms available over time. Microzones implemented in virtual machines, for example, only operate while the machines operate, and thus the shutdown of the machines may limit the period of exposure.
Create microzones to allow safer untrusted applications, content, and access use at lower cost: In many cases, and particularly in less controlled (non-high consequence) environments, use of untrusted content, applications, or access are desired, but the cost of creating and operating completely separate environments for such use exceeds the potential utility gained. Microzones provide the means to allow reasonable containment of content, applications, and access at relatively low cost. While this is not suitable for high consequence environments because of the surety limitations associated with microzoning today, it is highly suited to many other situations where substantial risk reduction is desired, particularly for limited time frames.
A typical example is the creation of a microzone for shared access sessions involving changes to a common document, where the effort is (1) time limited (i.e., only for the period of the on-line meeting), (2) requires access to a limited storage area (i.e., the documents being reworked and related content), and (3) requires access from multiple locations (e.g., via encrypted tunnels from multiple remote desktops). For environments configured for the purpose, this requires only a few minutes at the start of a session and substantially reduces risks associated with remote desktop access and related file sharing. The typical process involves starting a virtual machine (VM), loading copies of the supporting (read-only) files into the VM internal storage area, loading the content to be modified into a shared file area (or remotely mounting an appropriate micro-zoned file system via encrypted tunnel), and running the desktop sharing application and related editing applications from inside the VM. At the end of the session, the VM is shut down (not retaining any changes made to is), thus (1) eliminating residual effects of its operation outside of the shared or remotely accessible storage area, and (2) leaving the modified document available for use.
Don't use microzones: Microzones are not suited to many cases. For example, and without limit, when large bodies of information from a wide range of a-priory unpredictable areas are needed, when very high performance is required, and when high surety is required. Its use for effective protection also requires a level of maturity, typically Defined or above, although repeatable may be adequate for low consequence environments, and it takes time and money to operate effectively.
Implement microzone computation with virtual machines within machines: This involves the creation of virtual machine (VM) environments within computers to act as microzone operating environments. In most cases, these exist either on desktops or within what is commonly called cloud computing environments. VMs in internal clouds are used just as in external clouds, but can be operated within internal zones and subzones to provide adequate and required surety levels based on internal rather than external criteria. Within user machines, VMs tend to act as temporary work areas for limited purposes. They can be popped up and shut down and granted limited access during use, retaining some or none of the content or changes associated with their periods of operation.
Implement microzone communication within subzone and zone via encrypted tunnels: If communication is required within a microzone, the typical approach is to link machines to other machines (including storage machines) using encryption. This typically consists of remote file system mounts through encrypted tunnels such as via SSL or SSH tunnels. For example, from a VM, a remote area of a disk may be mounted for use via an SSH tunnel using the sftp protocol and a local mount daemon that attaches the mounted filesystem area to a virtual disk on the VM. This can be done read-only or read-write, so that specific filesystem areas can be micro-managed. However, the overhead of such micro-management may be problematic and expensive if overdone.
Implement microzone storage with sub-file-system storage areas within subzone and zone storage: Within a storage area (e.g., a disk, disk array, file server, etc.), zones or subzones may be further segregated, and presumably access restrictions associated with those areas will be in place for the microzones contained within them. But additional separation may be applied within microzones for finer granularity of control. For example, remote disk mounts may be to subdirectories within file systems within partitions within disks of a larger file system area within a zone and subzone. The smaller the area mounted, the less access and effect the microzone will have.
Implement microzone storage with encrypted storage at the microzone level: In cases where encryption is mandated or otherwise desired, encryption can be used to create microzone areas that are restricted to those with the appropriate keys. By only using (or having available) the keys within the microzone, microzones can limit access to microzone content. However, all of the issues of key management then get extended to the microzone level, a granularity at which most enterprises have difficulty operating encryption effectively.
The operating environment supports only low granularity separation and higher granularity is desired by clients or management: In most modern operating environments, separation is at most to the level of the user identity. However, in many cases, clients want their content separated from other clients, and many managers see no reason that access to all should be granted when access to only subsets is desired. The complexity of management becomes too high for these cases at the operating environment level, but at the microzone level, it may be achieved if adequate discipline is applied. For example, file system mounts to portions of different areas may allow finer granularity the operating environments not using this approach may support.
Risk aggregation justifies separation at finer granularity that the operating environment supports: In some cases, particular operations induce undesired risks, even though risk aggregation at the zone and subzone layer are normally adequate to the need. For example, when using desktop sharing for presentations or interactions with others, even if the risk associated with the internal user is not excessive, the aggregated risk of the internal user's access is too high for the remote less trusted user (e.g., client, potential client, etc.) to be granted as part of remote desktop or other shared access, even under any supervision that internal user may provide. In these cases, microzoning for the purposes of the remote access or collaborative effort may be suitable to the need without requiring the creation of special zones, subzones, etc. for each potential future use or enterprise management of each such instance.
Untrusted content or applications are desired but otherwise too risky: In many cases, temporary use of content or applications is highly desirable, but they are not trustworthy enough to grant access to the subzone and zone the user is otherwise able to access. In these cases, a microzone may be created for these risk operations, and less access may be granted for those uses through a microzone.
Risk aggregation, granularity, or content and application trust limitations stem from the computational mechanism (e.g., endpoint, server, etc.): In cases where trust limitations stem from the computational (as opposed to communications or storage) mechanism, virtual machines may be a reasonable solution. For example, internal users may be responsible for testing a wide range of software products for a particular use, only one of which will ultimately be used and fully vetted for its purpose. Since many of these are readily downloaded from the Internet for testing purposes, rather than create a whole testbed for this use, a microzone may be created using virtual machines and restricted storage access for the purposes of the testing, and removed afterward without residual side effects. Again, a VM can often be used to create a microzone for such a purpose at low cost.
Microzones extend beyond a single machine and its local storage: In some cases, a microzone may need to extend beyond a single machine. For example, if remote storage, sharing, or other similar interaction is desired, some methods of communication while maintaining microzone separation may be called for. In these cases, encryption between endpoints may be highly desirable.
Microzones access only a small and severable portion of the otherwise accessible file system area: In many cases, the microzoning strategy extends to restricting access to file systems and other storage. In these cases, a storage restriction mechanism may be important to microzone implementation. For example, mounting of small portions of file system, or access to embedded filesystems stored as single files within other filesystems may be a usable approach to controlling such access.
Encryption is required for the microzone content but not other subzone content: Encryption if sometimes desired for specific content, but not all content within a zone or subzone. For example, if a few clients demand encryption while other do not, and no other reason exists for encryption of a whole zone or subzone, a microzone encryption strategy may be applied at limited cost to supporting these clients without the cost or complexity of a larger scale encryption approach.