Slashdot Mirror

← Back to Stories (view on slashdot.org)

Microsoft Opens Its Security Research Cookbooks

Posted by ryuzaki0 on from the now-cook-me-up-some-pie dept.

greg65535 writes "Today Microsoft launched a blog about the internals of their IT security research and patch development process. There are already some posts that you will not find in the official security bulletins or KB articles. One of the posts says, 'We periodically identify workarounds or mitigations like this that we can't use for official guidance because they're either too nuanced or have some exception cases. When we discover something potentially useful but are uncomfortable listing it in the bulletin, we'll do our best to describe it here in this blog.' It looks like Microsoft is making an effort to become more 'open' in the area of security research and communication."

4 of 87 comments (clear)

  1. But will they release source code... by christian.einfeldt · · Score: 4, Insightful
    ...in exchange for all of the help that they get? Probably not. Seeing that most developers want their free labor to at least result in open source code, I can't imagine that this effort is going to be all that popular with the best developers.

    Microsoft likes to throw around the word "open" a lot these days, but most smart people in the industry remain skeptical. Take, for example, what open standards advocate Russell Ossendryver has to say about Microsoft's supposed open OOXML format:

    The legacy binary formats remain closed. If a file is one which was converted from an older format of Microsoft Office by DIS29500 and allowed to wrap the old file in xml, it remains unreadable for everyone else. OOXML is still a closed spec tied into to many proprietary formats.
    So how open is open? Unless the code is considered open under OSI standards or Free under FSF guidelines, it's really still just a pig with lipstick and a dress.
    1. Re:But will they release source code... by nrgy · · Score: 5, Insightful

      Ugh I hate to defend Microsoft but I have to be one to disagree with you.

      When I provide code for people, projects, or even companies who's software I use, I could really give a rats behind if its open source or not. Sure it would be NICE but hardly REQUIRED by me at least.

      If you don't like what will be done with your free labour then don't provide it, no one is forcing you to. I like people who contribute and provide there free time, but I don't like it when those same people feel that since its so called FREE LABOUR that they can start imposing what can and should be done with there FREE LABOUR. It just doesn't work that way

      Yes you are providing a service, yes it is welcome by the recipient and community, NO you shouldn't have a say in what way your contributions are disseminated because it was your choice to provide the service and no one else's.

      I don't know about you but I provide my code because I want a better end product, not because I want it to be free in the open. If the code I provide will make my life easier then do with it as you will. Just because its not OPEN SOURCE like you say doesn't mean that it doesn't perform any good for the community of users for software X. Besides you wrote the stuff, unless you signed a legal waver to your code then nothing is stopping YOU from releasing it OPEN SOURCE style.

  2. Too nuanced? by morgan_greywolf · · Score: 5, Insightful

    There is actually another mitigating factor present here that we didn't include in the bulletin because we could not authoritatively say that it was true in every case. The vulnerable code path only executes if your machine has a primary DNS suffix. Most of the time, only domain-joined machines have a primary DNS suffix. So it would have been great to say in the bulletin: "Machines not joined to a domain are safe" but that is not 100% accurate so we did not include that. Technically, an administrator could manually set a primary DNS suffix on a non-domain-joined machine. Okay...

    We periodically identify workarounds or mitigations like this that we can't use for official guidance because they're either too nuanced. How, exactly, is this 'too nuanced'? Why not just say "if your machine doesn't have a primary DNS suffix, you are not vulnerable"?

    I'll tell you why...because they assume that Windows administrators are idiots. Now, I've known some stupid Windows administrators in my day, but I wouldn't go so far as to think that most of them are idiots.

    --
    My blog
  3. Re:Microsoft Security Protocols by Anonymous Coward · · Score: 5, Insightful

    No, you're not. This comment reads like a total troll for "big-ups".

    Security is about the best tool for the job and it's not always the Open Source tool, with the "street cred". When you say you're an IT professional, do you by chance mean you work for a small business, supporting other small businesses, (with pirated copies of Windows)?

    No one avenue is the correct choice for security. You should chose the complete set of tools from a variety of vendors, who offer total support. Good luck getting official support with tripwire on Debian.

    Cisco are a proprietary vendor - are you telling me they have no quality solutions? I suppose you don't use Symantec or another vendors AV, on your client desktops? Microsoft ISA actually offers a very robust and powerful firewalling system, for exampling, allowing you to internally spoof/proxy SSL certificates to domain members so you can even inspect encrypted packets on the network. Maybe not a polite thing to do but clearly useful in some organisations.

    And while we're on it, Domains... Active Directory is a security tool in itself. Locking down desktops and client machines is a key security method and AD offers about the best way to do this on the market - I suppose you use Samba and about 500 perl scripts, instead, do you?

    What utter garbage...