He writes about “the VLAN leaking myth” and how it encourages clients to utilize physically separate network infrastructure in the DMZ’s. Now first things first, I wouldn’t call VLAN leaking a myth. At one time it was a very real and serious vulnerability that was exploited by overflowing the capacity of the switch you were attacking, and causing it to “downgrade” from switch to a hub. Once this happened you now had access to previously protected devices, as well as having the ability to sniff data as it passed through the shared hub backplane.

As he mentions though, this is 8 years ago. Most switches have evolved to the point where backplanes far exceed the traffic that could ever be injected into their switchports. Even beyond backplane enhancements there are many ways to further firm up your security stance – Virtual Device Contexts, not using Layer 3 SVI’s on a DMZ VLAN, utilizing PVLANs, using port security, virtual routing instances, and many more. Of course, there are still many other attack vectors that still remain, but can be mitigated by utilizing features built into the majority of enterprise switches available today.

I think the real question is not “are VLANs safe in a DMZ”. The important question is have you mitigated the probability of compromise (the actual threat) to levels that are acceptable to your business. This question remains whether you have a standalone switch or not. So many times we hear about risk risk and more risk. But risk alone is meaningless in a business context. What is important is combining risk with likelihood. For that I like to use a simple table to come up with the true threat.

For example, as I drive to Fry’s there is the risk of me dying due to a car crash. The impact of me dying is very high (risk) however the likelihood of an accident is low, and furthermore I reduce (mitigate) the latent risk (threat) by wearing my seat belt. So all in all the threat of me dying on my way to Fry’s is pretty darn low.

In a business context this may be that I have public facing web servers and network devices in my DMZ. The impact of them being compromised is that my public image may be tarnished for a short time, and my end users may lose productivity if they are not able to VPN into work, or access the Internet while on premise. I mitigate this risk by using firewalls and both host and network based Intrusion Prevention Systems as well as implementing best security practices on my network and systems devices. The latent risk (threat) remaining is at a level that is acceptable to the business leaders, so the system is allowed.

One question that I have seen coming up more often as we move towards fully virtualized data centers is centered around commingling of virtual infrastructure. There are some hard questions which challenge some practices that we have held true over the years.

• Should you allow sharing of physical memory on a host virtual machine between an internal and DMZ server?
• Should you allow virtual infrastructure from multiple security zones to share a storage array or cluster of arrays?
• Should you allow multiple virtual switches in different security zones commingling on the same ESX or Hyper-V cluster?
• Should you allow virtual firewall and load balancing instances protecting internal and external zones to reside on the same hardware?
• Should you allow virtual routing instances from multiple zones to share a physical infrastructure?

In the past world of standalone systems, the additional cost of providing a wholly separate infrastructure for DMZ environments was relatively low. Each system generally had internal disk, or at most direct attached storage. Network devices themselves were scaled down to support one chassis one function. This fit quite neatly into the Enterprise Composite Network model that was quite common from 1999-2003.

Now, many data centers have moved to the Service Oriented Network Architecture (SONA). In this model the cost of a virtualized data center is primarily focused on foundation elements such as the virtual storage and virtual fabrics, virtualized network, and virtual systems elements. The cost of providing additional virtualized services off these elements is low, however the cost of duplicating the physical infrastructure is quite high on both the capital and operational levels. This is forcing the technical and executive leadership at many companies to take a long hard look at the true threats they are facing in previously physically separate security zones such as DMZ’s, Financial and other secure zones. In the end, they are having to decide whether the threat remaining after their security controls is worth duplicating hundreds of thousands of dollars worth of infrastructure or not.

These are hard questions, with really no single good answer. My gut feel is that over the next few years we will continue the move towards the fully virtualized data center where components such as memory, PCI-X buses, storage and network devices are even further decentralized. This will make the cost of duplicating the infrastructure more and more significant, causing consolidated data center (or compute) fabrics to be the norm. At this point the discussion will move away from securing zones by creating separate infrastructure, to providing end to end security, starting integrated application level security, maybe with TrustSec or a dirivative, all the way down to securing the data at rest on disk. For the time being however, the best we can do is sit down and do an honest appraisel of our security stances, mitigate what we can, and do our best to design data center architectures that provide the flexibility of implementing whatever choice the technical and business leaders agree on.Similar Posts:

• Moving towards a Green Data Center – Truth behind the hype
• Cisco’s Cloud Computing Offering
• About Colin McNamara
• Vote for my VMworld presentation – #3221 Built to fail (shameless pandering)
• Simplifying remote site security with Cisco’s new video surveillance modules on the ISR
• Interesting TechWise TV episode on virtualization

--Colin McNamara

Measuring and mitigating risk involved with sharing virtual infrastructure between DMZ and Internal environments

Cisco TrustSec starts at the edge by negotiating a secure link if both hosts support it (802.1ae). This is similar to wireless encryption schemes, where a secure handshake is established and the L2 path become impervious to sniffing. This is user configurable, and to my knowledge the asics available to support line rate encryption are currently only on the Nexus 7000 blades.

The next step is to start 802.1x negotiations. For the people not familiar with 802.1x, it is a way of passing username / password information from your computer up into the network infrastructure. Once this is completed, the switch can not only utilise tools like NAC to place you into the appropriate quarantine, or access vlans, but it also know knows your identity.

Now the “network” is aware of your identity, a new level of granular security control can be deployed across your infrastructure. These security policies can map into “user x can connect to webserver y” instead of being restricted by ip and port. This allows you to utilize true roles based administration similar to what you use in your Windows and Unix file systems, but now you can do this across the network.

How is this done ? I like to think of this as a mix between dscp and mpls tags. Which in a nutshell means that when traffic enters the network it is tagged with a small amount of additional “identity: information which is retained as it traverses the network. This information can be used to augment or completely replace your current ACL based security controls in a way that enables you to more effectively comply with complex regulatory environments such as PCI, SOX, GLBA and HPPA.

Over the past few years we have learned how to leverage intelligence in the the network by utilizing tools like QOS, MPLS VPN’s, and many others. Expect to add Cisco TrustSec to your quiver of tricks to address the ever growing compliance needs faced by today’s network designers.

Learn more about Cisco TrustSecSimilar Posts:

• Cisco Nexus 7000 DataCenter switch released – Welcome to DataCenter 3.0
• Encrypting your backup tapes with Cisco Storage Media Encryption (SME)
• Altor Virtual Network Security Analyzer (VNSA) integrated with Cisco’s Nexus 1000v for VMware
• Cisco releases Nexus 1000V virtual switch for VMware
• Zone based IOS firewalls
• Cisco Nexus 4000 Blade Switch

--Colin McNamara

Identity aware networking using Cisco TrustSec

I was wrong, the Green Data Center is not about saving baby seals, it is about saving cold hard cash. Saving the world is just a nice side benefit.

That being said, saving cold hard cash is a very important discussion item in any IT Operations group as they are normally seen as a cost center. For them, a penny saved is literally a penny earned. Not only can you save money by not paying for power, but PG&E will actually has a budget to pay you NOT to use their power. Most people here this and get a puzzled look on their face. “why would the power company, who makes money on power, not want me to buy it from them?” The answer is that Californians use more power then PG&E can produce at peak times. When they have to buy it from another state it can cost them 10 times or more then they charge us. This is the reason why PG&E will pay you to use less. Each penny they give to the consumer for saving a watt, saves them 4 pennies (80% return on investment).

Great, PG&E saves money by giving it to me. How do I get this cash? Well there are a couple ways to get this.

1. Incentives for new buying new energy efficient servers
2. Rebates for moving to virtualized servers
3. Rebates and incentives for moving to thin client desktop systems
4. Audit teams for cooling and power if your Data Center is 10,000 square feet or more
5. Incentives for airflow control systems
6. Incentives for high efficiency UPS and power distribution systems
7. Technical services for cooling system evaluation (PG&E funded)

That is a pretty comprehensive list of how to get money from the power company, but you can save even more money buy not using the power in the first place. Not unsurprisingly this starts with the server.

First thing you can do, is virtualize, virtualize, and virtualize some more. For most people this means VMware. For others this may mean Xen, or Microsofts virtualization product. Whatever flavor you chose, the key message is to consolidate from many servers to few. A server sitting “idle” still pulls 50% of its max current. Now, howe many servers do you have that are just sitting there? My guess is a large amount. By virtualizing these servers, you allow them to be stacked onto high performance server that can be run at a higher utilization. This lowers the over all power utilization for your DataCenter. Another side benefit is that ever watt that you remove from a server, you get another watt removed from your cooling.

These same virtualization techniques can also be applied to your network devices, which account for 6 to 12 percent of your datacenters power draw.

Ask yourself a few questions

• ” Do I need 4 different firewall clusters?”. It is likely that these are leftovers from organic growth, and that you could consolidate them into virtual firewalls on a more efficient chassis (ASA comes to mind).
• ” Do I need to maintain physically separate infrastructure?”. There are technologies like MPLS, VFR-Lite, Virtual Switching and more that allow you to consolidate onto a shared network infrastructure, taking a service provider approach to providing transport in your network.
• ” Am I running old inefficient gear?”. Power supplies have increased in efficiency over the last few years. There may be a good return on investment for you to upgrade.
• ” Can I consolidate into larger chassis?”. Ask the question, which is more efficient – a closet full of 3560′s or a 4507? There is efficiency in scaling out.

I hope that reading this has caused you to ask some questions, and maybe look at the larger impact of your network operations on both the ecosystem and your operational expenses. With these questions in hand, you might want to talk to PG&E and your Cisco / HP parter about going “Green” in the data center.Similar Posts:

• Is your network ready for Cloud Computing with Virtual Infrastructure 4?
• Cisco’s Cloud Computing Offering
• Usability features in Cisco’s Nexus 7000
• Cisco introduces the C-Series Rack Servers
• New features in VMware 3.1
• Simplifying remote site security with Cisco’s new video surveillance modules on the ISR

--Colin McNamara

Moving towards a Green Data Center – Truth behind the hype

For the engineering perspective on this, the CCDE is equivalent  to the CCIE. However, the CCDE is focused on design and architecture rather then implementation. Where the CCIE (R&S, Voice, Security, Service Provider, Storage) is focused on implementation, the CCDE is focused more on the pre-sales design and architecture efforts. I am personally looking forward to the lab being released, as it provides a certification to validate the skill set needed to be an sales engineer on Enterprise accounts, or to be a network architect at an Enterprise corporation.

It is funny how small a world it is. Eplus (the company I work for) CEO – Phil Norton was quoted on Cisco’s press release -

“Certifications provide a stamp of approval that validates the quality of our organization’s employees,” said Phil Norton, chairman, CEO and president of ePlus. “The CCDE isn’t about operations; it’s about recognizing the value of network designers and honoring their core skills that provide a real value to our business and our customers.”

My gut feel when I first got invited to the CCDE beta program was that this will become a requirement for the Channel. I think Phil’s statement cements that gut feel into a reality. Obtaining a CCDE will become similar to the CCIE – a check box that you must attain to work with the top VAR’s out there. This makes me extremely grateful that I was lucky enough to be invited into the beta group to be allowed first crack at this gem of a certification.Similar Posts:

• It’s on like Donkey Kong – CCDE practical registration is open
• CCDE Practical – Beta candidate deadline August 1 2008
• Cisco Certified Architect – Board examination above the CCIE and CCDE
• Are you a kick ass engineer looking to grow?
• Challenges integrating VMware into Cisco networks
• About Colin McNamara

--Colin McNamara

Cisco Certified Design Expert – CCDE – officially released by Cisco

Colin is best known for providing designs that incorporate disparate technologies under a shared virtualized infrastructure. He is a proponent of both network virtualization and the utilization of service provider technologies inside enterprise networks to support the security delivery of Voice, Video, Storage and Real Time Application traffic over shared network infrastructure.

He resides in the San Ramon (San Francisco Bay Area) , California with his Wife and two kids. And is active in multiple boards and organizations, including -

• Cisco Partner Technology Advisory Board
• Consortium of Internet Technology Experts

He can be contacted via information found on his CCIE Resume page . by contacting him via Linkedin or at colin@2cups.com

Similar Posts:

• Colin has left ePlus Technology
• Cool new features in 12.4(15)T
• Are you a kick ass engineer looking to grow?
• Resume – Colin McNamara, CCIE #18233
• I’ll be at Cisco Live 2008 (networkers) in Orlando all week
• Cisco NX-OS 4.0 | Next Generation Internet Operating System

--Colin McNamara

About Colin McNamara