OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
From: Russ (Russ.CooperRC.ON.CA)
Date: Mon Apr 15 2002 - 12:18:46 CDT

  • Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

    Ok, I think the previous message about Windows Update should've
    sufficiently convinced you that WU is a dog and shouldn't be used, by
    anyone, at any time, for any reason. It just sucks, period. And by
    extension, that means that the soon-to-be-released Windows Update,
    Corporate Edition, should be put into the same boat.

    So what now?

    How about someone getting serious about patch management over at
    Microsoft??

    In their explanation of the severity rating scheme, the Microsoft
    Security Response Center (MSRC) said;

    "One of our major concerns is that, all too often, customers fail to
    install the security patches that would protect their systems"

    Um, maybe we know why. Instead of providing a robust, accurate, and
    incredibly reliable mechanism for getting patches onto systems,
    Microsoft have provided a hodge-podge of services (WU), free versions of
    fee-based tools with limited functionality (HFNetchk/MBSA), and myriad
    "download" lists like;

    http://corporate.windowsupdate.microsoft.com
    http://office.microsoft.com/ProductUpdates/default.aspx
    http://office.microsoft.com/Downloads/default.aspx
    http://www.microsoft.com/downloads/search.asp

    Where each appear to have little knowledge of the others, often show
    different results for the same system, or make it near impossible to
    determine precisely what you need (particularly if you're not using all
    of the latest versions of their software).

    Then there are the issues like the difficulty correlating Microsoft
    Security Bulletin patches to patches offered in other locations. Windows
    Update now lists patches according to their KB number, but the Security
    Bulletins today almost always say the KB will follow, or only show the
    KB number on the download page. WU does embed the MSxx-xxx number in the
    text, but its not obvious. Clearly they think they're talking to
    different people and there's no common language.

    I see the problem as two-fold;

    1. There is no centralized organization, and therefore no comprehensive
    and consistent plan, for patch management of Microsoft products. They
    seem to be able to pick and choose between the various existing
    services/download methods, or create an entirely new one of their own if
    they want.

    A good example is getting a cumulative roll-up patch for IE that doesn't
    include patches for Windows Media Player. Or a cumulative roll-up for
    IIS that doesn't include an Index Server patch. Why should they, they're
    different products and under different managers with different
    development teams! Unfortunately, most of us see them as linked and our
    expectorations aren't in synch with what Microsoft is delivering.

    There are, as far as I know, at least 3 different hotfix installation
    tools out there. They use different switches to perform similar actions,
    and none of them are well documented for the System Administrator. So
    while its possible to extract the contents of a hotfix and examine the
    individual files, using the /? Switch to see what you can do doesn't
    show you the /x switch that expands the hotfix.

    WU updates many products, but it doesn't update Office. HFNetchk checks
    for missing patches in several products, but it doesn't know about
    Exchange or Office. Office knows about its products, but it doesn't know
    about IE, a crucial component of every Office product.

    Is it really that difficult to bring this all together? The simple
    answer is yes, it is. In my opinion, its largely due to the loose
    management structure and lack of any focused emphasis on this as a
    problem. Microsoft just don't see this as a big enough problem for its
    customers to do all of the things required to fix it.

    Numerous groups in Microsoft have attempted to fix this issue "once and
    for all", with little success. Ultimately they created their own method,
    causing further variation and confusion for System Administrators.

    Trying to get consensus on this issue has failed, **for years**, its
    time someone with sufficient clout (e.g. Gates himself) put their foot
    down and mandated a plan of action that everyone *must* follow.

    No doubt such a plan is in the works, but I also suspect that any such
    plan is going to be based on .NET and only usable to customers who've
    upgraded (or upgrade immediately upon release). So the solution will be
    unusable by the *majority* of customers for years. One could easily
    infer that this is a ploy to get people to upgrade..."if you want to be
    secure, you must upgrade to .NET servers and Windows XP desktops,
    otherwise your SOL.

    2. Microsoft, and 3rd parties, have made numerous for-free programs
    which "handle" this problem. We shouldn't be expecting this problem to
    be solved for free. Free tools allow us to determine just how much of a
    problem we have, but they can't solve the problem for us. For that, we
    need to buy another tool, suite, or sub-system.

    That's like saying that your car's warranty will get you a letter in the
    mail when there's a recall, but it won't give you the repair. For the
    repair you'll have to get the part and install it yourself, or pay
    someone to do that for you.

    Huh?

    As much as I hate saying that Microsoft should kill a product space,
    this is one that *must* be killed. I want robust, accurate, and
    incredibly reliable patch management for free, regardless of whether I'm
    a home user or in charge of 70,000 systems. If for no other reason than
    should Microsoft have to provide such a system, it will be an incentive
    to minimize the number of patches they release (by minimizing the number
    of patches their products need).

    Another reason is because only Microsoft should be held responsible for
    ensuring my system is patched. Microsoft make mistakes, as the problem
    with FSCFG.DLL in MS02-018 demonstrated. Should a 3rd party be held
    liable for such a mistake (your system doesn't get patched because the
    patch is incorrect)? Who knows better than Microsoft whether a patch is
    or isn't correctly applied to my system? Who can tell better whether I
    have the affected software on my computer?

    With "Trustworthy Computing" being such a hot topic at Microsoft these
    days, they need to acknowledge that Sustained Engineering is one of the
    most crucial elements.

    The difference between what we have, and what we want, is the difference
    between;

    - walking around and touching every machine in my environment versus
    having confidence that a robust, accurate, and incredibly reliable
    *free* patch management system has done it for me overnight.

    - having my entire internal network shutdown because of rampant Nimda
    attacks versus having the confidence they were all patched 5 months
    earlier when the patch was released, and being able to verify they were.

    - having my entire mail system shutdown because of a Badtrans.b
    infection versus knowing that all of my IE installations were patched
    within the 12 days we had after the patch release and before the first
    infection.

    The solution today is available only via money, or manpower, no Zero
    Administration here (replace Zero with the number of dollars for a
    solution or the number of people). The various free tidbits we're
    currently offered only complicate the situation, because they're under
    different management and provide inconsistent results. Fee-based 3rd
    party solutions aren't the answer either, because they don't have all of
    the information they need from all of the product groups who many
    potentially issue their own patches (in their own format, using their
    own detection methods, etc...)

    So we await the next big attack, knowing full well that more than enough
    machines will be susceptible to it regardless of when the patch for its
    exploitation was made available. Not enough people have the money to
    solve this problem, and most of those don't have enough people either.
    Microsoft will say they made the patch available prior to the attack,
    and try to duck the bullet again.

    You would've thought that Code Red, and then Nimda, was enough to
    convince them to go back and fix what's actually deployed, but alas,
    nobody in Redmond runs Windows NT 4.0 any more so from their perspective
    its not a problem. Few even run Windows 2000 any more. I expect that
    robust, accurate, and incredibly reliable free patch management for the
    systems that **will go down** as a result of the next big attack will
    never come from Redmond.

    Budget your upgrades to .NET and Windows XP now, or expect to be
    attacked...

    ...unless of course we can get Microsoft to listen. Unfortunately I
    haven't had much success lately.

    Cheers,
    Russ - Surgeon General of TruSecure Corporation/NTBugtraq Editor