I recently finished a great project where our team replaced the enterprise firewall used in two DMZ’s with vShield Edge and vShield App (using vShield 5.0), in a PCI environment supporting some of the customers most critical applications. Due to the nature this type of environment there are a number of considerations that were important to completing it successfully.

• Creating a small management cluster of hosts to host the vShield Manager, vCenter and vCenter DB and other supporting infrastructure. This is important to allow the managed infrastructure to be independent of the infrastructure that is being managed. If vShield Manager is deployed within the infrastructure it is protecting you will suffer circular dependencies that will prevent the solution, including vCenter from functioning, as all the traffic will be blocked during the implementation process. In larger environments this can be solved by using the design I described in vShield App Design for the Enterprise.

• Firewall rule groups will need to be translated from the old firewall into vShield Manager and then used as the basis for the rules. This can cut down the number of individual rules necessary to provide the same level of security.

• Set up roles and responsibilities within vShield Manager that only allow the minimum of permissions to perform required functions by administrators. You should apply the ‘least privilege’ concept in all cases. Ensure audit logs are reviewed regularly.

• Firewall rules are required for both vShield Edge interfaces for each traffic flow. If a flow is going in the internal and then out the external interface you will need to ensure you specify a rule to allow each direction to be accepted i.e. two rules are required for this case.

• When using the vShield Edge as a static router and the default gateway for the network ensure you specify the correct SNAT rules and masquerading rules to allow for authorized internal traffic to reach the internet. Make sure that any traffic flows from an intermediate DMZ flow through the correct vShield Edge in a two vShield Edge Setup, some static routes on the VM’s may be necessary. If the vShield Edge doesn’t see the entire conversation traffic will be blocked, as it will interpret any part conversation as unauthorized due to the statefull inspection nature of the vShield Edge.

• Define a thorough test plan that will test all the necessary applications and rules that are required. Penetration testing and external auditing would also be advised to ensure that the solution minimizes any potential security risks.

• Only allow authorized and defined traffic in the DMZ’s and deny everything else, this includes traffic between virtual machines, which should be set to denied by default with vShield App (vShield App default setting is to allow traffic), unless specifically authorized. Any traffic flows that are not absolutely necessary to allow proper functioning of applications should be blocked.

• Audit the source and destination firewall rule bases with a very fine toothed comb. Any rules that are not absolutely essential should be removed.

• Create security groups for objects that have common security requirements, such as vNIC’s, other security groups, port groups, IP subnet groups, then use the groups rather than the individual objects to apply firewall rules.

• If you have a common group of ports that are assigned to multiple objects consider creating an application group that contains the ports, for example you might create an application group called WEB containing both TCP 80 and 443.

• Ensure that vShield Edge and vShield App appliances send all their logs to a centralized Syslog server or infrastructure. Consider mirroring the logs to an alternate site to ensure availability of logs in case of incident investigation or response if something happens to the primary site. Consider using a tool such as Splunk, RSA enVision or similar to visualize and correlate log events and highlight any possible events of interest.

• When protecting non-virtual systems using vShield Edge ensure that the vShield Edge is the gateway for the physical systems.

• During the implementation and troubleshooting process log all traffic and enable default logging on the vShield Edge to ensure all accepted and dropped packets are visible in Syslog. Filter or grep Syslog to identify any rule errors during technical and business acceptance testing.

• Use the vShield REST API’s in addition to the vShield Manager backup functionality to back up the firewall rule base and store this in a version controlled repository such as SVN or CVS. Use the REST API’s to turn off accept rule logging when troubleshooting and implementation processes are complete unless there is a reason to leave it enabled.

• vShield Edge doesn’t currently support any more than two interfaces, and Internal and External interface. In the future this will be expanded to support multi-leg vShield Edge implementations, similar to what can be achieved with physical firewalls currently.

• Remember when provisioning new Virtual Machines to include them in the correct security groups. This will ensure that the correct rules are applied without any additional actions by the administrators.

• If you are replicating the infrastructure to a DR site ensure that vShield Edge and vShield App are set up appropriately at the DR site and that you have a process to ensure the rule base is up to date. Security testing at the DR site should also be included in DR testing processes. Updates and changes to the DR site can be automated using the vShield REST API’s, which can also be integrated with VMware vCenter Site Recovery Manager.

• Business Critical Applications projects require detailed and careful planning, design, and quality assurance to ensure success. Testing needs to cover application functional and non-functional requirements in addition to security.

• vShield Edge doesn’t currently support IPv6 in v5.0, so this should be considered when you are planning your implementation. However the way that vShield Edge is implemented can reduce the need to go to IPv6 addressing, and it can still be integrated into an IPv6 environment. IPv6 has been designed to be used along side IPv4. IPv6 support is important and will be included in future releases. vShield App is agnostic to IPv4 and IPv6 when using it’s layer 2 firewalling capabilities.

The combination of vShield Edge and vShield App provides a powerful security solution that can be used to protect both virtual and non-virtual systems and provide important insight into authorized and unauthorized traffic flows. It can be integrated into DR solutions using SRM and the REST API’s, and can be integrated into IPS/IDS solutions and RSA and vShield Data Security solutions. During provisioning new virtual machines will inherit the correct rule base when administrators add them to the correct security groups. All VM traffic on the hosts is inspected and traffic between VM’s can be inspected and secured even when the VM’s are on the same port group, without the need of Private VLAN’s or port ACL’s.

Special thanks to my colleagues in VMware Professional Services and the Customer for making this project such a great success. As with all Business Critical Applications projects success depends on a great team effort.

Helpful References:

Use the VMware Free PCI Compliance Checker for PCI DSS.

VMware vShield App with Data Security

This post first appeared on the Long White Virtual Clouds blog at longwhiteclouds.com. By Michael Webster +. Copyright © 2012 – IT Solutions 2000 Ltd and Michael Webster +. All rights reserved. Not to be reproduced for commercial purposes without written permission.