Minder openheid over softwarefouten?
In elk computerprogramma zitten fouten. Moeten gebruikers en hackers die fouten alleen aan de producent melden, of juist aan de grote klok hangen? De internetgemeenschap wil openheid, maar grote softwarebedrijven als Microsoft vinden dat slecht voor hun imago. Microsoft probeert nu via een industriële lobby zijn standpunt tot richtlijn te verheffen.
(dit artikel is eerder gepubliceerd op Netkwesties.nl)
Vorige week heeft de Organization for Internet Safety een draft Security Vulnerability Reporting and Response Process gepubliceerd. Daarin staat een voorstel hoe beveiligingsdeskundigen en gebruikers fouten in computerprogramma’s zouden moeten rapporteren. De OIS vraagt de internetgemeenschap binnen 30 dagen te reageren op dit voorstel.
De voorgestelde richtlijn is vooral bedoeld om hackers buitenspel te zetten. De laatste jaren is het steeds gebruikelijker geworden dat iemand die een fout vindt direct de publiciteit zoekt en zijn vondst niet eerst in vertrouwen aan de producent meldt. Daardoor zouden hackers belangrijke informatie in handen krijgen en, nog voordat de fout is gerepareerd, kunnen inbreken op een server of een heel netwerk.
De OIS wil nu dat ontwikkelaars eerst de kans krijgen om het lek te dichten voordat een fout algemeen bekend is geworden. In de beveiligingswereld staat dit principe bekend als bug secrecy (of security through obscurity: problemen moet je niet aan de grote klok hangen, want dat zou de algemene veiligheid in gevaar brengen. De tegenhanger van dit standpunt is full disclosure: fouten moeten zo snel mogelijk in het nieuws komen, want daar is iedereen mee gebaat.
Ontwikkelaars krijgen van de OIS 30 dagen de tijd om een gevonden fout in hun software te verhelpen. Degene die de fout heeft gevonden mag het lek pas daarna bekend maken. Daarmee kiest de richtlijn in principe voor geheimhouding, maar met enkele kleine concessies richting de voorstanders van openheid.
Eerdere poging
De Security Vulnerability Reporting and Response Process is ook in een ander opzicht een compromis. Het stuk is in de eerste plaats een richtlijn en niet meer dan dat. Een procedure om het naleven van deze richtlijn af te dwingen is er niet.
Een eerdere poging van enkele softwaremakers, Mitre en @stake, om wél bindende richtlijnen op te stellen mislukte. In februari 2002 ging een voorstel richting de Internet Engineering Task Force (IETF), een internationaal netwerk van producenten, netwerkbeheerders en onderzoekers. Het IETF wees het echter af, omdat de voorgestelde richtlijn zo ver ging dat het niet meer binnen de bevoegdheden van deze organisatie paste.
OIS-lobby
De Organization for Internet Safety is vorig jaar in het leven geroepen door onder meer Microsoft. Er zitten nog meer softwarereuzen in, zoals OracleSymantec en Network Associates. Vanaf het begin was duidelijk dat de coalitie zou gaan strijden tegen openheid over softwarefouten.
Het standpunt van Microsoft was al langer bekend. In het najaar van 2001 schreef Scott Culp, een hoge beveiligingsfunctionaris van Microsoft, een pleidooi voor geheimhouding, dat veel aandacht trok. Openheid over softwarefouten zou volgens hem leiden tot “informatie-anarchie”.
Culp had op zich goede argumenten voor zijn standpunt. Al in de inleiding verwijst hij naar beruchte computerwormen als Code Red, Ramen en Nimda. Hackers hadden deze wormen gemaakt, nadat deskundigen op openbare mailinglijsten, zoals BugTraq, informatie over kwetsbaarheden hadden gepubliceerd, zonder eerst Microsoft in de gelegenheid te stellen daar wat aan te doen.
Vooral Code Red en Nimda hebben het bedrijfsleven veel schade toegebracht, volgens Symantec zelfs zo’n 635 miljoen dollar. Maar ondanks dit sterke economische argument had Culp verder alle schijn tegen. Microsoft komt veelvuldig in het nieuws wegens beveiligingsproblemen. Zijn betoog leek vooral bedoeld om het slechte imago van zijn broodheer weer wat op te vijzelen.
Openheid versus geheimhouding
De controverse tussen ‘bug secrecy’ en ‘full disclosure’ is oud en duurt in feite al vanaf de introductie van de IBM PC in 1981. In de jaren 80 was geheimhouding nog vanzelfsprekend. Wie een fout vond in een programma lichtte de producent stilletjes in. Voor klachten over andere producten dan software ga je immers ook gewoon terug naar de winkel en stuur je niet gelijk een brief naar de krant.
In 1988 werd het Computer Emergency Response Team (CERT) opgericht en werd het doorgeven van softwarefouten meer gecentraliseerd. Onderzoekers en hackers konden hun bevindingen melden bij het CERT. Deze organisatie verifieerde alle meldingen en stuurde ze door naar de betreffende producenten.
En daar ging het mis: het CERT drong bij de ontwikkelaars wel aan op reparatie binnen 45 dagen, maar was zo netjes om de fouten zolang geheim te houden. Iets té netjes, zo bleek, want veel ontwikkelaars hadden inmiddels andere prioriteiten en lieten de fouten gewoon liggen. Als je er maar geen ruchtbaarheid aan geeft, dan heeft niemand een probleem, zo leek de gedachtengang.
Maar dankzij de snelle opmars van internet in de jaren 90 kregen de gebruikers veel meer macht. Ze ergerden zich aan de gemakzuchtige houding van de ontwikkelaars en gebruikten mailinglijsten en websites om gevonden fouten algemeen bekend te maken, vaak nog voordat de softwaremakers op de hoogte waren gesteld.
CERT
Het CERT kreeg ook om andere redenen kritiek te verduren. Zolang ontwikkelaars een gevonden bug nog niet hebben opgelost, gaat CERT er vertrouwelijk mee om. Maar niet helemaal: wie ervoor betaalt, krijgt wél alle informatie over de nog niet opgeloste bugs. En de betalende klanten kunnen die informatie weer doorspelen aan anderen.
Naar alle waarschijnlijk gebeurde dat begin dit jaar, toen onderzoeker Riley Hassell van eEye Digital Security een bug aan het CERT rapporteerde, maar deze lekte uit naar een mailinglijst. Dit incident leidde tot boze reacties uit de beveiligingswereld.
Onderzoeker Mark Litchfield schreef daarop een brief dat hij nooit meer een fout aan het CERT zou melden. Ook Next Generation Security Software (NGSS) verbrak de banden met het CERT.
Verdeeldheid
Sinds een jaar of tien is ‘full disclosure’ dus de norm. Vorig jaar bleek uit onderzoek dat het overgrote deel van de gebruikers en beveiligingsdeskundigen volledige openheid wenst. Gevonden fouten zouden direct moeten worden gepubliceerd, ook als is de producent daar niet blij mee.
Maar de meningen blijven verdeeld, zoals blijkt uit het betoog van Scott Culp. En ook elders wordt getwijfeld. Beveiligingsdeskundige Arne Vidstrom zet in zijn paper Full Disclosure of Vulnerabilities alle voors en tegens vrij gedegen op een rijtje. Hij concludeert dat het vooral van de omstandigheden afhangt welke aanpak de beste is.
Ook de gezaghebbende beveiligingsdeskundige Bruce Schneier heeft meer dan eens over deze discussie geschreven. Volgens Schneier zijn absolute geheimhouding en volledige openheid geen van beide ideale oplossingen, omdat ze allebei enorme economische gevolgen hebben. Geheimhouding leidt tot inferieure software, maar openheid leidt tot miljardenschade door virussen en wormen.
Toch neigt Schneier uiteindelijk meer naar ‘full disclosure’. Zijn mening is vooral pragmatisch: in de jaren 80 bleek geheimhouding domweg niet te functioneren, maar juist openheid in de jaren 90 heeft ervoor gezorgd dat bedrijven veel alerter reageren en meer tijd en geld steken in het opsporen en repareren van programmeerfouten.
Verantwoordelijkheid
Per saldo lijkt de waarheid dus ergens in het midden te liggen, al blijft de vraag waar precies. Microsoft en de andere deelnemers van de OIS-lobby neigen naar geheimhouding met een klein beetje openheid; Schneier en veel andere deskundigen willen vooral openheid met een klein beetje geheimhouding.
Het enige waarover alle partijen het vooralsnog eens zijn is over het belang van verantwoordelijkheid. Zowel ontwikkelaars als gebruikers moeten verantwoordelijk omgaan met gevonden fouten: ontwikkelaars moeten ze zo spoedig mogelijk verhelpen en gebruikers mogen ontwikkelaars geen schade toebrengen door gevoelige informatie door te spelen naar andere partijen die er misbruik van kunnen maken.
Minder openheid over softwarefouten?
In elk computerprogramma zitten fouten. Moeten gebruikers en hackers die fouten alleen aan de producent melden, of juist aan de grote klok hangen? De internetgemeenschap wil openheid, maar grote softwarebedrijven als Microsoft vinden dat slecht voor hun imago. Microsoft probeert nu via een industriële lobby zijn standpunt tot richtlijn te verheffen.
(dit artikel is eerder gepubliceerd op Netkwesties.nl)
Vorige week heeft de Organization for Internet Safety een draft Security Vulnerability Reporting and Response Process gepubliceerd. Daarin staat een voorstel hoe beveiligingsdeskundigen en gebruikers fouten in computerprogramma’s zouden moeten rapporteren. De OIS vraagt de internetgemeenschap binnen 30 dagen te reageren op dit voorstel.
De voorgestelde richtlijn is vooral bedoeld om hackers buitenspel te zetten. De laatste jaren is het steeds gebruikelijker geworden dat iemand die een fout vindt direct de publiciteit zoekt en zijn vondst niet eerst in vertrouwen aan de producent meldt. Daardoor zouden hackers belangrijke informatie in handen krijgen en, nog voordat de fout is gerepareerd, kunnen inbreken op een server of een heel netwerk.
De OIS wil nu dat ontwikkelaars eerst de kans krijgen om het lek te dichten voordat een fout algemeen bekend is geworden. In de beveiligingswereld staat dit principe bekend als bug secrecy (of security through obscurity: problemen moet je niet aan de grote klok hangen, want dat zou de algemene veiligheid in gevaar brengen. De tegenhanger van dit standpunt is full disclosure: fouten moeten zo snel mogelijk in het nieuws komen, want daar is iedereen mee gebaat.
Ontwikkelaars krijgen van de OIS 30 dagen de tijd om een gevonden fout in hun software te verhelpen. Degene die de fout heeft gevonden mag het lek pas daarna bekend maken. Daarmee kiest de richtlijn in principe voor geheimhouding, maar met enkele kleine concessies richting de voorstanders van openheid.
Eerdere poging
De Security Vulnerability Reporting and Response Process is ook in een ander opzicht een compromis. Het stuk is in de eerste plaats een richtlijn en niet meer dan dat. Een procedure om het naleven van deze richtlijn af te dwingen is er niet.
Een eerdere poging van enkele softwaremakers, Mitre en @stake, om wél bindende richtlijnen op te stellen mislukte. In februari 2002 ging een voorstel richting de Internet Engineering Task Force (IETF), een internationaal netwerk van producenten, netwerkbeheerders en onderzoekers. Het IETF wees het echter af, omdat de voorgestelde richtlijn zo ver ging dat het niet meer binnen de bevoegdheden van deze organisatie paste.
OIS-lobby
De Organization for Internet Safety is vorig jaar in het leven geroepen door onder meer Microsoft. Er zitten nog meer softwarereuzen in, zoals OracleSymantec en Network Associates. Vanaf het begin was duidelijk dat de coalitie zou gaan strijden tegen openheid over softwarefouten.
Het standpunt van Microsoft was al langer bekend. In het najaar van 2001 schreef Scott Culp, een hoge beveiligingsfunctionaris van Microsoft, een pleidooi voor geheimhouding, dat veel aandacht trok. Openheid over softwarefouten zou volgens hem leiden tot “informatie-anarchie”.
Culp had op zich goede argumenten voor zijn standpunt. Al in de inleiding verwijst hij naar beruchte computerwormen als Code Red, Ramen en Nimda. Hackers hadden deze wormen gemaakt, nadat deskundigen op openbare mailinglijsten, zoals BugTraq, informatie over kwetsbaarheden hadden gepubliceerd, zonder eerst Microsoft in de gelegenheid te stellen daar wat aan te doen.
Vooral Code Red en Nimda hebben het bedrijfsleven veel schade toegebracht, volgens Symantec zelfs zo’n 635 miljoen dollar. Maar ondanks dit sterke economische argument had Culp verder alle schijn tegen. Microsoft komt veelvuldig in het nieuws wegens beveiligingsproblemen. Zijn betoog leek vooral bedoeld om het slechte imago van zijn broodheer weer wat op te vijzelen.
Openheid versus geheimhouding
De controverse tussen ‘bug secrecy’ en ‘full disclosure’ is oud en duurt in feite al vanaf de introductie van de IBM PC in 1981. In de jaren 80 was geheimhouding nog vanzelfsprekend. Wie een fout vond in een programma lichtte de producent stilletjes in. Voor klachten over andere producten dan software ga je immers ook gewoon terug naar de winkel en stuur je niet gelijk een brief naar de krant.
In 1988 werd het Computer Emergency Response Team (CERT) opgericht en werd het doorgeven van softwarefouten meer gecentraliseerd. Onderzoekers en hackers konden hun bevindingen melden bij het CERT. Deze organisatie verifieerde alle meldingen en stuurde ze door naar de betreffende producenten.
En daar ging het mis: het CERT drong bij de ontwikkelaars wel aan op reparatie binnen 45 dagen, maar was zo netjes om de fouten zolang geheim te houden. Iets té netjes, zo bleek, want veel ontwikkelaars hadden inmiddels andere prioriteiten en lieten de fouten gewoon liggen. Als je er maar geen ruchtbaarheid aan geeft, dan heeft niemand een probleem, zo leek de gedachtengang.
Maar dankzij de snelle opmars van internet in de jaren 90 kregen de gebruikers veel meer macht. Ze ergerden zich aan de gemakzuchtige houding van de ontwikkelaars en gebruikten mailinglijsten en websites om gevonden fouten algemeen bekend te maken, vaak nog voordat de softwaremakers op de hoogte waren gesteld.
CERT
Het CERT kreeg ook om andere redenen kritiek te verduren. Zolang ontwikkelaars een gevonden bug nog niet hebben opgelost, gaat CERT er vertrouwelijk mee om. Maar niet helemaal: wie ervoor betaalt, krijgt wél alle informatie over de nog niet opgeloste bugs. En de betalende klanten kunnen die informatie weer doorspelen aan anderen.
Naar alle waarschijnlijk gebeurde dat begin dit jaar, toen onderzoeker Riley Hassell van eEye Digital Security een bug aan het CERT rapporteerde, maar deze lekte uit naar een mailinglijst. Dit incident leidde tot boze reacties uit de beveiligingswereld.
Onderzoeker Mark Litchfield schreef daarop een brief dat hij nooit meer een fout aan het CERT zou melden. Ook Next Generation Security Software (NGSS) verbrak de banden met het CERT.
Verdeeldheid
Sinds een jaar of tien is ‘full disclosure’ dus de norm. Vorig jaar bleek uit onderzoek dat het overgrote deel van de gebruikers en beveiligingsdeskundigen volledige openheid wenst. Gevonden fouten zouden direct moeten worden gepubliceerd, ook als is de producent daar niet blij mee.
Maar de meningen blijven verdeeld, zoals blijkt uit het betoog van Scott Culp. En ook elders wordt getwijfeld. Beveiligingsdeskundige Arne Vidstrom zet in zijn paper Full Disclosure of Vulnerabilities alle voors en tegens vrij gedegen op een rijtje. Hij concludeert dat het vooral van de omstandigheden afhangt welke aanpak de beste is.
Ook de gezaghebbende beveiligingsdeskundige Bruce Schneier heeft meer dan eens over deze discussie geschreven. Volgens Schneier zijn absolute geheimhouding en volledige openheid geen van beide ideale oplossingen, omdat ze allebei enorme economische gevolgen hebben. Geheimhouding leidt tot inferieure software, maar openheid leidt tot miljardenschade door virussen en wormen.
Toch neigt Schneier uiteindelijk meer naar ‘full disclosure’. Zijn mening is vooral pragmatisch: in de jaren 80 bleek geheimhouding domweg niet te functioneren, maar juist openheid in de jaren 90 heeft ervoor gezorgd dat bedrijven veel alerter reageren en meer tijd en geld steken in het opsporen en repareren van programmeerfouten.
Verantwoordelijkheid
Per saldo lijkt de waarheid dus ergens in het midden te liggen, al blijft de vraag waar precies. Microsoft en de andere deelnemers van de OIS-lobby neigen naar geheimhouding met een klein beetje openheid; Schneier en veel andere deskundigen willen vooral openheid met een klein beetje geheimhouding.
Het enige waarover alle partijen het vooralsnog eens zijn is over het belang van verantwoordelijkheid. Zowel ontwikkelaars als gebruikers moeten verantwoordelijk omgaan met gevonden fouten: ontwikkelaars moeten ze zo spoedig mogelijk verhelpen en gebruikers mogen ontwikkelaars geen schade toebrengen door gevoelige informatie door te spelen naar andere partijen die er misbruik van kunnen maken.
Lees ook: