Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Security Programming IT Technology

Microsoft's Larry Osterman On Threat Modeling 113

Posted by ScuttleMonkey from the they-threat-model-at-microsoft dept.
Schneier has pointed out an excellent series of blog posts about threat modeling by Microsoft's Larry Osterman. The series focuses on the PlaySound API as an example. "As you go about filling in the threat model threat list, it's important to consider the consequences of entering threats and mitigations. While it can be easy to find threats, it is important to realize that all threats have real-world consequences for the development team. At the end of the day, this process is about ensuring that our customer's machines aren't compromised. When we're deciding which threats need mitigation, we concentrate our efforts on those where the attacker can cause real damage."
This discussion has been archived. No new comments can be posted.

Microsoft's Larry Osterman On Threat Modeling More

Microsoft's Larry Osterman On Threat Modeling

Comments Filter:
  • Consumer: My company doesn't need Vista, we're using Linux which has about the same amount of bumps and hiccups.
    Microsoft: You mean you're using an operating system that validates over 450 of our patents?
    Consumer: Well, I know that isn't true but ...
    Microsoft: But it'd be a shame if your company was ever engaged with our world class legal team instead of being a 'partner' with the largest software maker ever?
    Consumer: But we only have 20 employees.
    Microsoft: We know--perhaps you'd be interested in purchasing a copy of our lap dog here, Novell's SUSE?
    Consumer: But we already use Red Hat ...
    Microsoft: We heavily suggest you re-evaluate SUSE and when you do your trade study please do note that it's the only Microsoft Certified Genuine Linux. Also, it would be a shame if we had to exercise our patent portfolio on Red Hat and subsequently ... well, no reason to get into details. Have a nice day!

    • Re: (Score:2)

      by pembo13 ( 770295 )
      one can only hope that such never takes place. but posters are always quick to remind others that businesses are profit oriented only, yet seemingly reluctant to believe that such conversations are likely.

    • Re: (Score:2, Funny)

      by Anonymous Coward
      Given that the article talks about the audio api, it probably went more like this:

      Threat: User may play a song without paying for it.
      Mitigation: Render the internet useless while playing music.

      Threat: User may complain about the network being crippled while playing music.
      Mitigation: Blame hardware, blame drivers, then make up some excuse that playing audio requires super-low latency priority for the audio playing app and the network is sacrificed to ensure smooth playback.

      Threat: User may notice that the ne
    • Slashdotter: Windows!@ You obviously didn't RTFM or the FP we don't do Windows here
      Microsoft: You obviously are spending too much time on forums, games and caffeine... Did you know Vista..
      Slashdotter: I don't live in San Diego [vista.ca.us]...
      Microsoft: No, not the town, I mean Vista...
      Slashdotter: dewd!!!!!!! I don't even speak Spanish
      Microsoft: *gives up*

    • Consumer: Google?

      Microsoft: ?? [Throws chair...]

  • That's got to be a hell of a job (Score:5, Insightful)

    by Skyshadow ( 508 ) * on Monday October 01, 2007 @11:46AM (#20811953) Homepage
    Try to imagine this guy's work day: He gets to wake up in the morning, hug his kids and then go into work and spend all day trying to figure out the right combination of security defaults that will (a) let people go out and do stuff while (b) protecting them from their own "I'm a average Windows user" level of abject stupidity.

    Put another way, imagine that instead of just setting up a computer for your parents, you had to set one up for *everybody's* parents. All at once.

    As much as it's fun to give MS shit for their products, I think I'd last about two hours in that position before I went into the executive washroom and slashed my wrists.

    • Re: (Score:3, Informative)

      by ScytheBlade1 ( 772156 )
      I've got his RSS feed in my RSS reader (http://blogs.msdn.com/larryosterman/rss.xml). I enjoy reading about the details of what goes on inside of MS, and I really do enjoy getting the story straight from the horse's mouth. For example, the whole "playing a video kills my network performance" thing. Slashdot is, well, Slashdot. It'll spin it how it wants to.

      Larry started doing this threat modeling bit a while back, as the first article is dated some time ago. He's taken his time, and demonstrated what to do

      • Re: (Score:3, Informative)

        by account_deleted ( 4530225 )
        Comment removed based on user account deletion
        • Comment removed based on user account deletion

          • I prefer Attack Trees. (Score:3, Insightful)

            by khasim ( 1285 )
            http://en.wikipedia.org/wiki/Attack_tree [wikipedia.org]
            By Bruce Schneier.

            Face it, no matter how secure your little bit of code is, if the SYSTEM is vulnerable, your little bit of code is vulnerable.

            Which is where Larry goes wrong in TFA.

            You can put all the locks you want on your front door. But if you don't fix the huge hole in the wall next to it, you aren't improving your security at all. No matter what you claim.

            • Re: (Score:1, Flamebait)

              by pegr ( 46683 )
              Face it, no matter how secure your little bit of code is, if the SYSTEM is vulnerable, your little bit of code is vulnerable.
               
              No way, baby! Larry did his homework! That PlaySound API is rock solid!

              Um, did anybody else notice that the PlaySound API doesn't actually play any sounds? It just passes data to the APIs that actually do play sounds. So WTF does the PlaySound API do, really? To me, it doesn't really do anything at all...
              • Well, ultimately it's going to be the sound card driver that eventually gets called with the sound to play. The playsound API should really only care about the capabilities of the soundcard, not the details of the hardware interface.

              • Um, did anybody else notice that the PlaySound API doesn't actually play any sounds? It just passes data to the APIs that actually do play sounds. So WTF does the PlaySound API do, really? To me, it doesn't really do anything at all...
                It makes the API copyright by Microsoft so nobody else can implement it?

            • Re: (Score:2)

              by n0-0p ( 325773 )
              Uh, attack trees are one of several techniques used in threat modeling. And the whole point of the exercise is to identify the security aspects of a system. That means understanding the trust relationships, attack surface, and associated threats. So, the threat model should be helping you identify if the lock on the front door really helps or if there's a big gaping hole in the wall next to it.

              That said, a threat model isn't a panacea. It doesn't replace good coding practices, code reviews, testing, or anyt

              • Re: (Score:1, Flamebait)

                by jabuzz ( 182671 )
                Rather than spending large chunks of time trying to work out where you don't need to bother testing your inputs you can just be paranoid from day one and trust nothing.

                A threat model is about admitting we have a bad product, saying that fixing it properly is too hard /expensive so we will try and work out what the largest holes are and fix those first.

                • Re: (Score:3, Informative)

                  by swillden ( 191260 ) *

                  A threat model is about admitting we have a bad product, saying that fixing it properly is too hard /expensive so we will try and work out what the largest holes are and fix those first.

                  Nonsense.

                  Threat modeling is a crucial exercise for any system that wants to be secure. Note that "system" is more than just "software", so just testing your software against all possible inputs is insufficient, even if it were actually possible.

                  For example, let's suppose the system under consideration is the Windows access control system, responsible for ensuring that only authorized users can read/write files. What are the attack vectors? How many of them can be addressed with input validation tes

                • Re: (Score:2)

                  by cooldev ( 204270 )

                  A threat model is about admitting we have a bad product, saying that fixing it properly is too hard /expensive so we will try and work out what the largest holes are and fix those first.

                  Do you mean to say that you are against looking for security weaknesses in a product's design during the design phase, with a focus on untrusted input and data crossing trust boundaries? Ahahahahaha. Hahahaha. *Snorgahah*. Haha. Knowing how much open source there is in use today, especially on the server, I sincerely hop

        • meh, its only the size of a womp rat.

      • Re: (Score:2)

        by suv4x4 ( 956391 )
        Just because it's MS doesn't mean that it needs to be senselessly bashed. This would be one of the reasons as to why it shouldn't be. This guy knows what he's doing, and he does it well. Gasp, he works for MS.

        He may know what he's doing, but here's what he has to say about his colleagues in Microsoft:


        "Developers tend to think in terms of what a customer needs. But many times, the things that make things really cool for a customer provide a superhighway for the bad guy to attack your code. "

        "It's ad-hoc. M

      • Re: (Score:2)

        by blhack ( 921171 ) *

        "playing a video kills my network performance"
        I just want to let everybody know that I had this exact problem on several different linux boxes running gentoo. We (being me and the folks in #gentoo on freenode.net) finally figured out that it was due to an IRQ conflict between the soundcard and the wireless card.

        Remapping IRQs in the bios didn't fix it....so i sacrificed both cards to the thermite gods.

    • Re: (Score:2, Insightful)

      by pembo13 ( 770295 )
      well, they built that type of user, they get to deal with it

    • Re: (Score:2)

      by suv4x4 ( 956391 )
      Try to imagine this guy's work day: He gets to wake up in the morning, hug his kids and then go into work and spend all day trying to figure out the right combination of security defaults that will (a) let people go out and do stuff while (b) protecting them from their own "I'm a average Windows user" level of abject stupidity.

      Put another way, imagine that instead of just setting up a computer for your parents, you had to set one up for *everybody's* parents. All at once.

      As much as it's fun to give MS shit

    • Re: (Score:2)

      by hxnwix ( 652290 )

      He gets to wake up in the morning, hug his kids and then go into work and spend all day trying to figure out the right combination of security defaults that will (a) let people go out and do stuff while (b) protecting them from their own "I'm a average Windows user" level of abject stupidity.

      WARNING: This operation may or may not be vital and normal and correct / extremely dangerous and certain to result in fraud. Cancel/Allow?

      Indeed, this guy takes his job seriously and is proud of the fact that he has never copped out nor abdicated his responsibilities. We should also respect him for his excellent & highly informative work on theoretical physics titled This Exercise Left To The Reader.

    • Put another way, imagine that instead of just setting up a computer for your parents, you had to set one up for *everybody's* parents. All at once.

      I'd get them a Mac.

      Unfortunately, Microsoft can't get there from here.

  • Double-plus ungood (Score:1, Insightful)

    by Anonymous Coward
    I guess "threat mitigation" is more cost-effective than "writing code that doesn't suck".

    • It is, for the software vendor. The software vendor gets to push the cost of un-sucking the code to the consumers who actually need suck-less code. Of course the consumers never get that, they get to mitigate threats instead, which is almost as good. Sort of.

      Funny that "threat mitigation" doesn't exist in the aerospace industry...

      • Re: (Score:3, Interesting)

        by Mongoose Disciple ( 722373 )
        Funny that "threat mitigation" doesn't exist in the aerospace industry...

        What would you call passing through airport security to fly on a passenger aircraft?

        Airplanes typically don't stand up to serious attacks. I'm not sure where you're trying to go with this analogy.

        • Airplanes typically don't stand up to serious attacks. I'm not sure where you're trying to go with this analogy.

          I was actually thinking more of the space part of aerospace... sort of trying to make a point that when cost of software failure is sufficiently high, the software will be very rigorously un-sucked prior to launch. Whereas in non-space-exploration kind of thing the cost of failure is typically less than what decent testing would have cost in the first place -- except when people die, and stuff

      • Funny that "threat mitigation" doesn't exist in the aerospace industry...

        It damned well does. What mechanisms are in place to ensure that a malicious attacker can't take control of the avionics in-flight? What mechanisms exist to ensure that failure of one component doesn't crash the plane? What mechanisms exist to ensure that metal fatigue doesn't cause a wing to snap, since redundant wings to backstop the primary ones aren't practical?

        All of the above mechanisms -- some of which are implemented in software, some in hardware and some in maintenance processes -- are threa

      • Re: (Score:2)

        by drsmithy ( 35869 )

        Funny that "threat mitigation" doesn't exist in the aerospace industry...

        I think (hope) you have made a gross misinterpretation of the term "threat mitigation".

      • Re: (Score:2)

        by Allador ( 537449 )

        Funny that "threat mitigation" doesn't exist in the aerospace industry

        Of course it does. Just because *gasp* a different industry doesnt use exactly the same terms, doesnt mean the practice isnt there.

        Things like redundancy and backup systems are a perfect example of this. The threat analysis has to be done up front to understand what failures cause death, which cause inconvenience, and the redundancies and backup efforts go into those that have the more unfortunate outcome. Also just like software, system interdependency analysis is a big part of this.

        This is just basic

    • Yeah, this was covered in Fight Club.

    • Re: (Score:1)

      by MeBot ( 943893 )
      Threat modeling is usually more of a review of a feature design, and less about individual lines of code. The point is there *will* be bugs in any reasonably complex piece of code... how do you design in such a way that when those bugs do surface (or some of your design assumptions are proven false) there isn't a vulnerability there. That's where threat mitigation comes in. Just look at the WMF vulnerability. No matter how good or bad the code was for that feature, the design was flawed and that's what caus

  • At the end of the day, this process is about ensuring that our customer's machines aren't compromised. When we're deciding which threats need mitigation, we concentrate our efforts on those where the attacker can cause real damage."
    but I'm certain that the folks who wrote the blaster worm, and those that run huge botnets would like to buy this guy a beer or 12.

    • For high reliability code, you write code on the assumption that other code may have problems. You write code defensively. For any kind of complex system, people will make mistakes. Thus you have to continually verify program integrity and security in a multiply redundant manner. You don't wait until a trust barrier is crossed.

      For example, if I have an application controlling a power plant, even if the computer is already running "foreign" code at my privilege level, the control application may still b

    • Re: (Score:1, Troll)

      by jofny ( 540291 )
      Im just replying randomly to this post since it's as good as any other: Why do Slashdotters so often fail to differentiate between a company's business decisions and its technical capabilities? MS has a mature, well-developed threat modeling processes that works fine. That has little to do with which features are implemented in which time-frames, how well the QA on the final code is, whether or not they have to maintain backward compatitibility to feature sets and software which require old (bad) security m

      • Re: (Score:2)

        by Ajehals ( 947354 )
        Not sure why you are modded as 'Troll' but hey.

        I guess the issue at hand is that MS may well have a brilliant threat modelling process, it could be the best in the world for all I know, but it should feed back into all the areas it impacts upon (not saying it doesn't, just addressing your post.). It is not sufficient to have one or even a few great security procedures and practices if you are unable or unwilling to apply them consistently, or if they fail to address any given known or predictable issue. I

        • Re: (Score:2)

          by jofny ( 540291 )
          Completely agree with you. (And yeah, I thought I was making a legit point...but thats how Slashdot goes.) I guess I was arguing the same point from reverse: Yes, they dont put their whole package together very well (resulting in obvious defects), but that doesn't mean their threat modeling process is automatically junk - especially when so few organizations follow any sort of threat modeling process whatsoever. Everyone should!

      • Re: (Score:2)

        by drsmithy ( 35869 )

        Why do Slashdotters so often fail to differentiate between a company's business decisions and its technical capabilities?

        For the same reason they don't differentiate between "security problems" that are the result of actual design and/or coding flaws and "security problems" that are the result of end-user and developer error.

  • At the end of the day, this process is about ensuring that our customer's machines aren't compromised.
    <HEAD ASPLODES>
  • What he's really saying is they ran out of fingers to plug the holes in the dike,they have their dicks plugging the holes in their customer's ass, and the water is STILL rising.
  • misinterpreted 'threats modeling' as "a business modeling about threating the customers with the FUD against their competitors".

    In the article:

    Threat modeling is an analysis process that helps you better understand the attack surface of your component so you can understand what you need to do to ensure that your code is more secure.
    Apparently he's just talking about releasing service patches every time after being attacked.

    What a relief!
  • Microsoft made a big mistake when creating Windows, though not one most of us would have foreseen in the early '90s-- they made Windows 3.1 a single-user OS and thanks to their dedication to backwards-compatibility ended up being stuck with it. Now this poor guy has to figure out a way to make Microsoft software secure by default, even though they have 1) lots of idiots in their customer base to deal with and 2) too many legacy applications expecting root privileges to break backwards compatibility and set
    • Even if you were correct, it should not be that difficult for a company with Microsoft's money and personnel to solve.

      Just license some tech from VMWare or such.

      Build the NEW system to that it CORRECTLY conforms to security "best practices" and then incorporate "virtual machines" that can run those "legacy" apps under the OS they were designed for.

      Microsoft has already sort of tried this with "compatibility mode" and things like that. The problem is NOT the apps (as people claim). The problem is Microsoft'

      • Re: (Score:2)

        by cnettel ( 836611 )
        Apps are supposed to read and write user data. I can agree that this concept is flawed, it should be much more prevalent that an app defines a manifest or locks down its own token on load time to only be able to access things that really are relevant (possibly with some special breakout directly connected to the file chooser widget of choice). This is not common in any OS today. Most web browsers run with the full permissions of the user running them, enough to make it very hard for that user to create a bo

        • Re: (Score:2)

          by Allador ( 537449 )

          Most web browsers run with the full permissions of the user running them, enough to make it very hard for that user to create a botnet node or whatever. There are exceptions to this, but they are rare.

          Actually, this functionality you're describing has been present in Windows XP for years. Right click on IE, choose RunAs, and just leave the default and hit OK.

          You've not spawned an IExplore.exe process with very specific security tokens. Basically restrict it from writing anything at all to the registry, and nothing expect a very few locations on the hard drive (temp & cache space, basically).

          Vista makes it more prevalent, but its been there for years.

          Vista and Win2008 server also has a limited form

    • without Win3.0, there would never have been any subsequent versions on Windows. And for those of us who were Win3.0 adopters, I can tell you that is was a better OS in terms of cost, hardware, and applications than many of its peers: DOS, Novell, UNIX, MacOS5.
    • Microsoft made a big mistake when creating Windows, though not one most of us would have foreseen in the early '90s-- they made Windows 3.1 a single-user OS and thanks to their dedication to backwards-compatibility ended up being stuck with it.

      I will introduce you to a new technology for you to research. It is called NT and is over 15years old. Why the introduction, well if you are so stupid to still correlate Windows with 3.1 concepts then you obviously have no freaking idea what NT is.

      The argument you mak

    • Re: (Score:2)

      by Allador ( 537449 )

      ... set the OS up with Unix-style permissions.
      Why would anyone want to do that? Real ACLs are far superior to the old-fashioned (and overly simplistic and limiting) traditional unix permissions system.

      About the only downside to full ACLs is that the complexity is slightly higher.
  • "this process is about ensuring that our customer's machines aren't compromised."

    I cried tears of joy when I read about Microsoft dedicating so many of their resources to securing one customer's machines. It just shows how Steve "Big Hearted" Ballmer is steadily filling what was once a cold, impersonal monopolist with people who are willing to go not just an extra mile, but several extra parsecs to ensure that every one of their customers feels loved and cared for. I'm so very, very glad that there's a stil
    • Absolute class - thanks. It made me laugh.

      We have to be honest here - this IS innovation! Have you ever heard such quality BS from *any*, and I mean *any* other company? I mean, it's been tough since Enron's "I feel you pain" Shilling went the way of the Dodo, but Thank God we still have Microsoft churning out new way of selling complete and utter BS.

      I think we will all feel the loss when the EU finally hangs all of them (at least, that's what they make their conviction sound like :-).
      • "Lots of people did stick to Win2K instead of going to XP, and they were right to do so, XP was flaky."

        No, but that's only because there aren't any companies who've achieved Microsoft's level of success that need to explain why their entire product range has been so bad for so many years.

        "I mean, it's been tough since Enron's "I feel you pain" Shilling went the way of the Dodo, but Thank God we still have Microsoft churning out new way of selling complete and utter BS."

        MS have to keep producing BS screens l
  • I think we can all agree that actions have consequences, especially in an over-engineered software environment with layers upon layers of APIs and legacy code. - AH4H
  • Or rather for the use of ActiveX in the HTML control, particularly security zones.

    "Storing a file in the wrong place can lead to complete compromise... that's OK, if you download a file you really meant to run it anyway, so that's the user's fault."

  • Law #1 is a lie. (Score:2, Interesting)

    by zestyping ( 928433 )
    I see they're still using the old, tired, " Immutable Law #1 [microsoft.com]" that Scott Culp made up many years ago.

    Law #1: If a bad guy can persuade you to run his program on your computer, it's not your computer anymore
    [...]
    When you choose to run a program, you are making a decision to turn over control of your computer to it. Once a program is running, it can do anything, up to the limits of what you yourself can do on the computer.

    It's simply wrong, and it's deceptively named.

    One of the important jobs of any operating

  • Some improvements that could help:
    a)The default action for opening a document ( double click ) should not be the same as the default action for executing a binary ( double click ) and installing software ( yep, another double click ).
    b)Don't offer the option to execute binaries when you hit a link in the web browser. If the user wants to run a binary it goes: download -> execute ( again, not double click ).
    c)Try to avoid a situation which encourages the user to hit "Allow" without thinking.

    Oh, and finall
  • As Euclid said, "as you go about proving a theorem, it's important to consider the consequences of examining various cases. While it can be easy to find cases that need to be examined, it is important to realize that all cases have real-world consequences for the theorem. At the end of the day, this process is about ensuring that the time the theorem is mostly true at those time when it's most important to be true. When we're deciding which cases be tested, we concentrate our efforts on those where the theo
  • When we're deciding which threats need mitigation, we concentrate our efforts on those where the attacker can cause real damage

    Well, yeah, but there are so many threats against Microsoft software. So, why not just do it right in the first place? Why not create software without the possibility of buffer overflows and most other avoidable issues in the first place?

    • Re: (Score:2)

      by Allador ( 537449 )
      Are you kidding me?

      Probably the closest thing our race has ever seen to engineering that always 'does it right' the first time is NASA. And plenty of people have DIED on their ships. And they are arguably the most overfunded, overengineering, overly conversative R&D/engineering organization in the history of mankind.

      Bottom line is that 'doing it right' perfectly is not possible, at least not for larger-than-tiny systems. At least not in the current state of the art in systems software. If nothing el

      • Re: (Score:2)

        by m2943 ( 1140797 )
        I wish I could pull up some examples quickly, but not all buffer overflows are obvious.

        Buffer overflows are completely avoidable by using a language with bounds checks.

        Many millions of dollars per year flow into software/os/systems R&D to find a way to make a system impervious to these types of attacks, while still having an O/S that runs at a useful speed.

        The techniques for making buffer overflows impossible are well understood, and switching to languages that implement them does not cost you anything

        • Re: (Score:2)

          by Allador ( 537449 )

          Buffer overflows are completely avoidable by using a language with bounds checks.

          I notice that you dont actually name this language. Can you?

          What classes of buffer overflows does it protect against? Do you still have full access to pointers and memory reads/writes/copies? Do you have to give up direct manipulation of the stack?

          While I agree that it should (and will, eventually) be possible to write an operating system without the insanities of C-based languages, I'm definitely not aware of one. The only languages I'm aware of that even try to minimize the possibility are languages

          • Re: (Score:2)

            by m2943 ( 1140797 )
            I notice that you dont actually name this language. Can you?

            There are so many: Object Pascal, Oberon, Cedar/Mesa, Modula-3, and on and on.

            What classes of buffer overflows does it protect against?

            The memory corrupting kind.

            Do you still have full access to pointers and memory reads/writes/copies?

            Of course, you do. Safe programming languages don't prevent you from doing unsafe things, they merely make you ask for them explicitly.

            Do you have to give up direct manipulation of the stack?

            There is no "direct manip

            • Re: (Score:2)

              by Allador ( 537449 )

              There are so many: Object Pascal, Oberon, Cedar/Mesa, Modula-3, and on and on.

              Well, I guess we'll just be in fundamental disagreement there. Not sure I agree that you're going to be able to effectively write an O/S in object pascal. About the only thing going for it in this space is that you can include raw assembly in with it (IIRC) as part of the language.

              In fact, at least in its Delphi/Kylix form, this is much more of a user-space apps development language than a systems development language.

              The term "managed language" is some bizarre Microsoft neologism, and I have no idea what it's even supposed to mean.

              Hardly. Java would qualify as such. The defining characteristic is that its inteded

              • Re: (Score:2)

                by m2943 ( 1140797 )
                Is it possible that writing an O/S using

                Go read up on your OS history: the majority of commercial server and desktop operating systems over the last 50 years have been written in high level languages. We don't have to "guess" whether it's fast enough--it is. We don't have to guess how much assembly language it takes--we know (it takes very little). We don't have to guess whether it prevents buffer overflows and many of the ills that afflict Windows, UNIX, and Linux--it does.

                Hardly. Java would qualify as
        • I don't disagree with you completely, but while C's lack of natural bounds checking is a major weakness, bounds checking can easily be designed into the architecture using a simple "if (OFFSET_EXPRESSION BUFFER_LIMIT) PERFORM_BUFFER_OPERATION (buffer [OFFSET_EXPRESSION]);" where OFFSET_EXPRESSION is whatever the expression that determines the offset is, excluding any offset advance codes, and adding a "+ VALID_OFFSET_INCREASE" to the end if the advance code is done before the expression is used, and PERFOR

    • Re: (Score:1)

      by cepayne ( 998850 )
      Simply have microsoft make its slaves "code in" proper error checking for their routines in the first place... Then they won't have to issue hundreds of patches every week, and the users PC's just might be a little more secure.

Slashdot Top Deals

We are Microsoft. Unix is irrelevant. Openness is futile. Prepare to be assimilated.

Close