Microsoft Drops Next-Generation Security Project [updated]

grooveFX points to this CRN article which starts "After a year of tackling the Windows security nightmare, Microsoft has killed its Next-Generation Secure Computing Base (NGSCB) project and later this year plans to detail a revised security plan for Longhorn, the next major version of Windows, company executives said..." grooveFX writes "Glad to see they actually listen to the gripes from the media and users." Update: 05/05 19:13 GMT by T : phil reed writes "Oops. According to this article on Microsoft Watch, Microsoft really isn't giving up on NGSCB (aka 'Palladium') after all. Microsoft spent much of Day 2 of its Windows Hardware Engineering Conference (WinHEC) here refuting a published report claiming the company has axed its Next Generation Secure Computing Base (NGSCB) security technology."

Comments

Palladium

[Nexum]

Isn't NGSCB Palladium?

Surely this is pretty good news and indicates that MS might not be so able to force these kind of security measures on their custimers.

Although I imagine knowing Microsoft, the problems were at least as much technical than political, and they just gave up considering it to be "too hard and we can't be arsed", just like WinFS.

RTFA

[Dynedain]

This is Palladium, and it has not been "dropped", only shelved because it was too ambitious. They say they've invested too much on this not take advantage of it.

Possibly already too late

[ites]

We are getting to the stage where a fair chunk of PCs connected to the Internet are destined to die. It's reasonable to assume that MS has performed a kind of triage: - Home PCs are beyond the reach of any help. Whatever is done is already too late. Home PC users will have to migrate to Linux within 6-12 months or face working without the Internet. - SMEs can be protected with additional work. SMEs need better firewall security and better patching methods. - Most enterprise computing is safe as is. Many data centers will switch away from Windows for cost and reliability issues but the ones that can't will remain faithful Windows clients. So Microsoft has to concentrate on helping the people who can still be saved, namely SMEs that have several PCs behind a shared internet connection. Having seen three of my friends' PCs dead today from Sasser (MSIE rebooting without end, and no way to do anything else on the system), I'm rather sceptical that home computing can be saved.

Re:A few suggestions

[Chanc_Gorkon]

First off:

1. Dumping Features would break lots of stuff. I suggest that they don't ADD any more and fix what they got!

2. Um, gcc prevents this?? There's no language that prevents these types of things. Even if you write with a language that supposedly does not have Buffer Overflows, you still rely on other modules that were written in a language that does allow them ot happen.

3. UNIX and Linux both have 20 ways to do things as well. It's called choice. You choose the best for your situation. I think what you mean is that ActiveX components used on the web should never be allowed to stray out of the web sandbox nor should they be allowed to execute code. And another thing...the mail client should NEVER be allowed to execute code with out asking the user forty times!

It's time to tighten up C++

[Animats]

Stop using languages/tools that allow you have buffer overflows in code. That'll cut out 90% of critical updates in one swoop.

Yes. I've been trying to get the C++ committee to tighten up that language for years, with little success. It's time to get more serious about this, and apply pressure via ANSI (which is supposed to insure that standards are safe) and the Department of Homeland Security's National Cyber Security Division. Like it or not, we need to go to full subscript checking for anything that could possibly be exploited. The resulting 10-20% performance hit is minor compared to the costs of dealing with these attacks.

I've sent this to the C++ committee:

• After the damage caused by the Sasser worm, the latest in a long series of buffer overflow exploits, perhaps the designed-in lack of safety in C++ should be reconsidered.

  The Sasser worm exploits a buffer overflow in Microsoft's LSASS service, which is, apparently, written in C++.

  Perhaps more weight should be given by the Standards Committee to tightening up C++ and making it a safer language. The Committee has consistently rejected most suggestions which tighten up the language, usually on the grounds that they would impact existing code or prevent some dangerous but valid code from being used.

  It is now appropriate to ask ANSI, and the Department of Homeland Security's National Cyber Security Division, to reevaluate the C++ committee's priorities in the light of the documented and substantial damage caused by weak safety features of the language. Whether the committee should be permitted to promulgate unsafe technologies with ANSI approval must be seriously questioned at this point.

That will probably be ineffective. The appropriate forum will probably be Congressional hearings on computer security, which were threatened last year after the SOBIG virus, and are likely to happen this year.