Colin McNamara - CCIE 18233 , VCP, EMCIE, NCDA, GEEK » threat

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

colinmcnamara — Tue, 09 Sep 2008 20:36:57 +0000

Ivan Pepelnjak over at IOS Hints and Tricks wrote a post about DMZ VLAN leaking that got me thinking.

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:

--Colin McNamara

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

Tags: blog, breach, business context, C, CISCO, Colin, compromise, Data Center, DESIGN, device contexts, enhancements, FCOE, HP, hyper-v, Instances, linux, NDA, Network, network infrastructure, Nexus 5020, passed, Pic, risk risk, san, security, storage, switch, threat, TrustSec, virtual device, virtualization, vlan, vmware, vulnerability

Simplifying remote site security with Cisco’s new video surveillance modules on the ISR

colinmcnamara — Wed, 11 Jun 2008 00:31:13 +0000

One giant pain I have always faced when working with high security environments is dealing with surveillance systems. They are a necessary and required part of your security infrastructure. However they just never seem to integrate as well as your network, storage, or server devices.

When I work with data center infrastructure I expect the following – clean, remotely manageable, secure devices that runs on the same power and similar cabling, and everything can have a 24x7x4 support contract for hardware replacement. For the most part, you get this when dealing with Cisco, HP, Sun and similar manufacturers.

More often then not (with a few very cool exceptions), when I run into video surveillance infrastructure the video management infrastructure runs on some random third tier manufactured server. It never fails that the video management software is on Windows (normally XP or win2k). I have even seen some systems where the vendor requires you to have a session open to run the software.

And then when you get to the encoders themselves, it never fails. You have two choices.

The Uber package that can run a Casino, Identify and track dust mites , and if you point it at space, determine if there is life on mars.
Individual dinky encoders that run one or two camera’s each. They have limited encoding choices, limited camera control, no remote management, and normally run on 110 volt system that require different power distribution then the 220 that is common in systems today.

Cisco’s answer to this mess

Cisco has released both a video management solution, as well as a video encoding solution in a network module form factor for the Integrated Services Router (ISR).

The first part of this system, the Video Management and Storage System (VMSS) module fills the following roles -

Management of multiple video streams from one interface, including IP cameras, 3rd party encoders, and streams from Cisco’s video encoding module
Streaming of live and archived footage through a web browser interface
This one is pretty cool – The module can mount external storage via iSCSI. So, in addition to its 160 gig internal drive, you can mount a filer and utilize external storage to scale the system.
“fast forward” to events, as well as notify security and other personnel through SMS and email

The second part of the system (the module on the left in the picture above) is the Analog Video Gateway Network Module (EV-IPVS-16A). It has a couple functions -

It can take up to 16 analogue video inputs and encode them with MJPEG or MPEG4 codecs
You can use the first two ports to output video to a external monitors
If you are using MPEG4, it can be used as a motion detector (handy for fast forwarding to important events, or triggering alerts)
It can control pan and tilt cameras. This is good for pointing the camera at the janitor unplugging your servers each night to vacuum
You can configure analogue contacts as an alarm. This can be bound to a door switch, or even temperature and water level monitors in a remote data center. This one will be very handy.

The third part of this solution is Cisco’s Video Surveillance Operations Manager. It manages, archives, displays and distributes the content that was created and collected on the two previous modules. You would use this if you had many branches to aggregate, or needed to staff a video wall (e.g. casino gaming commission operations). Now, you can run each of these components individually. Buy run together as a whole, Cisco has an enterprise class security solution.

Want to learn more ?

Branch office security page on cisco.com http://www.cisco.com/en/US/products/ps9671/prod_module_series_home.html

Cisco’s product page for the Video Managment Module – http://www.cisco.com/en/US/prod/collateral/modules/ps9671/data_sheet_c78_462225.htmlSimilar Posts:

--Colin McNamara

Simplifying remote site security with Cisco’s new video surveillance modules on the ISR

Tags: archived footage, C, camera control, CCIE, center infrastructure, CISCO, cisco secure, Colin, Data Center, dust mites, encoders, Gadget, hardware replacement, HP, ip cameras, isr, legal, life on mars, linux, management infrastructure, mars, mitiigation, Network, network storage, Pic, Power, Router, security, security environments, security infrastructure, storage, storage system, support contract, surveillance systems, switch, Technology, threat, two choices, video encoding, video management, video streams, video surveillance

Zone based IOS firewalls

colinmcnamara — Tue, 16 Oct 2007 01:19:00 +0000

Zone based IOS firewalls

Cisco has finally included zone based firewalling in the IOS firewall feature set. The configuration guide can be found here -

Zone Based Firewall Design and Configuration Guide

The things that really got me interested are -

1. It is VRF aware (works well with network virtualization strategies)
2. No more CBAC’s
3. Policing built into firewalling classes
4. Content inspection including HTTP,P2P, and Instant Messenger

I think the biggest plus for this release is that IOS firewalls are finally following the general trend of zone based firewalling. By moving this way, configuration errors resulting in lax controls are likely to be minimized.

Excerpts from the documentation -

Cisco IOS Software Release 12.4(6)T introduced a new configuration model for the Cisco IOS Firewall feature set. This new configuration model offers intuitive policies for multiple-interface routers, increased granularity of firewall policy application, and a default deny-all policy that prohibits traffic between firewall zones until an explicit policy is applied to allow desirable traffic.

Nearly all firewall features implemented prior to Cisco IOS Software Release 12.4(6)T are supported in the new zone-based policy inspection interface; supported features are as follows:

•Stateful packet inspection

•Application inspection

–HTTP

–Post Office Protocol (POP3), Internet Mail Access Protocol (IMAP), Simple Mail Transfer Protocol/Enhanced Simple Mail Transfer Protocol (SMTP/ESMTP)

–Sun RPC

•VRF-aware Cisco IOS Firewall

•URL filtering

•Denial-of-service (DoS) mitigation

Zone-based policy firewall generally improves Cisco IOS performance for most firewall inspection activities.

The only Cisco IOS Firewall features that are not supported in zone-based policy firewall in Cisco IOS Software Release 12.4(6)T are as follows:

•Authentication proxy

•Stateful firewall failover

•Unified firewall MIB

Zone-based policy firewall completely changes the way you configure a Cisco IOS Firewall.

The first major change to the firewall configuration is the introduction of zone-based configuration. Cisco IOS Firewall is the first Cisco IOS Software threat defense feature to implement a zone configuration model. Other features might adopt the zone model over time. The classical Cisco IOS Firewall stateful inspection/context-based access control (CBAC) interface-based configuration model employing the ip inspect command set will be maintained for a period of time, but few, if any, new features will be configurable with the classical command-line interface (CLI). Zone-policy firewall does not use the stateful inspection/CBAC commands. The two configuration models can be used concurrently on routers but not combined on interfaces; an interface cannot be configured as a security zone member as well as being configured for ip inspect simultaneously.

Zones establish the security borders of your network. A zone defines a boundary where traffic is subjected to policy restrictions as it crosses to another region of your network. Zone-Policy Firewall’s default policy between zones is to deny all. If no policy is explicitly configured, all traffic moving between zones is blocked. This is a significant departure from stateful inspection’s model, in which traffic was implicitly allowed unless it was explicitly blocked with an access control list (ACL).

The second major change is the introduction of a new configuration policy language known as CPL. Users familiar with the Cisco IOS Software Modular quality-of-service (QoS) CLI (MQC) might recognize the format being similar to QoS’s use of class maps to specify which traffic will be affected by the action applied in a policy map.

--Colin McNamara

Zone based IOS firewalls

Tags: C, CCIE, CISCO, Colin, DESIGN, error, NDA, Network, packet, Router, security, threat, virtualization

Book Review – Security Threat Mitigation and Response: Understanding Cisco Security MARS

colinmcnamara — Wed, 15 Nov 2006 01:35:00 +0000

Book Review – Security Threat Mitigation and Response: Understanding Cisco Security MARS

Security Threat Mitigation and Response: Understanding Cisco Security MARS
by Dale Tesch, Greg Abelar
Publisher: Cisco Press
Pub Date: September 28, 2006
Print ISBN-10: 1-58705-260-1
Print ISBN-13: 978-1-58705-260-6
Pages: 408

This book had so much potential to be a great. Sadly it turned out to be an overgrown technical manual. The author does try to lighten things up by interspersing real world technical details throughout the book, however he could have just written a “hacks” style book with that material and been much better off.

This book is organized into four major divisions. The first, Security threat identification and response challenge reviews basic security theory and response. A network engineer breaking into security may find this interesting. Anyone else can just skip over this chapter.

I actually found the second, CS-MARS theory and operation to be the most useful. The author laid out a pretty good flowchart of the designing process used to process alerts. He also hinted out the back end architecture supporting the device.

The third section, CS-MARS operation was just blatantly lifted from the users guide. The only difference is that the online users guide is organized a little more clearly. I recommend skipping this chapter and going straight to the on-line documentation, you will be much happier.

The fourth section, CS-MARS in action had great potential, however the author just stuck in some really salesy usage scenarios. I can’t reinforce this enough – This needs to be updated. I have been to customer talks where users presented how the MARS box has made their life easier in many ways. The stories presented here do a disservice to the product, and do not highlight the core differentiators that this product offers.

Would I recommend this book? Yes and No. I would recommend that entry level engineers with no security experience, and business users pick this up. Other then that, log onto CCO and just read through the docs. You will learn more in less time. And as a plus, you will have $50 sitting in your wallet still.

http://www.2cups.com

“The difficult we do immediately, the impossible just takes a little longer.”

Tags: blog, C, CCIE, CISCO, cisco secure, Colin, DESIGN, mars, mitiigation, Network, Pic, security, threat