Re: [fw-wiz] A fun smackdown...

From: Paul D. Robertson (paul_at_compuwar.net)
Date: 05/19/05

  • Next message: Paul D. Robertson: "Re: [fw-wiz] A fun smackdown..." 
    To: Chuck Swiger <chuck@codefab.com>
Date: Thu, 19 May 2005 17:32:21 -0400 (EDT)

    On Thu, 19 May 2005, Chuck Swiger wrote:

    > >>> _All_ effective security controls break that tenet. The more liberal
    > >>> your controls, the more risk you assume.
    > >>
    > >> There is more to an effective security control than only denying
    > >> stuff!
    > >
    > > No, there isn't in terms of the mitigation of risk. Anything else
    > > isn't
    > > about the security properties of the control, but about its operational
    > > effectiveness. _What_ you deny, _how_ well it's implemented, and where
    > > you deny it is in fact the essence of security. From guards with guns
    > > to
    > > firewalls to anti-virus, default deny or default except- either one
    > > works
    > ^^^^^^
    > > by blocking stuff (what you know is bad, or what you don't know is
    > > acceptable.)
    >
    > "default accept", you mean? Sure, there are two general approaches:

    Yep brain fumble...

    > "deny all, and then have a list of stuff to permit", or "permit all,
    > and then try to deny stuff known to be bad".

    But both of them rely on blocking things, either known-bad, or unknown.

    > The former approach is a lot more likely to result in a secure system,
    > but both approaches do more than just deny everything: what you accept,
    > how well it's implemented, and where you accept stuff [to paraphase] is
    > also the essence of security.

    I never said they denied everything- I said they worked by blocking stuff.
    In terms of security, what you accept is what you haven't blocked. If
    you're not blocking, then you're not adding security controls.

    > Choosing to provide remote shell access via SSH is better than using
    > Telnet or a VPN. Choosing to provide POP or IMAP via SSL is better
    > than choosing to provide remote mail access via plaintext with
    > passwords passed in the clear. If you can live without either, by all
    > means, forbid remote access.

    That's the point, the more you accept, the more risk you accept. The more
    you block, the less risk.

    > >> I think you're over-valuing the utility of "deep protocol
    > >> inspection",
    > >
    > > Um, what the heck does "deep protocol inspection" have to do with the
    > > fact
    > > that security controls are a denial technology? Where exactly did I
    > > say
    > > anything about deep protocol inspection?
    >
    > You are disagreeing with a design principle from the RFC's which
    > discusses how to create robust software protocols. One could provide
    > other examples.

    No, I'm not disagreeing with it, I'm saying that it's not relevant to
    security because security controls are automatically less than liberal.
    Creating robust protocols isn't the same thing as providing security,
    would that more protocol designers understood that.

    > >> Paul, and you seem to be ignoring the risks of denying legitimate
    > >> connections which should have been permitted.
    > >
    > > No, again- Security works by denying things. That's got nothing to do
    > > with falsely denying things, and everything to do with accepting risk.
    > > If
    > > I deny everything, my risk is lower than if I deny 90% of everything-
    > > but
    > > in either case, the security factor is about denying.
    >
    > Paul, why *don't* people run their firewalls with a single "deny all"
    > rule?

    Again, that's got *nothing* to do with the fact that firewalls work by
    denying traffic. It also has nothing to do with the fact that accepting
    less stuff == less risk. The part where the rubber meets the road is in
    deciding which risks to allow and which stuff is necessary. That doesn't
    mean more stuff won't increase your risk, and it doesn't mean that
    security controls don't work by blocking stuff, both of which were my
    original points.

    > >> An effective security measure needs to implement the security policy.
    > >> It needs to permit the types of access that legitimate users are
    > >> allowed to have, for the system-- meaning the network, the firewall,
    > >> and the server(s) or other equipment being used-- to work correctly.
    > >
    > > That doesn't change the fact that it all works by denying things, not
    > > by
    > > liberally accepting just anything that might come over the wire.
    >
    > I didn't say, "accept anything", I said, accept the types of access
    > that the security policy says are permitted.

    Which means denying everything else. Again, you're trying to put words
    into my mouth. Security polices don't have anything to do with my
    original points.

    > >> This is just as important as denying access to stuff that is not
    > >> permitted by the security policy.
    > >
    > > That's not a security property though, it's an operational property.
    > > Now,
    > > you can argue that denying too much impacts business, and I'd agree,
    > > because it doesn't conflict with what I said-
    > >
    > > 1. Security things work by blocking stuff.
    > > 2. The less stuff you block, the more risk you assume.
    >
    > If my key doesn't open my front door, it's blocking legitimate access.
    > A security system which prevents legitimate access is a broken security
    > system.

    No, that's a risk/reward choice that's made by the security policy. It's
    perfectly acceptable to have false positives in some situations. It may
    in fact, be designed in because the cost of loss is so great that having
    some denied legitimate access is worth reducing the overall risk. Just
    because it's not *convenient* doesn't mean it's broken. Rate of false
    positive is, just like rate of false negative something that's part of the
    "should I do this?" equation, not the "is this secure" equation.

    It may be that you're roaring drunk, and if you got in, you'd throw things
    around, or accidentally drop a lit candle on the floor and burn the place
    down- so there is still less risk if you key doesn't work, it's just then
    not as useful for you as a door (or like most users, you'll just leave it
    unlocked.)

    > >> Has "fixup protocol smtp 25" actually done much to prevent a
    > >> vulnerable
    > >> M$ Exchange box from being owned, or helped control the flow of
    > >> spammy/virusized traffic significantly? Does it help control outbound
    > >
    > > I don't know what it does, since I don't field PIXes and have only
    > > worked
    > > on two in my entire life; but I _assume_ that it will block the
    > > Microsoft-only SMTP extension that popped up a couple of months ago as
    > > a
    > > vulnerability.
    > >
    > > Now, *if* it does, it *breaks* something that Microsoft Exchange Server
    > > does when talking- see- that's the point, protection comes at the cost
    > > of
    > > breaking functionality once you get to the point where you've knocked
    > > out
    > > the out-of-band stuff and you're just left with the in-band attacks.
    >
    > I used Cisco's proxying of SMTP as a well-known example of a "security
    > feature" which breaks legitimate protocol extensions (ESMTP), yet

    That's the point; You stop things (I don't think it really "breaks it,"
    since it should default to HELO instead of EHLO- so "doesn't allow
    increased functionality" is probably more accurate.) Heck, I try not to
    run browsers that do ActiveX when I run a browser on a Microsoft OS,
    that's reduced functionality too- but I'm willing to accept it because it
    reduces my risk.

    Guards with guns stop the free flow of people, and reduce the
    functionality of a place- but they also reduce the risk if they're doing
    their jobs- and many places are happy to deploy them.

    > doesn't seem to really improve security, but if you aren't very
    > familiar with it, I won't insist on debating this particular example.
    > :-)

    Does it stop the MS-only extensions? In that case it does provide some
    security value- unless you feel that overflows in SMTP verbs aren't that
    big a security deal...

    I know SMTP-fixup had poor implementation bugs initially, but that still
    doesn't remove the "able to reduce risk by denying things," it simply
    speaks to the quality of implementation.

    >
    > How about excessive ICMP filtering breaking path MTU discovery?

    Sure it might, but that doesn't mean it doesn't provide security from ICMP
    attacks. Again, it's a risk/reward calculation- but the blocking reduces
    risk, at the expense of either operational capability or functionality.

    FWIW, "excessive" (which is really trying to paint the landscape) ICMP
    filtering doesn't have to break PMTU discovery if you filter after you've
    already lowered the MTU before it hits that router- back when lots of
    things had ICMP frag overlap problems, I used to "excessively" filter some
    networks just fine, and the older devices were protected.

    Blocking outbound TCP/6667-7002 reduces lots of risk for lots of networks,
    but it breaks IRC to a lot of networks. That's the name of the game,
    reducing risk by being more conservative in what you accept, and trading
    reduced operations and functionality for increased security.

    That's still it in a nutshell, block stuff and reduce risk. How much
    stuff, and how much risk are the practice of security implementation, but
    the essence remains the same.

    Paul
    -----------------------------------------------------------------------------
    Paul D. Robertson "My statements in this message are personal opinions
    paul@compuwar.net which may have no basis whatsoever in fact."
    _______________________________________________
    firewall-wizards mailing list
    firewall-wizards@honor.icsalabs.com
    http://honor.icsalabs.com/mailman/listinfo/firewall-wizards

  • Next message: Paul D. Robertson: "Re: [fw-wiz] A fun smackdown..."

    Relevant Pages

    • RE: Why Easy To Use Software Is Putting You At Risk
      ... I do agree that the additions and changes to Solarius will make it more secure and that this is good. ... Why Easy To Use Software Is Putting You At Risk ... instead I would say that the view that security is ... Four Construction Workers Died after Crane Collapse in Toledo, ...
      (Security-Basics)
    • RE: Why Easy To Use Software Is Putting You At Risk
      ... Why Easy To Use Software Is Putting You At Risk ... Four Construction Workers Died after Crane Collapse in Toledo, ... The first issue to address is yes you found a vulnerability and it was ... a Security Discussion board, that is what we do here. ...
      (Security-Basics)
    • More food for thought
      ... Basic Risk Analysis ... I have taken a position that the professional security community in general ... has and will continue to fail because they are operating under the same ... storing those backups safely offsite in a secure location on a daily basis. ...
      (comp.security.misc)
    • More food for thought
      ... Basic Risk Analysis ... I have taken a position that the professional security community in general ... has and will continue to fail because they are operating under the same ... storing those backups safely offsite in a secure location on a daily basis. ...
      (comp.os.ms-windows.nt.admin.security)
    • Re: Risk metrics
      ... security management life cycle. ... more objective snapshot of a company's risk posture. ... > traditional risk metrics in pen-tests cannot be ... >> vulnerability works, and if an exploit is in the ...
      (Pen-Test)