Cisco Blogs

MegaTrends: The Need for Securing Data Center Traffic

- April 26, 2013 - 0 Comments

Data Centres are evolving rapidly, in response to the many industry IT Megatrends we have previously discussed. Services and applications are increasingly being delivered from very large data centres and, increasingly, from hybrid and public clouds too.

Specifically, a good example of services being delivered from data centres is Hosted Desktops. I discussed in my last post how technologies such as TrustSec can help secure VXI/VDI deployments. VXI is a good example of a service originally delivered only from private data centres, now being delivered As A Service as well.

Video is (and will be) increasingly delivered from data centers as a service. Infrastructure services (servers/VM, storage…) are also delivered internally more and more through Private Clouds.

Consequently, securing those environments is now perceived by our customers CTOs and architects, as the biggest barrier to adopting clouds on a much larger scale.

We will therefore look at how TrustSec can pervasively help secure all data centre traffic.

I have asked Dave Berry, Cisco EMEAR Security Architect, to answer a few questions for me. Dave has held several positions at Cisco where he assisted many very large Enterprises customers in transforming their IT securely.

Q. Dave, how do you see Data Centre security evolving?

“The modern Data Centre is a dynamic environment, with rapid changes to where services are instantiated and then moved.  In addition, the on-going consolidation of servers using virtualisation increases the density of Virtual Machines, this challenges traditional approaches to maintaining separation between services for different security levels, segmentation in general and access policy control.

Q. How has this been done traditionally?

Traditionally, the separation of services has been implemented by using VLANs, PVLANs and other similar technologies, combined with the deployment of Access Control Lists on switches and/or by using a Stateful Firewalls to control the flow of traffic.  Supporting this on a very large scale can quickly become too complex and expensive, both because of requirement to insert control points between the different security levels/layers but also due to the complexity of managing this dynamic environment.  The task has become so huge, that it can lead to misconfiguration and security vulnerabilities due to these configuration errors. Perhaps even worse, recent studies have suggested, that because it has become so challenging, some companies are failing to properly secure their virtual server environments to the same level they do their physical servers.

Q. I know you have been involved recently on really big Data Centre security architectures, using TrustSec?

Using TrustSec Security Group Tagging, the problems above can be dramatically simplified by using the network to identify which “group” the data packets belong to and then “Tagging” all of the packets from those sources with the appropriate Group Tag.  In a similar manner, where the packet is delivered to the destination (either a Physical or Virtual Server port) the destination group is also identified and access is allowed or denied by the network according to security policy.

Q. Ok, got it Dave. Could you describe that further for us?

You can see this more clearly by referencing the diagram below.  For example, a data packet coming from the Developer Zone can only reach other devices in the same zone or selected servers in the Storage Zone according to the Security Access Policy.

EMarin SG-ACL Server Segmentation

Using the same principles for all Zones, it becomes possible to control the flow of traffic inside the Data Centre, by assigning Security Group Tags to devices within each Zone.  The actual control is done using a simple control matrix, reducing or minimizing the need for using expensive separation technologies.  The control function can be done on the ASA Firewall (v9.0.1) or on TrustSec -enabled switches like the Nexus 7000, 5500 and 2000. The SGT assignment functions are provided in many Cisco products, but I would highlight one as an example of DC Security automation; the Nexus 1000V. With the Nexus 1000V, the SGT assigned to a virtual server stays with that VM as and when it is moved in the virtualised infrastructure, so live migration of virtual servers need not require security policy adds, moves and changes

Q. Feedback I have personally received is that Trustsec might be perceived as complex. Seems like it is quite the opposite, doesn’t?

Deploying TrustSec enabled devices in the Data Centre can dramatically simplify and reduce the cost of separating resources.  By using TrustSec Group Tagging, the job of controlling and separating the data traffic can be moved to the edges of the network, reducing the need for inserting control mechanisms into the path of the traffic.

In our efforts to ensure that the technology is easy to deploy and works as intended, we have just completed solution-level testing of our TrustSec v3.0 solution. This work is undertaken to validate operation of the advanced DC TrustSec features referred to in this blog entry on the Nexus 7000, 5500, 2000 and 1000v, working with the TrustSec features across the BN portfolio, including Catalyst switches, Wireless LAN Controllers, ISR and ASR 1000 routers. Please look for forthcoming docs on the TrustSec 3.0 solution at the following page.

Sharing intelligent ‘context’ information from one part of the Enterprise with another using TrustSec can significantly reduce the operational effort and time involved in implementing, managing and auditing security rules; it can also help address new challenges, such as controlled access to critical DC applications for BYOD users

Thanks Dave.

Please tell us if that is has been useful.

As I already said in my previous blog, Megatrends bring their own set of security challenges. Solving them architecturally using technologies that can be pervasively deployed throughout the network is in my opinion the only sustainable and cost effective way.


In an effort to keep conversations fresh, Cisco Blogs closes comments after 60 days. Please visit the Cisco Blogs hub page for the latest content.