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

From: Marcus J. Ranum (mjr_at_ranum.com)
Date: 05/21/05

  • Next message: Marcus J. Ranum: "Re: [fw-wiz] A fun smackdown..." 
    To: Chuck Swiger <chuck@codefab.com>
Date: Sat, 21 May 2005 12:31:07 -0400

    Chuck Swiger wrote:
    >I'd rather see an explicit statement that says, "this is not a secure protocol", then use something which pretends to be secure, yet is not.

    Um, no. If it's going to be standardized for widespread deployment
    on the Internet it needs to address security. Period. The days are
    over when people can just ignore that; that's part of how we got
    into the mess we're in now.

    >>The RFC process creates interoperable *CRAP*.
    >
    >Let's accept this as true for a moment. Can you point to something better?

    Oh, I see. Because I'm pointing out that something's broken, it's my
    job to fix it? ;)

    Actually, my previous Email contained a perfectly decent suggestion,
    namely that standards should specify separate operational stacks
    depending on use to which the protocols are being put. That requires
    some forethought in the design process, of course. Lack of which is
    the entire problem. Standards should at a minimum specify trusted
    mode operation distinctly from untrusted mode operation, and should
    specify that all servers/services default their initial configuration to
    untrusted mode. Do you have any idea how much grief that would
    have saved us?

    Are you defending the design philosophy of "make it work, fix it later"?

    >What about the ISO model, the X.400 & X.500 schemas, and ASN.1?
    >How well has BER, SNMP, SSL certs, and all of that done in practice for security?

    I didn't say ISO was any good, either! <LOL> C'mon... I've been
    bashing standards committees as useless on this mailing list since
    the first day I started it!

    >Or how about the security vendors, who break standards to create proprietary, non-interoperable crap?

    Stupid customers who give thier money to vendors that do that, deserve
    what they get. Stupid customers who buy "mission critical" products
    that don't interoperate with other "mission critical" products, deserve
    what they get. Stupid customers who buy cool widgets with blinky
    lights that do "deep inspection" deserve what they get.

    Let's look at the problem from a completely different perspective for
    a second. Do you CARE if there is a standard, if everything works
    together? I.e.: who cares if it's written down. Make it the vendors'
    problem to make sure it works. Customers should *always* have
    been specifying interoperation and security requirements in their
    products. That never happened, so the vendors are running the
    show. And, of COURSE they aren't going to "just do the right thing"
    because it's not in their interest. That's why standards bodies
    are *NEVER* effective in a market where there is still commercial
    life. Standards only can happen once a market is commoditized
    to the point where customers get their heads out of the sand and
    realize "duh! my wireless stuff should work together" -- I know
    that's all counter-intuitive to you, if you're a believer in the standards
    process, but think carefully about the success or non-success of
    standards efforts depending on the stage a given technology is
    at. There are some aberrations (like Wireless) where the vendors
    recognize that they actually need to make things work together
    *before* the market will blossom But as soon as it does, they
    then try power-grabs.

    Meanwhile, the standards bodies are increasingly left as weak
    sisters that come up with standards that are literally years
    too late to have meaningful impact - even if they were any good
    (which they aren't) Vis IPSEC. I had one of my engineers put
    SwIPe into Gauntlet because IETF had been thinking "IP encryption
    would be really nice" for 4 years and gotten noplace other than
    debate. So we shipped product. Because there was $$ to be made.
    And we told customers "We'll support IPSEC when and if it happens"
    If we'd had customers that said "we won't buy your product until
    it's compatible with Cisco" we'd have either done it or gone out of
    business.

    This industry is driven by market dynamics, not by standards
    committees. Ignore the IETF (except to laugh at them) like
    I do and focus on the economic incentives. The reason the
    industry is screwed up right now is because the customers
    have ceeded control to the vendors.

    >Not always. There are people, even on this list, who could learn something from:
    >
    >http://www.ietf.org/rfc/rfc2196.txt

    That document summarizes a set of observations of how real-world
    stuff behaves in practice. That's not a "standard" that's a "security
    for dummies" guide. If it was a standard, it would say "do NOT
    build your own firewall" etc.

    > As an aside, building a "home grown" firewall requires a significant
    > amount of skill and knowledge of TCP/IP. It should not be trivially
    > attempted because a perceived sense of security is worse in the long
    > run than knowing that there is no security. As with all security
    > measures, it is important to decide on the threat, the value of the
    > assets to be protected, and the costs to implement security.
    >
    >Give that RFC a fair read, Marcus, and then see whether you still agree with your own generalization above.

    Like I said, it's a how-to guide. It was written prior to 1997, based on
    the experiences of people who had been out "being there and doing
    that" since the late 1980's. I see some of my old TIS co-workers helped
    author that RFC. Co-workers who were sitting in their offices doing
    "theoretical computer security" while I was out installing firewalls
    all over the place.

    In other words, RFC 2196 documents acquired common sense.
    Useful standards (if there were such a thing) would provide
    roadmaps to the future, not "here's what we learned in the past."

    mjr.

    _______________________________________________
    firewall-wizards mailing list
    firewall-wizards@honor.icsalabs.com
    http://honor.icsalabs.com/mailman/listinfo/firewall-wizards

  • Next message: Marcus J. Ranum: "Re: [fw-wiz] A fun smackdown..."

    Relevant Pages

    • Re: threat/attack nomenclature/reporting [was Re: IDS Correlation]
      ... How many of the IDS vendors ... >the fact that vendors do not always buy into these standards, ... we had customers with money who wanted a solution. ... some of the IDS vendors are making it harder to get at their data ...
      (Focus-IDS)
    • RE: OSSTMM how good is it?
      ... I believe the OSSTMM is a good framework, in an industry with few public ... it is probably one of the few standards the customer can get for ... It is good because it challenges the perception that many IT Security ... Download FREE whitepaper on how a managed service ...
      (Pen-Test)
    • Re: [fw-wiz] iso 17799
      ... I think if we don't share now the marketing droids will win ... > have to battle the standards where they don't make sense (remember ... Though it hasn't been updated in sometime, I bet the firewalls-faq is ... There are tons of books on firewalling and basic security techniques, ...
      (Firewall-Wizards)
    • The ISO 27001 Newsletter: Issue 18 Published
      ... news and background with respect to the ISO security standards. ... Trials and Tribulations of an Information Security Officer Part 2 ...
      (comp.security.misc)
    • Issue 18 of The ISO 27000 Newsletter Released
      ... news and background with respect to the ISO security standards. ... Trials and Tribulations of an Information Security Officer Part 2 ...
      (alt.computer.security)