Re: [fw-wiz] iso 17799

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

  • Next message: Marcus J. Ranum: "Re: [fw-wiz] iso 17799"
    To: Dana Nowell <DanaNowell@cornerstonesoftware.com>, "Paul D. Robertson" <paul@compuwar.net>
    Date: Tue, 20 Jul 2004 23:49:40 -0400
    
    

    Dana Nowell wrote: (in response to Paul Robertson)
    >Great, how do the rest of us learn to negate 90% of the risk? Got a paper
    >somewhere? Written up an FAQ? Guideline? "Best Practice"? :-) Know of a
    >good repository of that type of thing? Or is every newbie supposed to post
    >the question to the list to extract your knowledge, say every other month?
    >('cause you KNOW they don't search the archives)

    Well, there are 2 ways to negate 90% of your risk:
            a) do a few simple, obvious things that are not very fun
            -or-
            b) spend a ton of money on products and process

    Let me try to explain it a different way:
            Computer security, as it's done today by most practitioners, is
    fundamentally a con. It's a con the same way that most diet foods
    and "lose weight fast" schemes are a con: they cost a lot and they
    only work if you do something sensible that would have worked
    REGARDLESS of whether you were following the rules of the
    diet. Because, basically, successful diets involve taking in less
    than you burn. All of them. It's the 2nd law of thermodynamics,
    basically. If you burn more fuel than you take on, you'll get smaller.
    Well, security's the same way: if you only do smart safe stuff,
    you won't get hacked. If you buy a $100,000 security doo-dad
    that makes sure you only do smart safe stuff, you won't get hacked.
    But the actual presence of the $100,000 doo-dad has relatively
    little to do with it other than making the vendor happy and giving
    the stupid suits you work for something to point at that has
    neat-o blinky lights. It's a con.

            Simple, obvious things:
            1) Make your network originate-only except for a very very
                    very very (is that enough "very"s?) small handful
                    of services
                    a) lock down those services
                    b) log usage of those services
                    c) put error detection into service-specific places on
                            those services (hey, you can even call it
                            "intrusion detection" if you want to make
                            Gartner happy)
            2) Know what's going on in your network
                    a) know who normally talks to whom
                    b) log usage of your network and look at those logs
                    c) know your security policy as well as normal usage
                    d) look in your logs for indications that your policy is
                            being violated (burglar alarms)
            3) Your policy should be "deny all"
                    a) only permit it if it needs to be permitted
            4) Internally compartment your network
                    a) mission critical machines should be behind
                            screening routers, on separate networks,
                            with a bare minimum (zero is a good start..)
                            of services back and forth
                    b) audit all traffic between mission critical systems and
                            non-critical systems
                    c) if someone can walk into your facility and plug
                            into a network port, get an IP address
                            assigned to them, and ping your
                            mission critical machines, your network
                            is a disaster waiting to happen
                    d) if someone can walk into your facility and plug
                            into a network port without you knowing
                            about it, your network is a disaster area
                            already; you're just blissfully ignorant
            5) Delete incoming attachments at the gateway to your
                    network except for a short-list of acceptable mime
                    types
            6) Don't outsource security; outsourcing is an admission
                    that you are ignorant and that your management
                    are clueless - or that your clueless management
                    think you're ignorant
            7) Know what goes out through your firewall
                    a) if you don't know how much spyware is installed
                            on your desktops, your network is 0wned
                    b) if you don't know how much IRC traffic is leaving
                            your firewall you're 0wned
                    c) why the heck would you let IRC out through your
                            firewall, anyhow? what are you, a born
                            victim?
            8) If you don't understand the difference between layer 7
                    security and "stateful inspection" - learn
            9) Don't waste your time patching
                    a) if you're running code on an internet-facing
                            system that has a history of needing
                            patches every week, you're running
                            the wrong code
                    b) your internet-facing machines should have
                            exterior lock-downs that mitigate the
                            damage of individual service/server
                            failure, or they shouldn't be internet
                            facing
                    c) if they aren't internet facing don't make them
                            internet facing just so you can get patches
                    d) production systems 101:
                            10 SET IT UP
                            20 MAKE IT WORK
                            30 IF WORKING THEN
                            40 DON'T F- WITH IT
                            50 ENDIF
                            60 IF NOT WORKING
                            70 FIX IT
                            80 GOTO 20
                            90 ENDIF
                            it's that BASIC (ok, that was a bad one...)
            10) Why on earth would you have roaming users connecting
                    straight into your corporate WAN after they have been
                    at home surfing pornsites and downloading Warez?
                    a) mobile users go on a separate network
            11) Antivirus software is good
                    a) updating it 4X / day is not necessary
                    b) updating it 1X / week works fine but especially
                            when combined with stripping attachments
                            (see above)
            12) No, your users do NOT need that stupid new chat/file sharing/
                    net-meeting/remote-control/powerpoint sales tool/virtual FAX
                    garbage - it IS dangerous

    See? That's a list of great, simple, powerful ideas. If you do these things
    you will virtually never get hacked. Of course, in the immortal words
    of Ray Wylie Hubbard,
    "It's not so hard to do what's right; it's just not as much fun."
    (Conversations with the Devil, from Crusades of the Restless Knights)

    >IMO, the 'push for standards' is because the field is exploding AND
    >maturing and many, many, newbies are being thrown in to the fire everyday.

    The push for standards has nothing to do with the unfortunate newbies.
    Standardization is a long-running conversation (or battle) between
    vendors and customers over who has control over the market.
    Standards only happen (are allowed to happen) once the innovation
    has gone out of a market - or in the rare case where a standard
    happens in spite of vendors splitting the market - standards cause
    innovation to go out of the market. The vendors will innovate (read:
    make stuff that doesn't work together) someplace else.

    If you look at the effectiveness of standards bodies since the
    early 1990's (the beginning of the Internet era) you'll notice
    that they have been reduced to a bunch of squabbling vendor
    shills (with a few academics and idealists thrown in) that are
    only able to effectively ratify the installed base after throwing
    a few little tweaks on to show that NIH syndrome is alive and well.

    >The frustration is that people on this list 'generally' solve the same
    >problems, use lots of the same references, sites, and resources.

    Well, part of it is because some of us (heya Paul! Fred! Steve!
    Michael!) have been singing basically the same song for ever.
    I published a few verses of it above. We've been singing the
    song through rain and snow and we've been right all along.
    And when people ask for a solution, what they're really saying
    is "We don't LIKE the rules of the jungle! Surely if I just buy
    this new $100,000 doo-dad then I can rewrite them so they
    no longer apply to me!" Nu-huh.

    > This list
    >is dedicated to answering specific questions about firewall
    >implementations, a good thing. However no centralized list or repository
    >exists to share the 'other' information required in the real world
    >(training materials, reference materials, example risk
    >assessments/documents, staff/food chain management issues, software, etc.).
    > The list is good, it does its job well, too well, people want the other
    >problems solved as well and currently they can't have it.

    Conferences like SANS try to do this, as do most security-oriented
    conferences. Personally I think you can learn it all yourself if you
    are motivated enough. This list is not the right place for that. Not
    because nobody here knows what to do; it's just our throats
    are tired from singing the same song and then having people
    say, "that sounds like sense but there's no WAY my pointy-haired
    boss is gonna let me do that."

    >In one man's opinion, that's one of the main reasons why we see the push
    >for 'standards'. It's not really standards people want, so much as
    >direction/help with the 'other' parts of their job.

    If you "standardize" enough then you've derived a "one size fits
    all" - which you can only do after something has commoditized
    to the point where it is no longer interesting. I'm not saying that's
    a bad thing - not by a long shot - but the implication of my
    view, if I am right, is that there will never be useful or meaningful
    standards regarding whatever the most interesting problem is that
    you have on your plate at any given moment.

    mjr. "A standard of one, since 1962"

    _______________________________________________
    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] iso 17799"

    Relevant Pages

    • Re: Intergenerational Transmission of Abuse - a Lancet Article
      ... >> Intergenerational continuity of child physical abuse: ... >> standards derived from a hypothetical randomised controlled trial, ... not sure you can do a true metaanalysis with risk. ... >> FINDINGS: In the ten studies identified (four cohort, ...
      (sci.psychology.psychotherapy.moderated)
    • Re: [fw-wiz] iso 17799
      ... I'll put my head in the noose again ... ... >One person's best practices are another's waste of time. ... then obviously the risk goes up. ... the 'push for standards' is because the field is exploding AND ...
      (Firewall-Wizards)
    • Re: Intergenerational Transmission of Abuse - a Lancet Article
      ... > Intergenerational continuity of child physical abuse: ... > standards derived from a hypothetical randomised controlled trial, ... studies found some increase in risk, and 3 showed a very low relative ...
      (sci.psychology.psychotherapy.moderated)
    • Re: Intergenerational Transmission of Abuse - a Lancet Article
      ... >studies found some increase in risk, and 2 showed a very low relative ... >>> but that which met six standards did not support the hypothesis. ... The Beverly Hills Freudians tied the Chicago Rogerians 0-0 last ...
      (sci.psychology.psychotherapy.moderated)
    • Re: Intergenerational Transmission of Abuse - a Lancet Article
      ... > though there is an intergeneratioas aspect, ... >> but in three other studies the relative risks were less than 2. ... studies found some increase in risk, and 2 showed a very low relative ... >> but that which met six standards did not support the hypothesis. ...
      (sci.psychology.psychotherapy.moderated)