Re: Proxies, opensource and the general market: what's wrong with us?

[Magosányi Árpád <mag () magwas rulez org>]

On 2011-04-28 21:35, Tracy Reed wrote:
> On Thu, Apr 28, 2011 at 08:05:20AM +0200, Magosányi Árpád spake thusly:
>
> > Doing this they came out with a definition which goes against basic
> > security principles and empties the meaning of the word to the
> > extent which makes nearly pointless to have "firewalls".
> I think it would be hard to make the argument that it is pointless to
> have packet filters.

Yes, packet filters are needed to have basic domain separation. But that 
can be achieved in the routers as well.
Yes, separation of security controls from operation is a good practice, 
but you
 1. cannot do meaningful separation without net ops anyway
 2. can designate routers to that
Yes, there are still some possible minor functionality losses and other 
problems, but honestly I have seen complex firewall setups which would 
have been achieved better with some routers. Yes, this is not always the 
case, this is why I have used the word "nearly".

> How would defining a firewall as a packet filter go
> against basic security principles? You could then simply say you need a
> firewall (packet filter) AND these various other proxies and tools to
> secure your network. Perhaps we are not really doing ourselves a favor
> by overloading the word "firewall" to such an extent?

SPF technology is what goes against basic security principles, namely 
"default deny".
I don't like to argue about words, because they are just labels, and if 
there is an agreement on the meaning of the label, it is utterly 
unimportant how the label looks like.
This is why it would have been totally perfect to define "firewall" as 
packet filter at the beginning. (Only that firewalls were invented to do 
things which packet filters cannot.)
But if you redefine a word to mean much less than it have meant before, 
you will have a gap.
When the auditor recommends firewall to defend an application, it means 
"defend", which is much more than "separate mostly, but leave it wide 
open on the biggest attack vectors".


> > This led to a state of affairs where there is practically no
> > discussion about a lot of important questions of network perimeter
> > defense, because the majority of the "firewall" people are kept in a
> > darkness about the issue to the extent that they do not have the
> > background even to ask the right questions.
> What are some of the questions that you feel get overlooked?

Information flow control policy, labeling, the relationship of network 
perimeter defense to the enterprise data-, application-, and technical 
architecture.
You might have noticed that DoD have invented the notion(buzzword) of 
"enclave". I haven't seen much discussion even here on how that notion 
can be interpreted for various cases in the commercial world.

> > This means that even though those same vendors now would be in the
> > position to implement actually meaningful features, they do not do
> > it because they have conditioned their consumers to not think about
> > such things.
> I think they have simply failed to educate the customer of the value of
> those features. The vendors are constantly looking for ways to
> differentiate themselves in what has fast become a commodity market.
> Why doesn't the customer care? If I see two boxes on the shelf with the
> same price but one seems to offer more security than the other I'm going
> to buy that one. But the additional perceived security just isn't there
> for the customer.

My point is exactly that the lack of customer education from vendors is 
the direct result of the marketing campaign which redefined the meaning 
of firewall:
After saying so many times that whole classes of security functions 
doesn't belong to firewalls, it would be so inconsistent to state that 
firewalls should have those functions, that even customers in the US 
would have noticed that there is something wrong there.


> > When you see someone trying to correct this "firewall = packet
> > filter" nonsense, you actually see a vain attempt to correct these
> > mistakes. Because the first step is to meaningfully discuss
> > something is to have meaningful definitions.
> I understand and appreciate that a firewall can be more than just a
> packet filter. But to insist that a packet filter is not a firewall does
> not seem to accomplish anything because then you have to define exactly
> what a firewall really does require to be called a firewall which can
> get quite complicated.
>
> The idea that all of that functionality should be in one box or provided
> by one vendor bothers me also. It seems to violate the UNIX philosophy
> of do one thing and do it well.

You have a very valid point here. Do one thing and do it well. This is 
why a firewall doesn't do packet filtering or tcp session handling.
It leaves those functions to the operating system; using, defining and 
controlling them in the same way an application uses, defines and 
controls the underlying database.


_______________________________________________
firewall-wizards mailing list
firewall-wizards () listserv icsalabs com
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards