Re: Firewall RISKS

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

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


In message <s766103c.007 () sbscorp com>, "MIKE SHAW" writes:

> > Okay.  Stipulated.  Scribbling a firewall into the network diagram isn't
> > going to change any of this.

> No.  That's why I said effectively deploying one will decrease your
> vulnerabilities further, not plugging it in and expecting all your
> worries to disappear.

Realising the above (i.e., a firewall dropped into the mix doesn't make
the infrastructure secure), what steps would you still consider
necessary to reach a stage of acceptable security?  What steps beyond
that would be necessary before the firewall became (in your eyes)
superfluous, and why do you consider those steps impossible or impractical
(in all or in an overwhelming majority of situations)?

As extra credit, what is the failure mode in the scenario you present,
how do you control it, and how does this compare to the firewall-less
scenario?

If you mull over nothing else in this message, ponder the above.  In
fact, stop reading now and figure out answers to the above before
going on.  If you don't have a handle on these issues, the rest will
be pretty much pointless.


> Just because you can come up
> with some obscure and specialized example doesn't mean that the 
> importance is not demonstrable.

Dialup internet access is an `obscure' example?  Setups involving
dialup to ISPs constitute less that one percent of all topologies?
That all aside, and also ignoring that home dialup use is probably
one of the functions with the -least- specialised topology, I would
still point out that (from this end at least) observing that a security
setup is `specialized' is in no way a Bad Thing.


> > Stated more generally, the truth of `foo enhances bar' does not
> > entail `foo is essential to bar'.

> Depends on the level of enhancement and your definition of essential.

No, it doesn't[1].  It does appear, however, that we have vastly different
ideas of how the language works.  The more interesting distinction, though,
appears to be that you believe that having a firewall is of paramount,
unequivocal and and universal importance.

We seem to have made some progress, though, as you originally appeared to
be tacitly suggesting (if not outright asserting) that a firewall was
necessary for -any- topology.  You now appear to be willing to admit
that there are -some- instances where a firewall isn't `essential'.

I would tend to believe that it would be most profitable to examine
those border cases (in your schema) to figure out what's interesting
about them and approach the issue from that direction, but you seem to
be more interested in the opposite approach.  That's fine, but it does
tend to make for a more difficult rhetorical position---i.e., your
original statement, which was falsifiable by a single counterexample.
Which leads us to:


> These are security schemes and would be included in the word 'any'.
> So let me define 'any situation' where a firewall would be applicable:

Ah!  The `it depends what the word "is" is' argument.  Okay.  I'll
play along.


> 1) uses a network LAN/WAN with TCP/IP anywhere in the architecture.
> 2) has machines present in the architecture with OS' that are difficult or 
>   or impossible to completely lock down (which is nearly all, especially 
>   with managers reading every day about how great NT is)
> 3) requires that a port or ports be open for functionality.
> 4) has actual services running on hosts/servers.
> 5) has end-users whose primary job does not involve network security (even if 
>   it is a secondary consideration).
> 6) has an interest in protecting information present in system(s) on that
>   network or would be harmed by an abuse of that network.
> 7) has a budget.
> This is the situation in the vast majority of networks now and over the
> next 5 or so years.

Okay.  Stipulated.  I'll even forego comment on the tacit question-begging
in some of the above items (most noticeably the second and the fifth[2]).
Am I allowed to specify policy, or would you care to enumerate items of
a `99%' of the `real world' policy?  Presumably the sixth item isn't
intended to be one in and of itself.

Trivially, I'd say a workable no-firewall setup given the above constraints
would be to simply multihome whatever servers need to be exposed to
both the internet and the internal network (i.e., bind 8.x, a squid server,
u.s.w.).  Secure them appropriately.  Have all your desktop toys talk to the
internal interfaces of these boxen.

Note that I'm not suggesting that this sort of solution is optimal for
all cases.  I'm just trying to get you to see that, even stipulating
your `real world' conditions, a viable security policy can be implimented
without inclusion of a firewall.  And I'm not even going to go off on
the subject of solving protocol design problems with firewalls to do it.


> For all practical purposes this is the 'real world' for
> anyone giving security advice.

No.  But I assume the fact that I'm disagreeing has something to do
with my understanding of `for all practical purposes'.  Or maybe even
`security'.  And we've already been over the `real world' bit.


> If your answer is "this is not the majority of networks", then let's 
> move on to the quantitative data, and stop bantering about what is 
> essentially an exercise in boolean logic.

The question isn't whether or not most networks -are- set up that way,
the question is whether or not most networks -need- to be set up that way[3].
You seem to be asserting that they do.  My contention is that there are
other ways.








- -Steve

- -----
1     Mod some silly process definition.  If `enhance' can be construed
      in any way such that `foo enhances bar' does not imply `foo is
      essential to bar', then `foo enhances bar' does not entail
      `foo is essential to bar'.  That there are cases such
      that both are true doesn't imply that one entails the other.
2     Who puts all their machines on one (logical or physical) segment these
      days?  All but one percent of the `real world'?
3     Presumably you realise that current IT implimentations are far, far
      from being an indicator of how things ought to be done.  And I'm not
      talking about the theory/practise dichotomy.


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

iQCVAwUBN2brECrw2ePTkM9BAQHNTAP+PHKKk8iBBMvDLs2FCRj0Jnv5IEp9GO+o
pv67cUnzAYs8xANarpZngBTltuBM3JlVuh5YUp4TY7XBAkF1uA3wCGnbWsDhMPrv
F+mSAFV+e/LbbrSXqKhAIjOmworkYZ+o7bC3e5DMF04xKe565DAX05WsvJrX35Hb
1j6559wNukw=
=6EdW
-----END PGP SIGNATURE-----