NYT over Microsofts Security Response Center

De New York Times heeft een kijkje achter de schermen genomen bij het Security Response Center van Microsoft Het SRC van Microsoft is net een soort ziekenhuis. Is de gevonden bug ernstig of is de patient niet zo ziek, is de vraag die ze daar stellen. Een team van specialisten staat dag en nacht klaar om gevaarlijke lekken zo snel mogelijk te analyseren en te dichten. De fout waar de Blaster worm gebruik van maakte, is een voorbeeld van een probleem wat in dit centrum een hoge prioriteit zal krijgen. Na de analyse en een aantal tests wordt er een patch gemaakt. Als de update in orde is kunnen de getroffen klanten worden ingelicht. In het SRC van Microsoft worden problemen achteraf aangepakt, vooraf betere code produceren is een andere optie.

Software al van te voren veiliger en betrouwbaarder maken is geen gemakkelijke taak maar wel haalbaar, zo zeggen analisten. Behalve het technisch aspect van deze problematiek zal er ook een mentaliteitsverandering nodig zijn. Op dit moment is het normaal om het product eerst te bouwen en te laten werken en daarna pas de problemen op te lossen. Ook de complexiteit, tijdsdruk waaronder men vaak werkt en het hergebruik van oude code spelen hierin een rol. Het mentaliteitsprobleem begint echter al bij opleidingen en studieboeken. Shawn Hernan, beveiligingsspecialist van CERT heeft vaak maar een paar minuten nodig om de fouten uit een leerboek boven water te halen:

Yet years of steady progress in the quality of software engineering will be needed for big gains in security and reliability to become apparent. And it starts with education, noted Shawn Hernan, a security specialist at CERT. He makes a game of seeing how quickly he can find security vulnerabilities in the programming examples used in college textbooks. It rarely takes him more than few minutes.

"The textbook examples are riddled with vulnerabilities," Mr. Hernan noted. "Computer science culture is based on, build it, get it working and fix it later. We need a culture change away from the cowboy and toward the engineer."

Reacties (13)

[siepeltjuh]

In het SRC van Microsoft worden problemen achteraf aangepakt, vooraf betere code produceren is een andere optie. `

En DAT is nu juist wat ik zo jammer vind aan microsoft (niet dat ze de enige zijn)

[Verwijderd]

Duh, dit artikel gaat over het security response center.

Wat ik zie van Microsoft is dat ze security toch serieus opgepakt hebben en daar ook grote vooruitgang in boeken. Moet ook wel, want anders zouden ze veel klanten kwijtraken.

[Verwijderd]

Als ik mij niet vergis roept MS al meer dan een jaar dat ze aan veiligheid gaan werken maar ondertussen is Augustus toch al door de pers de historische virusmaand genoemd en zitten we nu weer met Swen.

MS is zoals politiek: veel beloven en weinig doen...alleen nog erger.

[Verwijderd]

Wat heeft Swen te maken met fouten van Microsoft? Tis een attachement die de gebruiker zelf moet openen en moet uitvoeren.

[Verwijderd]

Attachements die zomaar achter de rug van gebruiker om kunnen mailen zonder dat er een "deze applicatie wil gebruik maken van een smtp server via dll, mag dat/nooit meer vragen" dialoog veroorzaakt 90% van alle problemen wereldwijd. Kinderlijk makkelijk in te bouwen, MS weigert dit. Voorbeeld van fundamentele verkeerde aanpak van MS, namelijk de koppige houding van "moet je maar patchen". Dat is achter de feiten aanlopen en constructiefouten verbeteren onder het mom van "udpates" alsof je software versleten is na zoveel maanden.

Precies waar dit artikel kritiek op heeft.

[Verwijderd]

Hmm, dit is de uitloop van de eeuwenoude discussie tussen de veilige computer die constant controleert of de gebruiker wel echt wil doen wat hij doet en de computer die gewoon luistert. Het zijn gebruikers die opdracht geven Swen uit te voeren. Denk je nu echt dat deze randde.. dat niet zouden doen als er eerst wordt gevraagd of er mail mag worden verstuurd? "Zal wel kloppen, komt toch van Microsoft?" zullen ze denken! Die "oplossing" van jou lost dus niets op. Ik vraag me ook af hoe dom jij precies gevonden wil worden door je computer, want ik vrees dat jij je al irriteert aan de bevestigingsdialoog als je bestanden verwijdert...

Wat Microsoft wel zou moeten doen (en inmiddels ook doet dankzij Trustworthy Computing) is security vantevoren inbouwen. Daar zien we nu nog geen resultaten van en het is maar de vraag of Longhorn niet al te vroeg in ontwikkeling was. Randgevolgen zien we wel. Kijk naar Windows 2003: standaard helemaal dichtgezet, in plaats van open. Maar het Security Response Team zal nooit en te nimmer vantevoren actie ondernemen, dus die hele kritiek die hier geuit wordt slaat nergens op!

[Verwijderd]

Lekker makkelijk zeggen als je de ballen verstand hebt van programmeren. Het is praktisch onmogelijk bugloze code aan te leveren (zoek wetenschappelijke publicaties maar door als je het niet gelooft), wanneer snappen mensen nu dat ze enkel die bugs zien die NIET gerepareerd zijn en niet de duizenden bugs en lekken die MS e.d. al vér vantevoren repareerd?

Bugs en lekken zijn problemen in programmatuur, per definitie moet de programmatuur er dus zijn vóór er bugs of lekken zijn.

Het is net zoiets als met een oude auto in de autogarage gaan klagen dat ze de auto eigenlijk al vóór de verkoop hadden moeten repareren.

Net zoals een auto is software aan slijtage onderhevig, de externe factoren zijn echter niet weer en gebruik maar hackers en vooruitgang (kijk maar naar brute force methodes; jaartje of 10 geleden zowat onmogelijk).

[AlterEgo]

offtopic:
Ik zou het prettig vinden als bij links in artikelen vermeld zou staan of je je moet registreren (zoals bij NYT het geval is).

Het pleidooi tegen hergebruik vind ik een beetje kort door de bocht:
beproefde technologie hergebruiken hoeft zeker niet per definitie gevaarlijker te zijn dan code-from-scratch.

[Verwijderd]

Code hergebruiken hoeft inderdaad niet per definitie slecht te zijn. Maar het kan ook het geval zijn dat deze code achterhaald is voor de huidige hardware. Iets wat nog al eens bij embedded software gebeurt. Zo was dat ongeluk met het prototype van de Arianne raket hieraan te wijten. Ze hadden wat code van de oude raket gebruikt voor de besturing. Alleen deze code was 8bits ofzo, en de rest van de raket werkte met 16bits. Software werd niet herkent, poef, weg raket, weg paar miljoen. Natuurlijk wel een misser van jewelste

[LaMoS]

mss even offtopic, maar toch interessant:

de Ariane 5 raket van ESA die ze daar hebben opgeblazen was de eerste die ging worden gelanceerd, nr. 501.
Ze hadden software voor de besturing van de gyroscopen (daarmee kan de raket zien welke weg hij aflegt en zo ook waar hij op dit moment zit) uit de Ariane 4 overgenomen, maar... de Ariane 5 vertrekt veel sneller als de 4. Software was niet daarvoor aangepast, software kan niet meer volgen en de raket begon al na een paar seconden uit zijn baan af te wijken. Dus hebben ze hem laten ontploffen (daarom dat lanceerbasisen ver weg van bewoond gebied staan, of zo veel mogelijk zee errond).

Men papa heeft bij ESA in Noordwijk gewerkt , kheb die lancering nog daar mee op het groot scherm gevolgd...

[Verwijderd]

Hehehehehehe, wil je hiermee vertellen dat ze iedere Windows PC maar moeten opblazen

[Max|Burn]

goh vreemd ik heb de patch daarvoor in mei gedownload, de virussen kwamen grofweg 3 maanden later. (in het wild)