mailing list archives
Re: Switch ACL vs Firewall
From: Chris Blask <chris () blask org>
Date: Fri, 12 May 2006 15:17:58 -0400
At 11:35 AM 12/05/2006, Dale W. Carder wrote:
On May 7, 2006, at 6:48 PM, Grant Bourzikas wrote:
Their point is that Switch ACL's do the same thing as firewalls
Some (most?) switch ACL implementations suffer from either
1) no logging, 2) very limited logging, or 3) logging can
affect forwarding. You also may or may not get ACL hit
counters. You need to find out *exactly* how these boxes
will log, and balance that with how comfortable you are
There's the point.
The reason the vendor's argument is seducing is that security ideally isn't a bolt-on option but something intrinsic to
all components of the network.
o Where the vendor is correct is in that the activity of the switches themselves *is* citical to the security of the
network, regardless of what else you do. Which, in itself, is at worst banal parroting of people who know some basic
o Where the vendor's argument is self-interestedly vague and incomplete is in how this switch stuff will work with all
the other stuff on your network to make the whole thing more secure than it is already.
The answer to the second and more interesting point lies in richness of telemetry and telemetry management.
o What does this thing have to say about the stuff it does?
- Rich syslog/SNMP/flow/... data?
- Some sort of alerts using some sort of internal processing IDS/IPS/behavioral-anomaly-savant thingy that make the
box a more aware and useful member of the community?
o OK, assuming it's just full of spit and vinegar and can discern a new attack from the spin of a photon at a thousand
- once it has a bit of intelligence to share, what does it share it with?
- what does that gain you?
Having smart gear on the network is all good - switches that handle a bit of sensing or produce cognizant commentary on
what part they can see, well-written apps on good hosts that are less likely to screw up and are more likely to tell
you when they do - even dedicated firewall and other security appliances that do one job at one spot without getting
entangled in other complex processes. Depending on the situation on the ground, you make tactical and strategic
choices on which bits to deploy for what reasons, and many of those reasons are pragmatic best-guesses based more on
the realities of resources and the number of battles you can bear to fight simultaneously without having a brain
hemorrhage than the fine points debated between vendors.
All this stuff feeds a management model where you reach a critical mass of good telemetry that - with a bit of luck and
some good choices - can be more useful than any one piece of gear.
Maybe your switch vendor has really good stuff, but talk to them about how it is managed and how that integrates with
anything else. Unless that same vendor has a specific integrated managment offering (and even if they do), look around
for solutions that manage at least:
o Network info (topology, device/app states [versions/patches/configs/...], VA data,...)
- "What do you have?"
o Event info (syslog, traps, IDS, etc...)
- "What is it doing?"
Also, think about how a potential solution manages all this, both:
o In the present.
- how do you get greater value in making your network secure Right Now by managing all this data than by managing all
the devices individually?
o And in the past.
- how do you meet your needs for managing historical data? (Compliance is a good one for justifying funding these
days, as is Application Performance Management - though there are manifold benefits to security ops in being able to
see the past clearly, as well.)
You may or may not find that workable "Solutions" still have to be bolted together from more than one "solution".
In times of change, learners inherit the earth, while the learned find themselves equipped to deal with a world that no
- Eric Hoffer
chris () blask org
firewall-wizards mailing list
firewall-wizards () listserv icsalabs com