Re: Firewall RISKS

["Stephen P. Berry" <spb () incyte com>]

-----BEGIN PGP SIGNED MESSAGE-----


In message <609B8FA424F9D111A91A00805FD71EE2CF4714@DSLEXXCH3>, "Sheldrake, Kevi
n" writes:

> My point was that the software you run is likely to contain bugs.  You
> claim this is 'bogus' without any argument.  Looking at development
> cycles or the release of 'patches' following product releases should
> convince you that almost all software contains bugs.  It would be
> foolish to think otherwise.

Okay.  Even if we accept this proposition as true, it doesn't
support your earlier statement.

If we accept that the majority of software contains bugs, then that
implies that if we choose a piece of software at random, it is likely
to contain bugs.  I am not talking about choosing software at random.
Neither are you.  

You seem to believe that having the word `firewall' associated with
the piece of software enhances the likelihood if it being (either
completely or comparatively) bug-free.  My contention is that this
is not necessarily a good heuristic, or at least it is not necessarily
better than all heuristics for choosing application-level daemons.

At any rate, we both seem to believe that there are ways of
improving the odds.  Put more formally, we appear to agree
that, given that the chance of a randomly-selected piece
of software containing bugs is p(b), there exists some selection
criteria q such that p(b|q) < p(b).  Therefore your arguments about
the very high value of p(b) are irrelevant---because we're really
concerned about p(b|q).  All we're really arguing about here, then,
is the character of the selection scheme q.  Hence my rejection
of your `statistically likely' argument.


> Maybe you did not understand my original statement.  I was not reducing
> computer security to a single statisitc, I was merely pointing out that
> software is likely to contain bugs, that testing helps find bugs, and that
> targetted testing and prolonged testing tends to find more bugs of the
> targetted nature.  

I understood what you said.  I just don't think that it only applies
to firewalls, or even preferentially to firewalls.

You seem to be asserting that there's some sort of greater rigour
associated with firewall development (in general), than there is
with development of -the best- application-level daemons.  You've
complained that I haven't been supplying enough evidence to support
my opinions.  Care to support yours?

Note that I haven't been arguing that in the general case application-level
daemons should be trusted (apply appropriate caveats to the word `trust'
here) as much as firewalls.  I'm saying that there are specific
application-level daemons which can be configured such that putting
them behind a firewall isn't always necessary.  You seem to have based your
argument against this on two things:  that firewalls are inherently better
than application-level daemons (because of how they are developed);  and
that the firewall is doing something that the application-level daemon
can't do, but which is -necessary- to enforcement of a sane security
policy.


> Estimations of probability can be drawn from historical
> data.

They -can- be.  That doesn't mean that they'll be good estimates.

If you're actually interested, I can bore you with lots of details specific
to network security---I've been fiddling around quite a bit with
induction-based heuristic generation as a tool for traffic analysis.  I doubt
that the other list members would be interested, however, so perhaps we
should adjourn to out-of-band email.


> > > Making the source
> > > available does not make software any more likely to work.  It is all to
> > > do with the evironment within which the software was developed and the
> > > testing regime.

> > The guilty flee when no man persueth.  I stipulated the point.

> What does the above line mean?  I'm not in the business to flame, but I feel
> that Stephen P. Berry is not putting up any argument to justify his views.
> Here is a dictionary definition of stipulate:
> stipulate1 // v.tr. 
> 1 demand or specify as part of a bargain or agreement.
> 2 (foll. by for) mention or insist upon as an essential condition.
> 3 (as stipulated adj.) laid down in the terms of an agreement.

Sorry you had trouble with my diction.  In an argument, if one of
the interlocutors stipulates a point, this means that he or she is
willing to conditionally concede the point for the purposes of
moving the discussion on to more important matters.  It generally
means that the person doing the stipulating has reservations about
the issue, but believes it isn't terribly germane to the larger
issue under debate.

In this case, I don't think the pros and cons of open source development
are really that important in our discussion as to whether or not
firewalls are absolutely necessary for implementing sane security policy.
So I stipulated the point.


> > An interesting case can be made for independent
> > reimplimentations
> > of application-level protocols as a security mechanism.  To the best
> > of my knowledge, this aspect hasn't even been alluded to in this
> > discussion by anyone other than myself.

> Let's see, reimplementations of protocols.  Sounds like focused (or
> targetted) development concentrating on security.  Sounds good,
> but who's going to do it?  A lot of people are implementing security
> today and tomorrow; not in six months' time.  (And in sixth months'
> time, will this have been completed?  I think not.)

And why is this redesign work when it goes into a firewall product
_prima facie_ going to be more effective than if it does into a
non-firewall product?

I don't follow anything you say after `sounds good' above.  Or rather,
I understand the words and even understand (and more or less agree)
with the sentiment.  I'm just not sure how they apply to your argument.


> > I'd be interested in seeing the firewall absolutists attempt to make
> > a case for the necessity of firewalls based on specifics of intrusion
> > prevention, containment, failure mode control, u.s.w., rather than
> > (as has been generally done to this point) vigorous assertion.

> I've put up a simple argument for why firewalls are better than not-
> firewalls.  Until this is shown to be incorrect, I do not see the point.

Could you reiterate this argument?  I seem to have missed it.  You're
not talking about the developmental rigour presumption, are you?


> > Erm...are you seriously contesting my contention that things don't
> > always work the way they were designed to work?  Pardon me if I observe
> > that this strikes me as slightly disingenuous.

> No, I am pointing out that you are not providing any evidence.  Phrases like
> 'I'm not sure', 'I'm pretty sure', and 'anyone familiar' do not provide
> weight to your case.

This is just plain silly.  You're asking me to supply evidence that
things don't always work as designed?  Perhaps you should take a gander
at the `Galloping Gertie' discussion, next thread over.


> > I said that servers exposed to the outside world should be `secured
> > appropriately'.  You seemed (and, indeed, seem) to find the idea somewhat
> > ludicrous.  I was merely explaining what I meant.  Part of what
> > I mean when I say that a server should be `secured appropriately'
> > is that it should, if possible, be running exposed application-level
> > daemons in a chroot.

> I find the word 'appropriately' ludicrous.  You have not stated anyway of
> distinguishing between appropriately secured and inappropriately secured
> (or appropriately insecured).

Depends on what the machine is going to be used for, how much the data
is worth, what a compromise would cost, u.s.w., u.s.w., u.s.w.  I.e.,
the usual litany of risk analysis.  My use of `secured appropriately' is
my acknowledgement that security is always implementation-specific.  I
can think of comparatively few things which would universally be
a part of insuring a machine was `appropriately secured'[1].

Put another way, `secure' is always context-dependant.  `Appropriately'
means congruent with the particular context in question.  If you're
objecting that this isn't a closed-form solution, I sympathise.  If you
can come up with a closed-form solution for deciding what appropriate
security is for all implementations, I'd like to hear it.


> I was pointing out that chroot may not really
> be providing the security that you believe it is.  Simple checklist: has the
> particular implementation been certified (ie to E3)?  is it running on an
> operating system that has been certified?  If not, where does your faith
> in chroot come from?

It isn't faith.

Running a daemon in a chroot is just a tool or a component, like a firewall
is.  When I'm putting together a security infrastructure, I'll use different
tools and components.  You're right in point out that using chroot(8)
(or Venema's chrootuid(1)) isn't a form of magical protection.  Nothing
is.

In any case, I don't take ITSEC certifications much more seriously
than I take TCSEC certifications.  A B1 or E3 is nice to throw into
the marketing flack, but it generally isn't particularly meaningful in
establishing the suitability of a particular implementation for a
particular task.  For example, Firewall-1 on NT (configured
appropriately[2]) is E3 certified.  This doesn't mean that it
is going to help protect your DNS server against the lastest
exploit du jour.

Things like the Common Criteria help winnow out some of the most
glaring idiocy in implementations, but that's about the size of it.


> > If you're running an application gateway then you're assuming that
> > your proxy is better than the daemon itself.  As I said, whether or
> > not this is a good assumption will depend on the application and the
> > proxy in question.  You seem to be asserting that this will -always-
> > be true, as a result of some belief about the rigour of firewall design
> > and implimentation.  I do not find this a particularly compelling
> > argument.

> I am stating that the proxy should be more secure than the daemon
> itself due to the design, implementation, and testing processes.  Obviously
> there will be cases where this is not true.  

Then, obviously, there will be cases where the firewall won't be buying
you anything.  This, too, appears to be a concession of the point.


I noticed you've now explicitly discussed application gateways but haven't
made any mention of packet filters.  Should I take this to mean that
your argument is not for firewalls in general, but application gateways
in particular?  If this is the case, then by your standards a hefty
portion of the current firewall market is lacking a `necessary' component.

If you are not intending to narrow the scope of your argument, then
I'd like to see your arguments for what essential purpose a packet
filter serves in, for example, protecting a hardened machine running
bind 8.x .


> > Beyond that, it's not even clear that even if you're running all inbound
> > data through a proxy that it'll help the daemon any in the case of an
> > attempted exploit.

> I assume that the proxies should do protocol analysis which should
> distinguish (generally) between attempted exploits and genuine requests.

So should the application-level daemon.


It actually appears that you've conceded most of the important points
I've been arguing.  What's interesting is that even given that you're
willing to acknowledge the individual points, you seem to reject
the conclusion to which they lead.

Let me reiterate (again) that I'm not suggesting that firewalls are
bad or that they are always useless or anything of the sort.  In fact
I have argued that there are niches in which firewalls will remain
necessary for the foreseeable future.  

I'm just arguing that firewalls are not necessary for all security
topologies.  In the latter part of the discussion, I've been confining
myself to a posited `real world' that doesn't include dialup ISPs or
requirements stringent enough to specify air gaps.  Even given that,
I haven't seen any compelling arguments from the opposition.  There
have been some fairly cogent arguments for why firewalls are neat
in general, but that's not what I'm arguing.






- -Steve

- -----
1     I do think, however, that there are many things that -generally-
      help to secure -most- infrastructures.  I.e., firewalls.  The crux of
      our dispute appears to be that you believe this general case to
      be universally true, and I do not.
      Note that to disprove an absolute, one need only supply a single
      counterexample.  Methods for proving the absolute vary, but you
      do not appear to be pursuing any of them.
2     `Appropriately' here, incidentally, means `in accordance with the
      ITSEC certification report'.


-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBN3F/vSrw2ePTkM9BAQFKGwQAn6ZJrMc4fl5COjO0/JhCa1nt69vd5yjR
W2rduPiQRgEf+/nflAnmJyKDxxySr4LCiomoB4a0pyHUNVRioe+eZZ2ArIHA2is+
Ykd9FjnHbpdYdaSNYuBFHt/OxnCfKxUZP+1TwI1tXoJKVzQouu4IrmQN5Y/tYv5f
Ic9UcvQlkWA=
=Yl4B
-----END PGP SIGNATURE-----