Vijf dilemma's van lekken onthullen
Je ontdekt een lek, bent geen crimineel, en wat doe je? Braaf melden en stilhouden? Melden en eisen stellen? Of onthullen? Het is hoe dan ook ellende. Vijf dilemma's van disclosure.
Je ontdekt een lek, bent geen crimineel, en wat doe je? Braaf melden en stilhouden? Melden en eisen stellen? Of onthullen? Het is hoe dan ook ellende. Vijf dilemma's van disclosure.
Vijf dilemma's van lekken onthullen
Je ontdekt een lek, bent geen crimineel, en wat doe je? Braaf melden en stilhouden? Melden en eisen stellen? Of onthullen? Het is hoe dan ook ellende. Vijf dilemma's van disclosure.
Het is een fundamenteel twistpunt dat al bestaat zolang er ict is. Moeten security-onderzoekers lekken melden bij de maker van een product, of moeten ze ermee naar buiten treden? En dan onder eigen naam, of juist anoniem? Hiertussenin zitten nog overlopende en overlappende opties. Zoals: melden en de maker een deadline geven, of melden vlak voor - of tegelijk met - de publieke onthulling. Full disclosure versus responsible disclosure.
Luie leveranciers
Onthulling moet, want anders worden lekken nooit of veel te laat gepatched. Beweren de voorstanders van full disclosure, veelal zelf security-onderzoekers. Ze hebben daar wel een punt. Het kan weken, zo niet maanden duren voordat een gat gedicht wordt. Of zelfs jaren. Klinkt overdreven? Is het niet. Kijk maar naar dit 8 jaar oude lek, of deze van 17 jaar oud. Goed, die twee extreme voorbeelden zijn niet al die jaren bekend geweest en open gehouden.
Toch vertegenwoordigen gaten plots en dringend ontwikkelwerk, waar veel ict-leveranciers niet op zitten te wachten. Werk aan een product wat allang 'af' was. Denk aan de arme ontwikkelaars bij Microsoft die nog aan het antieke Windows XP moeten sleutelen, met alle beperkingen van dat oude besturingssysteem.
Bovendien hebben die bedrijven vaak een planning waarbij ze aan de volgende versie van hun product werken, dat meer biedt en sneller is maar ook weer veiliger. Sommige bedrijven gaan daarin zo ver dat ze security updates uitbrengen als integraal onderdeel van de nieuwe versie. De oudere voorganger staat dan in de kou, terwijl de gaten daarin dus wel gedicht kúnnen worden. Maar wat levert dat de leverancier op? Niet een verkoop van het nieuwe product.
Liever werken de ondernemingen in hun eigen tempo aan zaken die ze zelf ontdekken, bepalen, van een weging voorzien en dan inplannen. Het ritme van kwartaal- of maandupdates voor veelgebruikte programmatuur zoals Windows, Flash, Adobe Reader en Oracle is er heus niet alleen voor de voorspelbaarheid en het gemak van beheerders. Want dan zouden de verschillende leveranciers elkaars cyclus moeten mijden, om de ict'ers wat te ontzien.
Obscuur
Sterker nog, lekken liever niet (meteen) patchen en zeker niet onthullen is de strategie van de ict-leveranciers. Hun business model. Van de meeste dan. Jawel, het gehekelde security through obscurity. Geheimhouden hoe dingen werken, vooral en zeker de beveiliging, om daarmee ook zwakke plekken en gaten ook geheim te houden. Zodat een product of technologie veilig is.
Probleem is dat tegenwoordig iedereen slotenmaker kan zijn, en dus ook inbreker. De tools om sloten te analyseren en te verbeteren maar ook kraken zijn niet voorbehouden aan gecertificeerde en (dus) bekende slotenmakers. Het woord hacker is al jaren terug ingewisseld voor cracker, waar de echte hackers zich mateloos aan kunnen storen.
Daarbij is nog de categorie 'script kiddie' gekomen, iemand die niet zelf hackt of crackt maar simpelweg wat scripts en tools van anderen toepast. En door de voortschrijdende technologie is dat steeds vaker het geval. Je hoeft immers ook niet meer te kunnen programmeren om een computer te bedienen. Je hoeft dus ook niet echt zelf te kunnen hacken om een beveiligingstool annex inbreekkit als Metasploit te draaien.
Tuurlijk, het ontdekken van gaten is een meer complex werkje. Maar ook dat kunnen veel meer mensen tegenwoordig. En door de criminalisering van de hack- en malwarescene is er ook veel meer incentive. In sommige landen met lage lonen, slechte economieën en andere financiële hordes is voor een technisch onderlegd iemand dan ook moeilijk om white hat te zijn en blijven. Het carrièrepad leidt bijna vanzelf naar de gray of dark side. Beveiliging middels stilhouden, is niet meer houdbaar.
Afhankelijkheden
Nu even de andere kant. 'Responsible disclosure' klinkt misschien als een slap excuus van luie leveranciers om de doofpotstrategie te hanteren. Maar er komt veel meer kijken bij het analyseren en dichten van een gat dan bij het 'simpelweg' ontdekken ervan. Eerst moet de ontdekking van het lek worden gereconstrueerd, dan moet de exacte en verdere impact worden bepaald.
Daarna kan pas aan het echte dichtwerk worden begonnen, wat ook weer meerdere stappen omvat. Niet onbelangrijk, en erg tijdrovend, daarbij is het testen van de gemaakte patch of lapmethode. Want wat heeft die voor impact? Op de rest van het product, en op andere producten die in combinatie daarmee worden gebruikt. Het is een serieus ontwikkelproces, met procedures.
Kijk ook eens naar de recente XP-vastlopers door een patch van Microsoft. Dat blauwe scherm des doods (BSOD) bleek dus niet veroorzaakt door die patch, maar door een slordig gemaakte rootkit. Een stuk malware dat juist vanwege het gedichte gat ineens de hele, gep0wnede Windows-installatie onderuit haalde. Goed, een softwaremaker kan en moet op veel testen, maar op een infectie door een rootkit?
Het zijn niet alleen de grote, commerciële marktpartijen zoals Microsoft, Apple, Adobe en Oracle die vóór - al dan niet voorlopig - stilzwijgen zijn. In juli 2008 heeft Linux-schepper Linus Torvalds zich nog uitgesproken over deze kwestie. Opvallend genoeg is hij vóór stilhouden! Daarmee dus ingaand tegen het open source-mantra dat openheid het hoogste goed is en juist de beveiliging ten goede komt.
Patchtijd
Bedenk ook dat de meeste malware wordt gemaakt op basis van bekende gaten. Dus onthulde lekken. Microsoft heeft zelfs beweerd dat malwaremakers vaak uitgaan van de informatie die patches hun geven. En dan is er tenminste nog een patch. Bij het onthullen van lekken voordat de leverancier het weet of heeft kunnen dichten, duurt dat nog enige tijd.
Laten we even eerlijk zijn, het is vaak niet eens zo slecht gesteld met het patchen van gaten. Ook niet wat betreft de tijd die leveranciers daarvoor nodig hebben, of nemen. Zo komt aanstaande dinsdag in Microsofts maandelijks patchronde de oplossing voor de recente zero-day, die is ontdekt en onthuld door Tavis Ormandy. Daarmee blijft Microsoft ruim binnen de 60 dagen die de security-onderzoeker had geëist. Maar was dat ook gebeurd als Ormandy niet naar buiten was getreden met zijn ontdekking? Dat is en blijft de vraag.
Een vraag waarvan het antwoord wat gerelativeerd wordt door een ander tijdsprobleem. De duur tussen het verschijnen van een patch en het installeren daarvan. Daar blijkt in de praktijk ook een flink gat te zitten. Beheerders en gebruikers nemen de tijd. De meest misbruikte, lekken zijn echt niet de allernieuwste. De stilgehouden of topgeheime gaten waar alleen een handjevol experts - white, gray en/of black hats - van af weten. Nee hoor, de grote plagen waren rond voor oude gaten waar vaak ook al lang patches voor zijn.
Het gerenommeerde SANS Institute heeft in september vorig jaar naar buiten gebracht dat bedrijven patches rijkelijk laat na het verschijnen pas toepassen. Ook dat heeft overigens met testwerk te maken. Maar het is dus niet zo verstandig om de malwaremakers nog meer de tijd te geven. Hun voorsprong is al zo groot.
Impact
En tot slot een dilemma dat van toepassing is op wel en niet onthullen, dus op full én responsible disclosure. Doordat ict alomtegenwoordig is, en we als moderne maatschappij niet meer zonder kunnen, is de impact van gaten steeds groter. Enerzijds reden om maar niet voortijdig 'wolf' te roepen, om maar geen slapende cybercriminele honden wakker te maken. Anderzijds argument om juist wel de alarmklok te luiden, om de onwetende schapen te waarschuwen dat de wolf er echt wel is. Telkens weer.
Bonus: bonussen!
Om nog even een gerelateerde knuppel in het hoenderhok van 'disclosure' te gooien: het belonen van netjes melden van lekken is niet zo'n gek idee. Met meer dan alleen een schamele erkenning in de release notes bij een patch. Ja, belonen moedigt aan, dus lokt uit. En dat kost dus geld; voor de bonus zelf en voor het extra werk dat er dan op een leverancier afkomt.
Waarschijnlijk trouwens veel geld, want een leverancier van een veelgebruikt product moet dan opbieden tegen de zwarte markt. Waar een goed gat goud waard is. Maar waar de onderzoekers minstens zo slim zijn als de white hat hackers die buiten het illegale circuit staan. Kortom, we zijn er nog lang uit; of lekken onthuld of stilgehouden moeten worden.
Bedankt voor de minnetjes Blieb. Heel volwassen. =P
Ik weet uit ervaring dat sommige problemen meer tijd nodig hebben dan andere. Zeker als er uitgebreide regressietesten nodig zijn.
Ik vind jouw oplossing vrij cynisch en het is daarom niet de weg die ik bij voorkeur zou kiezen. Maar goed, dit is een vrij land.
Ik niet. Dan geef je een bedrijf de kans om rustiger aan te doen. Als buitenstaander kun je nooit weten/controleren of de argumenten die een bedrijf aanvoert waarom ze meer tijd nodig hebben waar zijn of niet.
Ik stel mij voor dat een bedrijf winst moet maken en daarom liever niet te veel programmeurs aan een patch laten werken (of testen) als dat ten koste gaat van de releasedate van een nieuwe versie die weer geld in het laadje moet brengen.
Wat in de praktijk het beste werkt is om ze gewoon keihard voor het blok te zetten.
Ik zou 'ongeacht de' vervangen door 'mits geen'. Sommige lekken zijn misschien niet in 30 dagen te verhelpen.
Zolang er constructieve communicatie is tussen de twee partijen, en de security by obscurity nog redelijk werkt, vind ik niet dat je de slapende honden (black-hat hackers of wannabes) moet wakker maken.
Zo, je wenst me zelfs al een hartaanval toe? Kan je nog lager gaan?
hoe jij niet te doen hoor ;)
IMHO zou een ontdekker van een lek, de makers van de software moeten inlichten en alle mogelijke relevante informatie die de vervaardiging van een patch versnellen, ter beschikking stellen. Tevens zou hij de makers moeten vertellen dat hij het lek (en eventuele exploitcode) na 30 dagen zal publiceren, ongeacht de reactie van de makers van de software.
Al lang gepatchte *bekende* lekken... :-)
Ik denk dat dat meer te maken heeft met de openheid van Linux. Bij MS ben je afhankelijk van wat MS je biedt en zal een afwijkende functionaliteit ook extra geld kosten. Zoals Blieb al aangeeft, je kunt b.v. W-Server gebruiken, maar da's duurder.
Bij Linux kun je dus veel makkelijker de mogelijkheden gebruiken die het OS je biedt. Je (laat) iets compileren waar je alles uitsloopt wat je niet nodig hebt en wat het systeem ook maar enigszins kwetsbaar zou kunnen maken.
Juist wel. Je kunt Windows embedded gebruiken of Windows server 2008 of zelfs de core versie daarvan voor bedrijfskritische systemen.
Windows computers worden genoeg gebruikt in ziekenhuizen, electriciteitscentrales etc. Vertel me nu nog een keer hoe je zo zeker weet dat er geen mensenlevens bedreigd worden.
"Ontdoe de medische computers van het netwerk" = oh, en hoe krijgt de docter de gegevens dan te zien?
"Scheid de twee netwerken" = een usb-stick trekt zich niks aan van een firewall.
Nu zou je - terecht? - kunnen stellen dat het de hacker is die mensenlevens in gevaar brengt. Echter, de hacker is hier (hoogstwaarschijnlijk) niet op uit - die wil gewoon je creditcard gegevens en/of wat spam versturen. Dat een mensenleven bedreigd wordt door een disfunctionerende computer is een onbedoeld neveneffect.
Het wezenlijke probleem is hier de toeters en bellen: een medische computer heeft wel een netwerk nodig, maar alleen uitgaand. Een goede systeembeheerder kan al aardig wat dichttimmeren, maar het systeem is daar niet echt op ingericht.
Gek genoeg biedt MS wel 7 variaties aan van hetzelfde systeem (van 'normaal', 'kreupel' en 'extra' etc) - maar geen 'hardened windows' voor een bedrijfskritieke (dus geen standaard desktop) toepassing.
Kijk je in linux land - dan zie je dat er een rijk aanbod is aan 'hardened' linux distributies. Zou dat komen omdat linux zoveel veiliger is dan windows? Of zou dat komen omdat er in de markt vraag is naar een extra dichtgespijkerd systeem.
Software is zo lek als je het toelaat. Waarom kan 'MS office' lek zijn voor remote attacks? Omdat het zonodig - omwille wat voor functionaliteit dan ook - aan het netwerk wil luisteren. SMB gaten? (om de paar jaar wel een paar)? Omdat MS zonodig bijna standaard printers en shares wil delen. en ga zo maar door. Dit zijn geen bugs, dit zijn ontwerp keuzes.
(zelf-ontkrachtende opmerking wtb hardened windows:) het kan min of meer met 'windows embedded' maar dat is weer zo'n omslachtig verhaal dat zelfs leveranciers van medische apparatuur dat liever links laten liggen - blijkbaar.
Nu heb ik verder helemaal niks tegen windows (itt tot sommige andere MS bashers hierzo) en gebruik het al 15 jaar met plezier, toch vind ik dat ik het grootste recht heb op mijn 2 centjes kritiek -of een kritische blik- op hun aanpak. One size fits all - maar technisch moet het best mogelijk zijn een windows met een of ander meetsysteem applicatie zo te maken dat het zelfs zonder patches een jaar of 10 draait zonder gehacked te worden. Tis een keuze.
Er staan dan ook nergens computers in vliegtuigen, ziekenhuizen, kerncentrales, auto's, ....
Je vergeet een punt. Vaak zijn er voor lekken work arounds. In dit laatste geval ook, het uitschakelen van een protocol is voldoende om het probleem buiten te houden.
De vraag is nu, wat heb je liever. Blissful unawareness, met het risico dat een black hatter het ontdekt en verkoopt aan Metasploit? Of disclosure, met een work around zodat je je in elk geval kan verdedigen tegen mogelijke hackers en volhouden tot de patch er is.
Oftewel, heb je liever de buurman aan de deur om je te waarschuwen dat de achterdeur op een kier staat, ook al is die deur niet zichtbaar vanaf de straat. Of wacht je liever af of er ooit een insluiper achterkomt?
Ik vind de discussie wel erg zwart-wit op dit moment. Verder 'je grote bek dicht te houden' terwijl je ziet dat het bedrijf hard werkt aan een oplossing? Lijkt me logisch. Verder 'je grote bek dicht te houden' terwijl je ziet dat het misgaat? Lijkt me een slechte oplossing. Goed voor het bedrijf misschien... op korte termijn. Slecht voor de consument.
In economische verliezen zouden de verschillen niet zo groot hoeven te zijn misschien.
Maar goed de vraag is, of een hacker zijn mond moet houden als hij weet dat er een ernstig lek in software zit waardoor botnets hun gang kunnen gaan terwijl het bedrijf probeert het lek te verdoezelen.
Ik vind dat de hacker in kwestie zijn mond moet houden, tot duidelijk is dat hij genegeerd wordt. Als een hacker een fout kan vinden, dan kan een andere hacker dat ook. Het is dus een kwestie van tijd voor misbruik gemaakt gaat worden van een lek. Ik zou niet zo ver willen gaan dat ik full disclosure zou voorstellen, maar als een bedrijf weigert actie te ondernemen kan het uiteindelijk noodzakelijk worden.
De zaak die dit hele verhaal nu weer in de media heeft gebracht lijkt me een schoolvoorbeeld van hoe het niet moet. Maar aan de andere kant, zoals het in de IE6/ActiveX tijd ging is weer het andere uiterste. Ik denk dat beide partijen elkaar nodig hebben en dus elkaar serieus moeten nemen.
Dus... als ik een softwarelek ontdek en ik gooi dat in het publieke, dan kan iedereen daar misbruik van maken en tegelijkertijd heeft de eigenaar van de software (lees: eigenaar van het intellectueel eigendom) de mogelijkheid om dat lek te verhelpen. Daarmee zorg ik er dus voor, dat gebruikers (eigenaren van licenties van de betreffende software, die geen hacker zijn) de kans lopen om schade op te lopen, mits de eigenaar van de software het lek niet heel erg snel verhelpt.
Er zullen geen derde partijen zijn, die een patch schrijven om het lek te verhelpen, dus lijkt mij het enige verantwoordelijke (indien ik geen crimineel ben), om het lek aan de eigenaar van de software te melden en verder m'n grote bek dicht te houden... iets anders en dan ben ik wel crimineel bezig... en dat is mijn mening.
Je trekt hier dus de vergelijking die hevig impliceert dat een fout die een mensenleven kan kosten even ernstig is als een fout die inbraak op een computer kan veroorzaken.... interessant.
Stel: een autofreak met veel knowhow en gereedschap ontdekt een ernstige fout waardoor alle Toyota's kunnen ontploffen. Moet die ontdekker dan de cel in omdat hij moedwillig zijn neus in andermans zaken heeft gestoken?
Zeg jij het maar...
Ik wel. Alleen zijn er te weinig van.
Assumption...
Ik het het dan ook niet tegen jou.
Dat ik het niet met jou eens zou zijn had ik wel verwacht, want je reactie blinkt uit in absolute nietszeggendheid, dus ik neem maar aan dat het alweer een grap is.
Het lijkt mij niet wenselijk om de strafmaat af te laten hangen van de pak kans.
Want daar zijn we het over eens? Bizarre stelling zeg. Dat zijn we namelijk helemaal niet.
Ik heb het idee dat geen enkele security model an sich werkt. Je streven om te komen tot een eenvoudige en eenduidige oplossing, geformuleerd op politiek correcte wijze (beetje in het midden), doet op geen enkele wijze recht aan de complexititet van het thema.
Ik denk dat de enige weg te gaan is, om effectief 'security te doen' niets anders is dan je te manifesteren als krachtige partij in de huidige praktijk van de dag. Hackers zijn er in alle soorten en maten. Hun 'disclosure strategie' loopt van zeer responsible tot zeer rancuneus cq sensatie belust cq commercieel getint.
Ik hoop dat als je dit leest, dat je dan begrijpt wat ik bedoel, en dat je dan niet alsnog tot de conclusie komt dat 'we' het wel eens zijn met een stelling die uitblinkt in simpliciteit.
Edit: reactie op Thieu
Bij security by obscurity denk ik mee aan de periode tussen de ontdekking en openbaarmaking van het lek. Vaak zal de openbaarmaking gelijk vallen met, of de patch, of de eerste gevallen van misbruik.
In die zin vind ik dat security by obscurity wel toegevoegde waarde heeft. Maar het mag inderdaad geen doel op zich worden, want dat werkt niet, daar zijn we het over eens.
Voor zover mij bekend houdt Tavis Ormandy zich over het algemeen keurig aan het idee van responsible disclosure. De manier waarop jij in één grandioze beweging alle veiligheidsonderzoekers om één hoop veegt is net zo min constructief als de fout in deze specifieke situatie.
Denk je om je bloeddruk?
Dan is hij daar de boot ingegaan dan. Zoiets beslis je in overleg lijkt me. Meneer Ormandy doet verder goed werk wat mij betreft, maar in deze heeft hij toch een steek laten vallen.
Het één hoeft het ander niet uit te sluiten. Maar welke fabrikant biedt garantie tegen moedwillige vernieling van zijn producten?
Nee. Daarom juist. Mensen met voldoende verstand van ICT om beveiliging te begrijpen, gaan wellicht minder snel werken voor een ambtenarensalaris. En de salarissen voor ambtenaren verhogen is (m.i. terecht) taboe. Dus deze agenten gaan er waarschijnlijk ook niet komen.
Aangezien de pakkans dan klein blijft, zou het risico voor de computercrimineel moeten toenemen door hard te straffen.
Volgens mij bestaat dat niet. Als een lek niet algemeen bekend is is het goed denkbaar dat het wél goed bekend is bij mensen die er belang bij hebben. Dat zijn dan vaak degenen die een lek zo lang mogelijk ongestoord willen misbruiken.
Security by obscurity werk niet. Maar dat wist jij al :-)
Strafbaarheidsstelling heeft alleen zin als je het kunt waarmaken, dus als je daadwerkelijk iemand kunt veroordelen en bestraffen. Los daarvan moet je ook voor ogen houden waar het hier omgaat: tekortkomingen in een product.
Bedenk dat je daar politie en justitie voor vrij moet maken. Dat kost mankracht waardoor die mankracht niet meer ingezet kan worden voor iets anders, zoals bijvoorbeeld bestrijding van kinderporno. Dat kost geld waardoor 'lekken in software' opeens op het bordje van de belastingbetaler komt en dat geeft een softwarebouwer weinig reden om zelf in de buidel te tasten om de software te verbeteren.
Je staat met je strafbaarstelling verder met lege handen als het criminele gedrag gedaan wordt in het buitenland, zeker als dat een land is waar het niet strafbaar is en waar geen uitleverings- of samenwerkingsrelatie mee is. Vooropgesteld dat je de dader kunt vinden, natuurlijk.
Dan blijft er nog een categorie over die je zou kunnen omschrijven als misbruik, zoals het uitvoeren van code in een PDF-bestand. Geeneens lekken maar het gebruiken van mogelijkheden voor, wellicht, criminele doeleinden. Anders gezegd: stel ik stuur jou een mailtje met een boosaardig attachment en jij opent het attachment en voert het uit. Wie is dan de crimineel? Dan hebben we het nog niet eens gehad over eigenaren/beheerders van websites waarop malicieuze code wordt verspreid zonder dat ze het weten.
Micrsoft publiceert regelmatig rapporten met de stand van de security zaken en daar staat bijvoorbeeld precies in welke lekken in software het meest worden aangevallen en dat zijn inderdaad vaak al lang gepatchte lekken.
Zie hier: http://www.microsoft.com/security/about/sir.aspx
De egotripper per definitie is inderdaad het type dat niet nadenkt over de belangen van anderen, dus ook niet van de gebruikers over de hele wereld.
Er zijn nog meer types die dat probleem hebben (zij het wellicht in mindere mate), en dat zijn de mensen die denken dat ze weten hoe het zit. En daar ook nog eens prat op gaan. Langzamerhand groeit bij hen het geloof dat ze expert zijn. Door deze zelf-overschatting raken ze deels verblind. Hierdoor kunnen zij gemakkelijk de belangen van grote groepen belanghebbenden uit het oog verliezen en deze dan ook niet correct waarnemen noch meewegen in hun oordelen cq wijsheden.
Nee, de hele heisa is begonnen omdat een security onderzoeker bij MS een lek aanmelde en begon te eisen dat ze het binnen 60 dagen zouden oplossen terwijl iedere security onderzoker weet dat Microsoft eerst de impact bepaalt en dan zelf bekijkt welke terminjn het lek in de patchh cyclus pas. De meneer wist dus al dat zijn eis noot door MS zou worden geaccepteerd en publiceerde vervolgens binnen een week een exploit voor het betreffende lek. Dootdat er nu tienduizenden of zelfs honderdduizenden mensen aangevallen worden met zijn exploit moet Microsoft de patch cylus omgooien en zijn lek prioriteren en wordt hij als persoon belangrijker.
Pure egotripperij dus die enorm veel gebruikers onnodig veel schade berokkend en die door de beperkingen in testtijd meer risico's inhoud dat de patch software op bepaalde configuraties voor andere nieuwe issues kan zorgen.
Als een lek op verantwoordelijke wijze doorgegeven wordt dan kan Microsoft veel rustiger een oplossing bedenken en deze in een patchstrategie inpassen. Ook kan Microsoft die wereldwijd het internet op security issues monitoren in de tussentijd wel controleren dat er hun gebruikers niet door zero day aanvaalers worden geexploiteerd en dus altijd de risico's voor gebruikers minimaliseren.
Er is dan ook geen geen enkel voordeel aan de publicatie van een exploit voor de software gebruikers. Deze werden door deze egotrpiier dus zwaar genaaid zodat zijn naam wate vaken in de publiciteit komt.
Volgens mij is de hele heisa ontstaan omdat iemand een lek had gevonden die voor hem niet zo misbruikbaar leek, en was het responsible genoeg om het te disclosen. Helaas bleek dat lek dus op andere manieren juist heel goed te misbruiken en worden een paar heetgebakkerde microsoft "security experts" boos. Tja, die heetgebakkerde microsoft "security experts" hadden het zelf dus al fout voordat de software geleverd werd, ga dan niet iemand aanvallen die de gevolgen van het gat nog niet helemaal overzag. Dat krijg je namelijk als je de source code niet hebt.
De disclosure van die man was volledig terecht en responsible voorzover hij het kon overzien. Dus we mogen hem gewoon dankbaar zijn.
Dat de microsoft "security expert" dan wel overuren moet draaien is gewoon zijn WERK.
Zelf verplicht ik ook wel eens tot een code audit door een peer, en die kan er meestal nog wel wat fouten uithalen.
Je hebt zojuist filosofie naar de ijskast verwezen. Waarom zou je niet over een gewenste situatie moge discuteren?
Voor de rest heb je een goede reactie. Maar de vraag die het artikel oproept is er eigenlijk mee verweven. Hoe dien je de belangen van die gebruikers en beheerders het beste. Dus wat is de responsible disclosure?
Ik zelf denk dat full disclosure niet de juiste weg is, net zo min als volledig stilhouden (dus eigenlijk security by obscurity). Ik denk dat je fabrikanten een redelijke termijn moet geven om een probleem op te lossen, maar die termijn kan niet blijven schuiven. Blijft alleen de discussie over wat een redelijke termijn zou kunnen zijn.
Ik denk dat de vraagstelling over wat de beste methode is een beetje rare vraag is. Het getuigd van de illusie dat de maatschappij maakbaar is in alle opzichten. Er zijn dusdanig verschillende motieven om een gat te vinden, dat de wijze waarop ermee omgesprongen wordt en zal blijven worden per definitie oncontroleerbaar is.
Wat je als software fabrikant kan en moet doen is jezelf en je klanten zoveel mogelijk weerbaar maken tegen de problemen die zich aandienen rondom dit thema. Preventief kun je zorgen voor het fundamenteel inbouwen van security in het ontwikkeltraject, en vervolgens een support systeem/organisatie organiseren dat goed in staat is om te reageren op incidenten, en een capabele staf neerzetten die e.e.a. communicatief doordacht en zo correct mogelijk naar buiten brengt. E.e.a. moet gericht zijn op het dienen van de belangen van de gebruikers en de beheerders van de gebruikers.
De meest misbruikte, lekken zijn echt niet de allernieuwste. De stilgehouden of topgeheime gaten waar alleen een handjevol experts - white, gray en/of black hats - van af weten. Nee hoor, de grote plagen waren rond voor oude gaten waar vaak ook al lang patches voor zijn
En uit welke cijfers blijkt dit? Los daarvan kun je je afvragen wat ernstiger is: 'grote plagen' die het nieuws halen of gerichte hackpogingen waarbij jarenlang stilletjes gebruik wordt gemaakt van een via de zwarte markt verkregen lek.
Wel grappig dat je het meteen zoekt in strafbaarheid. Ik zou het juist zoeken in aansprakelijkheid van de fabrikant.
Met openbaar maken zitten we gelukkig wel op 1 lijn: openbaarmaken van lekken zou expliciet niet strafbaar gesteld moeten worden. Enkel het halen van financieel gewin danwel het stelen van gegevens zou strafbaar moeten zijn. Het simpelweg melden van een lek (klokkeluidersfunctie) zou een beschermd recht moeten zijn.
Ben jij al eens een politie man of vrouw tegen gekomen die verstand heeft van ICT?
Ik denk dat het voor de voortgang je carrière beter is niks te zeggen. Met klokkenluiders en dergelijke loopt het zeker in Nederland niet goed af.
De strafbaarheid op computercriminaliteit moet fors omhoog. Dat geldt ook voor de strafbaarheid op medeplichtigheid hieraan.
Dat verkleint het dilema.
Openbaar maken zie ik overigens als een recht, tenzij het om informatie van je werkgever gaat.
Reageer
Preview