NSX: Security vs workability

In this digitalized world were the number of internet-connected devices is growing each year, the number of cyber-attacks (through data theft, ransomware, unauthorized access, etc.) is increasing also. Security is shifting towards the board-level at companies, because the costs involved with security-breaches are hitting the business hard. Security must be considered on all aspects: from the digital workspace (desktop, mobile) towards the datacenter were critical data is stored and applications/services are running.

When considering security mitigations there is always a trade-off with the workability and/or operations involved with it.


When security mitigations are set at a too high level the solution becomes either unworkable or unmanageable, which itself is a problem because people will found a way around this burden (which is not in the favor of the business). There must be a good balance between security and workability/manageability.

Micro-segmentation as a security offensive.

One of the IT trends of 2018 is micro-segmentation. Micro-segmentation enables security boundaries decoupled from the technical components, which enables a new set of security services understandable at C-Level.
Traditional security offensives are depending on technical constructs, such as VLANs, IP subnets and/or perimeter firewalls. These technical constructs are provided by the networking/security-team, but are tend to be technical solutions which are not in line with applications and/or business requirements.

For example, usually a “server”-VLAN is created which hosts all application servers/services and a separate “DMZ”-vlan is created which hosts internet-facing application servers/services. Internal/external network traffic is filtered through a dedicated (physical) perimeter firewall appliances.
Even until today this topology is widely used by most companies, because this topology achieves a moderated security level at a low complexity operation level.

But, this topology has it’s drawbacks:
– When an attacker has breached into the “server”-vlan, it’s just like a child in a candy-store, it grabs (or demolishes) whatever it can without any security-boundary (OS level firewalling is usually disabled, because as it is managed per server-instance (aka almost unmanageable).
– A topology with a server- and a DMZ-vlan can, security wise, only fulfill 2-tier applications: Today the majority of the applications has more than 2 tiers and/or other demands which not can be supported by this topology.
– The firewall rulebase is almost completely unmanageable: a firewall uses representations/constructs (objects) based on technical components, like IP addresses, (TCP/UDP)-ports and VLAN’s (aka. zones)). When an application or services is taken offline or changed, the security operation teams usually has trouble identifying which rules were involved with the application and/or service and even deleting or modifying is even harder, which results in unmonitored security-holes in the firewall rulebase.

Bottomline: The technical constructs do not match the business requirement which results in possible security breaches, costing the business a lot of money.

The promise of micro-segmentation is to enable security boundaries at the application level, which are decoupled from the technical constructs. The security can be more aligned with the business needs, mitigating security threads within the datacenter.

How is micro-segmentation achieved?

Micro-segmentation security is delivered at a server-instance level and is enabled through the use of Software Defined Networking (SDN). Each server which is connected to a (overlay-)network, is firewall’d at the interface-level. This enables firewalling at the server-instance level instead of the perimeter firewall level. With this methodology it is possible to create security boundaries around the servers which belong to an application and/or between application tiers.

An SDN has the benefits that it can integrate more efficient with the application-stack, as it is completely driven by software (the SDN-controllers/manager). With an SDN it is possible to use other constructs like: security tags, (dynamic) security groups, server (VM) names, logged on user and/or security policies (which can be re-used again and again .. and again), etc. This enables the business (and/or applications) to set a higher security level, by segmenting on a finer/granular level lowering the attack-surface for cyber-attackers.

But, just as with a perimeter firewall, for micro-segmentation a firewall rulebase is still needed. There are multiple ways of organizing the firewall rulebase which are described below.

arrows box business chalk
Foto door Pixabay op Pexels.com

From an operational/administrative view, it is advisable  to use security policies and/or a security framework, which can be used repeatedly at different applications. This makes the firewall rulebase manageable, as the security offensive is predefined and only applied at the application-level. When an application is removed, the security policy associated with it is removed automatically leaving no security holes. The implication with this approach is that there must be enough security policies available to accommodate ALL application-types, but this is just a matter of time and experience from the network/security team to fill in all gaps.

Implementing micro-segmentation

With SDN there are multiple ways of creating the firewall rules, enabling micro-segmentation.
Below I will describe a few methods of creating firewall rules which are manageable:

  • Create firewall rules manually:
    Do you seriously think you can apply micro-segmentation firewall rules manually? This is too much of a burden on the operational team: No can do!
  • Creating firewall rules based on network analyses!
    now we are talking
    VMware prescribes the use of vRealize Network Insights, which shows a complete list of firewall rules based on current network analyses over a period of time, which can be imported into VMware NSX. This enables micro-segmentation instantly for brownfield environments, but with some drawbacks: The operation teams still have some trouble tracking firewall rules and it does not provide firewall rules for new applications: new applications must be analyzed before new firewall rules can be applied.
  • Creating firewall rules through the use of security policies: The security policy prescribes exactly which type of network traffic is allowed or prohibited. The security policy must be applied to application servers (aka virtual machines) manually or though automation. When a security policy is applied, a specific firewall section is created which contains all necessary firewall rules for that application. When a application is modified a new security policy is applied or when the application is removed, the security policy is automatically removed also.
  • Through the use of an “security framework” (note: a security framework is a non-official method by VMware means): With a security framework almost all of the firewall rules and sections are predefined. The rules are based on (dynamic) security groups, which are enabled by security tags. By tagging server instances with one or more security tags, a virtual machine becomes a member of a security groups and the predefined firewall rules are automatically applied. Usually a security framework is built upon multiple security layers. Each security layer performs it’s own distinct filtering. Examples of security layers are customers, environments (for example: “Develop”-, “Test”-, “Acceptance”-, “Production”-environments), application grouping (for example: “Finance”, “intranet” and/or “email-services”) and/or application-tiering (for example: “web”-, “app”- and/or “database”-tiers). A security framework consist of a few predefined firewall rules, with some exceptions: the amount of firewall rules is low with this method.

Which method to use depends on the use case and organization structure.

It must also be mentioned that all above methods rely on human interaction to be set up  correctly. VMware has bought AppDefense which enables micro-segmentation through machine-learning, AppDefense analyses the application and creates a network baseline, firewall rules based on this baseline are created automatically. This technology looks like the ultimate solution and it exist today but it’s rather new and must gain some momentum in the IT security area to be accepted.


With micro-segmentation a higher security level is achieved within the datacenter, but without automation, security policies or a security framework it is almost unmanageable. which itself becomes a security threat as the operational teams are going to operate out-of-sight of the board-level leaving security gaps. Software Defined Networking helps securing the business, but at the same time adds complexity for the operational teams.

Customers have to rethink their security offensives and the operational network/security teams must offer security mitigations which are decoupled from traditional technology constructs to be able offering security at the application level and fulfill the nowadays business needs.


4 Reacties

  1. […] always it is a constant battle between maintainability and the level of security for every organization. The evolvement of a […]

  2. […] topics I had to address during my professional career are “NSX vs ACI” and micro-segmentation. These are not “What is the future brings us” or roadmapping topics (which i’m […]


Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *