Operational Environment

The operational environment includes physical systems and their components, datacenter architects, administrators, and members of the IT organization. A security breach can occur at any point in the operational environment.

Virtualization places a layer of software between the actual hardware and the guest domains that run the production services, which increases complexity. As a result, you must carefully plan and configure the virtual system and beware of human error. Also, beware of attempts by attackers to gain access to the operational environment by using “social engineering.”

The following sections describe the distinctive threats that you can counter at the operational environment level.

Threat: Unintentional Misconfiguration

The primary security concern for a virtualized environment is to sustain server isolation by separating network segments, segregating administrative access, and deploying servers to security classes, which are groups of domains that have the same security requirements and privileges.

Carefully configure virtual resources to avoid some of the following errors:

• Creating unnecessary communication channels between production guest domains and the execution environment

• Creating unnecessary access to network segments

• Creating unintentional connections between discrete security classes

• Unintentionally migrating a guest domain to the wrong security class

• Allocating insufficient hardware, which might lead to unexpected resource overloading

• Assigning disks or I/O devices to the wrong domain

Countermeasure: Creating Operational Guidelines

Before you begin, carefully define the operational guidelines for your Oracle VM Server for SPARC environment. These guidelines describe the following tasks to perform and how to perform them:

• Managing patches for all components of the environment

• Enabling the well-defined, traceable, and secure implementation of changes

• Checking log files at a regular interval

• Monitoring the integrity and availability of the environment

Regularly perform checks to ensure that these guidelines remain up to date and adequate, and to verify that these guidelines are being followed in everyday operations.

In addition to these guidelines, you can take several more technical measures to reduce the risk of unintentional actions. See Logical Domains Manager.

Threat: Errors in the Architecture of the Virtual Environment

When moving a physical system to a virtualized environment, you can usually keep the storage configuration as-is by reusing the original LUNs. However, the network configuration must be adapted to the virtualized environment and the resulting architecture might differ considerably from the architecture used on the physical system.

You must consider how to maintain the isolation of the discrete security classes and their needs. Also, consider the shared hardware of the platform and shared components such as network switches and SAN switches.

To maximize security for your environment, ensure that you maintain the isolation of guest domains and security classes. When you design the architecture, anticipate possible errors and attacks and implement lines of defense. A good design helps to confine potential security issues while managing complexity and cost.

Countermeasure: Carefully Assigning Guests to Hardware Platforms

Use security classes, which are groups of domains that have the same security requirements and privileges, to isolate individual domains from each other. By assigning guest domains that are in the same security class to a certain hardware platform, even a breach of isolation prevents the attack from crossing into another security class.

Countermeasure: Planning an Oracle VM Server for SPARC Domain Migration

The live domain migration feature has the potential to break isolation if a guest domain is inadvertently migrated to a platform that is assigned to a different security class as shown in the following figure. So, carefully plan guest domain migration to ensure that a migration across security class boundaries is not permitted.

Figure 4 - Domain Migration Across Security Boundaries

Countermeasure: Correctly Configuring Virtual Connections

Losing track of all of the virtual network connections might lead to a domain gaining erroneous access to a network segment. For example, such access might circumvent the firewall or a security class.

To reduce the risk of implementation errors, carefully plan and document all of the virtual and physical connections in your environment. Optimize the domain connection plan for simplicity and manageability. Clearly document your plan and verify the correctness of your implementation against your plan before going into production. Even after your virtual environment is in production, verify the implementation against the plan at regular intervals.

Countermeasure: Using VLAN Tagging

You can use VLAN tagging to consolidate several Ethernet segments onto a single physical network. This feature is also available for virtual switches. To mitigate the risks involved with software errors in the implementation of virtual switches, configure one virtual switch per physical NIC and VLAN. To further protect against errors in the Ethernet driver, refrain from using tagged VLANs. However, the probability for such errors is low as this tagged VLAN vulnerability is well known. Intrusion tests on Oracle's Sun SPARC T-Series platform with the Oracle VM Server for SPARC software have not shown this vulnerability.

Countermeasure: Using Virtual Security Appliances

Security appliances such as packet filters and firewalls are instruments of isolation and protect the isolation of security classes. These appliances are subject to the same threats as any other guest domain, so using them does not guarantee complete protection against an isolation breach. Therefore, carefully consider all aspects of risk and security before you decide to virtualize such a service.

Threat: Side Effects of Sharing Resources

Resource sharing in a virtualized environment might lead to denial-of-service (DoS) attacks, which overload a resource until it negatively affects another component such as another domain.

In a Oracle VM Server for SPARC environment, only some resources might be affected by a DoS attack. CPU and memory resources are assigned exclusively to each guest domain, which prevents most DoS attacks. Even the exclusive assignment of these resources might slow down a guest domain in the following ways:

• Thrashing the cache areas that are shared between strands and are assigned to two guest domains

• Overloading memory bandwidth

Unlike CPU and memory resources, disk and network services are usually shared between guest domains. These services are provided to the guest domains by one or more service domains. Carefully consider how to assign and distribute these resources to guest domains. Note that any configuration that permits maximum performance and resource utilization simultaneously minimizes the risk of side effects.

Evaluation: Side Effects Through Shared Resources

A network link can be saturated or a disk can be overloaded whether exclusively assigned to a domain or shared among domains. Such attacks affect the availability of a service for the duration of the attack. The target of the attack is not compromised and no data is lost. You can easily minimize the effects of this threat, but you should keep it in mind even though it is limited to network and disk resources on Oracle VM Server for SPARC.

Countermeasure: Carefully Assigning Hardware Resources

Ensure that you assign only required hardware resources to guest domains. Be sure to unassign an unused resource after the resource is no longer required, for example, a network port or DVD drive required only during an installation. By following this practice, you minimize the number of possible entry points for an attacker.

Countermeasure: Carefully Assigning Shared Resources

Shared hardware resources such as physical network ports, present a possible target for DoS attacks. To limit the impact of DoS attacks to a single group of guest domains, carefully determine which guest domains share which hardware resources.

For example, guest domains that share hardware resources could be grouped by the same availability or security requirements. Beyond grouping, you can apply different kinds of resource controls.

You must consider how to share disk and network resources. You can mitigate issues by separating disk access through dedicated physical access paths or through dedicated virtual disk services.

Summary: Side Effects Through Shared Resources

All the countermeasures described in this section require that you understand the technical details of your deployment and their security implications. Plan carefully, document well, and keep your architecture as simple as possible. Ensure that you understand the implications of virtualized hardware so that you can prepare to securely deploy the Oracle VM Server for SPARC software.

Logical domains are robust against the effects of sharing CPUs and memory, as little sharing actually occurs. Nevertheless, it is best to apply resource controls such as Solaris resource management within the guest domains. Using these controls protect against bad application behavior for either a virtual or a non-virtualized environment.