Divide and Conquer: Multidimensional Security Policies

The current architecture for infrastructure security, which aims to control traffic using technical means, can not provide the necessary segmentation and scaling in modern data centers. Support for any cloud solution requires one hundred percent virtualization, while the scale of application and service virtualization today does not exceed 70%. Yes, there are still physical servers and outdated applications to which the same security policies should apply. But instead of taking this state of affairs as the norm, we should consider them as exceptions from the general architecture, and develop a security structure around what constitutes the bulk of the load, that is, around virtualized applications in the form of virtual machines and containers.



This is what is meant by such a one-dimensional and consistent approach. Consider an example of segmentation of a high-level data center and outline a simple three-level scheme:


')
We could logically represent the security that is needed here, as a sequence of perimeters that regroup end systems connected by firewall policies:



Note that if all these rules were implemented through a single firewall without contextualization, they would form a single list that could be managed globally. Now let's add a “dimension” to these rules, allowing administrators to work on each of the servers.



As you can see, in order to add this simple policy, every firewall or entity must be affected. What if other “dimensions” are required, for example, the need to make any application (or application component) isolated from any other in the default data center?

Implementing complex security policies affecting the multidimensional structure of the application is extremely difficult. When multiple entities or physical devices are used together, the problem is exacerbated by the correct and effective propagation of security policies to them.

A one-dimensional consistent approach to security policies has not proven to be the right tactic to support operational security.

Multidimensionality in the virtual space

We do not say that safety equipment is no longer needed. In the context of data centers, they are usually required for the physical perimeter, where North-South traffic converges to a single point.

How then to deal with the described problem in the context of the program-defined environment?

To illustrate this approach, we will use VMware's Horizon View, VDI solution as a security application. From a network and security point of view, this is quite a complex deployment application, as some servers can be accessed from the Internet, while others are buried deep inside data centers, and virtual desktops are often located at different security perimeters, depending on which user group refers to them.

The following diagram gives an idea of ​​the interaction between components in a Horizon View environment with a minimum of 4 perimeters, which should be taken into account: internal client networks, external client networks, DMZ (demilitarized zones) and internal network.



In the context of NSX, we will use the Service Composer, which creates “bubbles” designed to group objects according to the workload attribute and regardless of their IP addresses , VLAN, or location.

To begin, let's consider the environment with which we will work:



The first step is to group the relevant parts of the application that need to be protected. Create 3 groups depending on the type of workload: one for Security Servers acting as proxies to the Internet, another for Connection Servers acting as desktop brokers and, finally, for all virtual desktops to be created. The idea here is that now the administrators (View admins) can add any of these services anywhere in the data center, and they will be automatically added to the appropriate groups.



Let's make the last bubble to cover the entire ecosystem of the Horizon View.



Note that objects and groups have no reference to the underlying infrastructure, since they are not identified by IP addresses , VLan, hypervisor technologies, a specific data center , etc. These objects can exist in one cluster, several clusters, several data centers, or even at several cloud providers.



The resulting group policy is then distributed and executed for each member of the Horizon View bubble, micro-segmenting each element into its own security perimeter.

We continue. Our application still needs to be managed by a specific administrator (View Admin). Like any other users, administrators will use the View Client for their vDesktop, then the NSX Distributed Firewall will recognize them as part of the “View Admins” group in Active Directory and apply dynamic rules to their vDesktops, allowing them to manage any elements inside the bubble of Horizon View , but also limiting them only to these elements.



The same applies to regular users who would like to receive additional rules for a particular vDesktop based on their participation in AD groups.



As we can see, the transition from a one-dimensional sequential static rule set to this contextual approach allows us to apply security in a more intuitive way by setting the perimeter around the natural boundaries of the application, the desktop, or everything that seems logical for these services, completely independent of any another section of infrastructure.

Adding “dimensions” to an application becomes simpler, because we approach the problem from the side of functional groups, and not from the point of view of creating compound security policies. For example, you can now easily set corporate security rules for "all MS Win2003srv" using the "OS-Type" virtual machine attribute to dynamically select group members.



In the past, this would have required an understanding of where all the Windows 2003 servers are located, what firewalls they are closed down, and then copying the adapted versions of the same set of rules to place different IPs in each firewall. When some servers are upgraded to the current version, the same manual process will occur again until our “bubble” simply removes them from the list, as they will not meet the membership criteria.

Finally, since the sum of these security groups is applied to each individual virtual machine, we benefit from working with group policies by creating a de facto micro-segmented perimeter of one machine everywhere in the data center, allowing you to inspect all traffic.

Integrated security as it is

Consistent one-dimensional security policies, such as those found in physical firewalls, have proven to be functionally complex to implement various aspects related to applications located in the data center.

Network virtualization with distributed virtualized security services offers new features, allowing you to regroup services, not a range of IP addresses , a set of hosts , etc. , and also provide benefits from reducing the total complexity in developing security policies. Group policies, micro-segmentation for one virtual machine, traffic checking…. All that.