After working relatively closely with Security Officers over the years, I understand their pain. Applications have traditionally been designed and deployed with security as an afterthought. It was either too hard, unknown, the skills weren’t there, or it is political and “easier” to seek forgiveness. I believe one of the core issues was that the tools or processes to implement policies and procedures were not present, or were difficult to use, especially as the use of public cloud environments has evolved.
Times have changed, and it’s fair to say that security is now front of mind for developers, architects, implementers and operational staff. The risk is too high for organisations to not have security at the forefront. The technology and tools associated have come a long way in helping us navigate the journey of securing our applications, wherever they may be located.
One of the major components that comprise the goal of the VMware Software Defined Data Centre (SDDC) is networking and security, also known as Software Defined Networking (I needed to slide a buzz phrase in!). One product that VMware have in the Software Defined Networking (SDN) space and that is a core component of the VMware SDN strategy, is NSX, which will be the focus point of today's post.
Firstly, let me start by saying this; NSX as a product and a solution, is a beast. We're only going to scratch the surface today, and I'll be tying it back in to the theme of this blog series - Security. We will only focus on the security components of NSX. There is much more to NSX as a solution, so I encourage you to do some homework on other problems NSX can solve for you in the data centre and/or get in touch with us to help.
I don't want to spend a lot of time on this, but it is important to note, that at the time of writing, there are two versions of NSX that you should be aware of, and it is important to note that these are two very different products using two very different code bases for different purposes. The two versions are NSX for vSphere and NSX-T.
NSX for vSphere, as per the name, is tied very closely to VMware vSphere environments, in fact it relies on vCenter Server and ESXi. NSX for vSphere today is the most commonly deployed version of NSX. On the other hand, NSX-T is the newer kid on the block and has been developed by VMware from the ground up with a vision to support cloud native applications, containers, bare metal workloads, multi-hypervisor environments and public cloud environments, including multi-cloud. VMware recently released version 2.4 of NSX-T (early 2019 calendar year), and with this release the official advice from VMware is that a greenfield deployment of NSX should almost always be NSX-T. While VMware will continue to support NSX for vSphere for some time to come, for me the writing is on the wall that NSX-T is where the future development and innovation from VMware will be focused. With that said...
...the topics I'm going to touch on in this post, except for multi-cloud (NSX-T only), are valid for both versions of NSX. Let's crack in to it.
From what I see in my corner of the world, through talking to VMware employees and reading information from the Networking and Security Business Unit, the most popular problem or use case that customers look to NSX to solve, is for micro-segmentation of their applications. In my simple view, micro-segmentation is a method of creating very granular network zones, which can be as specific as a single interface on a virtual machine or workload, and then applying rules and policies at that granular level. To use a simple example, think of having a firewall built in to your platform that wraps around every virtual NIC of every virtual machine running in your environment, while being able to centrally manage and maintain the rules and policies that are applied across your environment, holistically. A lot of customers I work with will, at best, have a firewall sitting at the edge of a Layer 2 network, but no firewall protection within a Layer 2 network. This is where micro-segmentation comes in and NSX's Distributed Firewall (DFW) is a solution enabling micro-segmentation in your environment.
Customers love the idea of micro-segmentation, but after we've had the chat about how awesome it is and how it can help with securing their business critical applications, I will usually talk to them about what applications they are running in their environment, how the applications integrate with each other and external components, and what the dependencies are. Often, customers are unsure how a lot of their stuff is bolted together. Occasionally they do know, but they lack the detail that is required to make the implementation of micro-segmentation worthwhile. There are a lot of legacy applications, and a lot of poorly documented systems and applications that customers are consuming.
To be successful with implementing a micro-segmentation solution, you need to understand the data flow in your environment. VMware have a solution named vRealize Network Insight (vRNI) that helps in this area. While it isn't an NSX component, I thought it was too important to not mention with the context of our discussion today. vRNI can monitor data flows within your environment across virtual and physical topologies. It can help with understanding which applications and services are communicating with each other, and how vRNI can then help plan your security with recommendations on how to build your firewall rules based on the traffic flow detected. More than likely you'll also come across some unexpected traffic flows in your environment, I've heard of some interesting discoveries where applications were sending data to external endpoints that were not documented or expected!
Now, we might have a handle on how our applications are running and we've implemented micro-segmentation - high 5's all around! Unfortunately, there are still bad people out there trying to do bad things and there are viable attack vectors that can be used to achieve this goal. NSX offers VMware anti-virus and anti-malware partners a service platform to provide policy-based agent-less antivirus and anti-malware capabilities. New virtual machines (or existing virtual machines that went offline) are immediately protected with the most current antivirus signatures when they come online. It’s worth checking with your current provider to see if they offer this integration.
VMware also have a solution named AppDefense, which is a solution that allows you to learn and set the desired running state of a workload and then action a task if the workload drifts from that desired state. My colleague, Harry Offer, has gone in to detail about AppDefense in his post. Because NSX is a software defined solution, you can build in workflows to automatically react to virus detection or desired configuration drift to perform tasks like isolating the workload, removing the malware, cloning the machine, shutting down the machine, so on and so forth.
I won’t spend a lot of time on this as we’re planning to go in to more detail on this topic in another post, but the ability to automate these components of NSX, and more, is what really makes NSX a powerful product. One of my colleagues, Sam Bentley, is going to talk about NSX in a service provider context with vCD, making the features and functions of NSX available to consume through intuitive user interfaces or APIs in a multi-tenant environment. I’ll link back to that when it’s online. NSX provides a REST API which, in my experience is well documented and easily consumed.
As we learnt in the introduction, one of the goals that VMware had for NSX was for it to be not only multi-cloud aware, but provide the ability to be a centralised management plane you can use to secure your environment - which we’re continually seeing evolve to span multiple cloud environments. NSX-T has integration with platforms such as VMware vSphere, VMware Cloud on AWS, Azure, AWS. You’re able to centrally see the inventory across multiple cloud environments and build consistent policies and rules that span your business-critical applications - across multiple cloud environments. Think about how powerful that can be to tie in to your operational and automation frameworks.
With VMware's NSX solution you truly have the capabilities to holistically secure the SDDC using a centralised policy-driven platform. The best part is that for all of the components we spoke about in this post, you don't need to re-architect your network or make any major changes to existing routing and switching. While out of scope for our discussion today, there are some serious benefits in looking at how NSX can solve your problems in that space as well.
If you have some pain points in your environment and the topics we discussed in this post resonate with you, I challenge you to dig further in to understanding how VMware's NSX solution can help with solving your problems and contribute to your journey of securing the Software Defined Data Centre.