Real World Example: Deploying VMware NSX in the Financial Sector
I recently finished up a project implementing VMware’s NSX and wanted to take a minute to recap my experience. The client I worked with provides call center services in the financial sector. They have to be able to securely access systems that have the ability to see credit card information along with other personal, sensitive information.
The customer is building out new facilities to host their primary, PCI-related, applications. In this environment, they have to be able to provide the highest levels of security, while providing high-performing networking services. To achieve the necessary requirements, they have had to purchase new infrastructure: blade center systems, networking infrastructure (Nexus 5672s, Nexus 6000s, Nexus 7710s, Juniper SRXs, F5 load balancers, etc.), Software licensing, among other things.
They came across the need to purchase additional pairs of F5 load balancers but were up against their budget. When this happened, the Director / VP in charge of the project evaluated VMware’s NSX technology. After some initial discussions, he realized that NSX could not only provide the type of security the environment needed to drive higher efficiencies but could also provide some of the general networking services he was looking for.
Previous network designs included the need for complete isolation of some workloads and, to achieve this, the design called for trusted traffic to traverse a separate pair of distribution/access layer switches to reach external networks. This design also made it necessary to acquire separate F5 load balancers, as specific traffic was not allowed to commingle on the same physical infrastructure due to the way the security team wanted to steer trusted and untrusted traffic. This meant that the team was required to purchase twice the hardware; separate Nexus 6000s and separate F5 load balancers.
Because of the NSX Distributed Firewall capabilities, security teams have the ability to place required rules and policies closer to applications than has previously been achievable. Because of this, networking designs changed and allowed for infrastructure requirements previously deemed necessary to be alleviated. The ability to stop untrusted traffic before it ever reaches a logical or physical wire gave the team the opportunity to converge more of their networking equipment; eliminating the need to utilize separate Nexus 6000s. In addition, with the NSX Edge Services Gateway having the ability to provide network load-balancing, they were no longer required to purchase additional physical equipment to provide this service. With the budget they put towards NSX licensing, they were able to get all the security and load-balancing services they were looking for and also put money back into their budget.
The Engagement:
Over the span of approximately one month, the security team, networking team, server/virtualization team, and auditing team worked together to design what the NSX solution needed to achieve and how it would be implemented. I believe this to be an important aspect of NSX projects because of the misconception that the server/virtualization teams are trying to take over everything. Without each team, this project would have been a disaster.
As requirements were put forth, we built out NSX in building blocks. First, we identified that we would utilize VXLAN as a means to achieve desired efficiencies: eliminating VLAN sprawl, segregating trusted traffic in the logical, software layer, and allowing Disaster Recovery designs to become easier when using the same IP address space. Once networks and routing were implemented, we were able to test connectivity from various sites, while achieving all requirements by the security team. The next item was implementing NSX security. This item required new ways of thinking for most teams. With VMware NSX, customers have the ability to manage security based on vCenter objects, which provides more flexibility. We had to walk through what the contents of each application were, what types of communications were necessary, and what types of policies were required, and, in identifying these items, we were able to build dynamic and static Security Groups. We then built Security Policies (some basic that could apply to a majority of similar applications, some application-specific) and were able to re-use these policies against various Security Groups, speeding the deployment of application security. We applied weights to these policies to ensure application-specific policies took precedence over the generic. In addition to Netflow, we applied “Flow Monitoring” as a means for the networking and security teams to monitor traffic patterns within the NSX environment.
All in all, this was a very successful project. Our client can now better secure their internal applications as well as better secure sensitive customer data.
Remember, NSX can be mislabeled as a server team product, however, the network team and security team need to know how it works and need to be able to implement it.
Are you interested in learning more about how GreenPages can help with similar projects? Reach out to us!
