Hvad er mest sikkert: Open source eller closed source? Her er mit bud på, hvorfor open source er langt den sikreste form for software.
For nemheds skyld vil jeg indføre tre definitioner:
1. Den venligtsindede person er typisk "ejeren" af softwaren, som står for den primære udvikling. Det kan også være den person eller institution, der sætter software i drift, f.eks. en bank.
2. Den ondsindede person forsøger bevidst at finde sikkerhedsbrister, som personen udnytter til personlig vinding. Den ondsindede person er f.eks. en hacker.
3. Den neutrale person har ikke specifikke interesser i at udnytte sikkerhedsbrister, men har omvendt heller ikke ejerskab af softwaren. Det neutrale person kan f.eks. være en bankkunde, men kan også være frivillig bidragyder til softwaren, idet personen måske på isolerede punkter har en interesse i, at softwaren får en bestemt funktionalitet.
For eksempel: Hvis du opdager en sikkerhedsbrist i et sygehussystem eller en brist i et banksystem, så kan du enten vælge at udnytte sikkerhedshullet til skade for patienter eller bankkunder, eller du kan advare sygehuset eller banken, før du selv bliver patient eller kunde. Nogle mennesker (de ondsindede personer) vil forsøge at udnytte sikkerhedsbristen. Andre (de neutrale) vil indberette den, og måske komme med forslag til rettelse, til den myndighed (den venligtsindede person), der benytter softwaren til sin service.
Interesse-misforhold
Vi kan generelt antage, at den ondsindede person målrettet leder efter softwarefejl, uanset om softwaren er udviklet som open source eller closed source. På grund af adgangen til kildekoden i open source kan vi også antage, at en ondsindet person principielt vil kunne identificere flere sikkerhedsbrister i open source end i closed source. Dette er et af de oftest benyttede argumenter mod open source. (Der er dog en hage ved antagelsen, som jeg kommer ind på senere.)
Imidlertid eksisterer der et interesse-misforhold mellem open source og closed source, som gør argumentet svagt. Det kræver lidt forklaring:
Erfarne softwareudviklere vil kunne tale med om, at man finder flere sikkerhedsbrister ved et tilfælde, mens man vedligeholder eller udbygger kildekode, end når man efterfølgende er bruger af softwaren. Det svarer til, at mekanikeren finder fejl i en bil ved et serviceeftersyn, mens hverken bilens ejer eller mekanikeren ville opdage fejlene på en køretur.
Hvis kildekoden er tilgængelig, og hvis det er tilladt at videreudvikle kildekoden, vil der optræde neutrale personer, som arbejder med den. Disse personer vil finde sikkerhedsbrister af ovennævnte årsag, og kan forventes at indberette eller rette op på sikkerhedsbristerne.
Neutrale personer har dog ingen interesse i at beskæftige sig med kildekoden i closed source, fordi den jo ikke er tilgængelig. De finder derfor kun sikkerhedsbrister i closed source software, når de tilfældigt falder over dem i rollen som almindelige slutbrugere.
For nemheds skyld vil jeg indføre tre definitioner:
1. Den venligtsindede person er typisk "ejeren" af softwaren, som står for den primære udvikling. Det kan også være den person eller institution, der sætter software i drift, f.eks. en bank.
2. Den ondsindede person forsøger bevidst at finde sikkerhedsbrister, som personen udnytter til personlig vinding. Den ondsindede person er f.eks. en hacker.
3. Den neutrale person har ikke specifikke interesser i at udnytte sikkerhedsbrister, men har omvendt heller ikke ejerskab af softwaren. Det neutrale person kan f.eks. være en bankkunde, men kan også være frivillig bidragyder til softwaren, idet personen måske på isolerede punkter har en interesse i, at softwaren får en bestemt funktionalitet.
For eksempel: Hvis du opdager en sikkerhedsbrist i et sygehussystem eller en brist i et banksystem, så kan du enten vælge at udnytte sikkerhedshullet til skade for patienter eller bankkunder, eller du kan advare sygehuset eller banken, før du selv bliver patient eller kunde. Nogle mennesker (de ondsindede personer) vil forsøge at udnytte sikkerhedsbristen. Andre (de neutrale) vil indberette den, og måske komme med forslag til rettelse, til den myndighed (den venligtsindede person), der benytter softwaren til sin service.
Interesse-misforhold
Vi kan generelt antage, at den ondsindede person målrettet leder efter softwarefejl, uanset om softwaren er udviklet som open source eller closed source. På grund af adgangen til kildekoden i open source kan vi også antage, at en ondsindet person principielt vil kunne identificere flere sikkerhedsbrister i open source end i closed source. Dette er et af de oftest benyttede argumenter mod open source. (Der er dog en hage ved antagelsen, som jeg kommer ind på senere.)
Imidlertid eksisterer der et interesse-misforhold mellem open source og closed source, som gør argumentet svagt. Det kræver lidt forklaring:
Erfarne softwareudviklere vil kunne tale med om, at man finder flere sikkerhedsbrister ved et tilfælde, mens man vedligeholder eller udbygger kildekode, end når man efterfølgende er bruger af softwaren. Det svarer til, at mekanikeren finder fejl i en bil ved et serviceeftersyn, mens hverken bilens ejer eller mekanikeren ville opdage fejlene på en køretur.
Hvis kildekoden er tilgængelig, og hvis det er tilladt at videreudvikle kildekoden, vil der optræde neutrale personer, som arbejder med den. Disse personer vil finde sikkerhedsbrister af ovennævnte årsag, og kan forventes at indberette eller rette op på sikkerhedsbristerne.
Neutrale personer har dog ingen interesse i at beskæftige sig med kildekoden i closed source, fordi den jo ikke er tilgængelig. De finder derfor kun sikkerhedsbrister i closed source software, når de tilfældigt falder over dem i rollen som almindelige slutbrugere.
Vi har derfor følgende situation: Ondsindede personer har interesse i
kildekoden i såvel open source som closed source, og vel at mærke med
henblik på at identificere svagheder. Neutrale personer har kun
interesse i at undersøge koden i open source.
Nettoresultatet er, at ondsindede personer vil finde flere sikkerhedsbrister i closed source end neutrale personer, fordi de ondsindede personer beskæftiger sig langt mere indgående med closed source end neutrale personer. Interesse-misforholdet mellem open source og closed source stiller således ondsindede personer væsentligt stærkere overfor closed source end overfor open source i forhold til modvægten fra de neutrale personer.
Denne diskussion accepterer dog closed source-forsvarernes præmis om, at den åbne kode i sig selv er en sikkerhedstrussel, og tjener derfor blot til at svække præmissens argument for, at der kan identificeres flere sikkerhedsbrister i open source end i closed source.
I virkeligheden er selve præmissen fejlagtig: Det er langt nemmere at inspicere kildekode med henblik på at identificere mulige sikkerhedsbrister, end det er at identificere sikkerhedsbrister, der giver bestemte muligheder. Det er praktisk taget umuligt at læse kildekode og gennemskue hvilke muligheder, en given sikkerhedsbrist reelt åbner op for. Når ondsindede personer forsøger at bryde ind i software, sker det derfor i praksis ikke ved at nærlæse kildekoden for fejl. I stedet benytter hackere sig af automatiserede værktøjer til f.eks. port scanning, SQL injections, password-gæt, osv. Overfor angreb fra ondsindede personer har det således i praksis ingen betydning, om der er tale om open source eller closed source.
Til gengæld opdages sikkerhedsbrister forholdsvis nemt ved nærlæsning af kildekoden, for her er det tilstrækkeligt, at man konstaterer, at der er en mulighed for en uhensigtsmæssighed, uden at man behøver gøre sig de større tanker om, hvordan man helt specifikt kan udnytte uhensigtsmæssigheden. Sikkerhedstruslen er derfor den samme, uanset om softwaren bygger på open source eller closed source, men er kildekoden open source, er der flere øjne, der læser den, og som kan nedbringe sårbarheden.
Konfigurationsstyring
Det foregående afsnit beskæftigede sig med muligheden for at identificere sikkerhedsbrister i kildekoden. Open source giver dog også andre muligheder end at læse kildekoden; man kan også skrive ny kildekode eller ændre den eksisterende kildekode. Ondsindede personer har mulighed for at ændre i kildekoden og foreslå disse ændringer til de instanser, der måtte ønske at bruge softwaren.
Det siger sig selv, at ikke alle og enhver skal have mulighed for at ændre den kildekode, der driver kritiske systemer. Hvis f.eks. hospitalsvæsenets kildekode frit kunne ændres af alle og enhver, ville patientsikkerheden hurtigt blive kompromitteret. Dette er et andet ofte benyttet argument mod open source: Hvis enhver kan ændre koden, kan og vil også ondsindede personer ændre den.
Sådan fungerer drift af software imidlertid ikke. En ting er nemlig at ændre i kildekoden; det er nemt. En anden ting er, om det også er denne ændrede kildekode, der bliver sat i drift, og det er straks langt sværere at opnå. Der er nemlig ikke blot én kildekode. Hvis man f.eks. satte nye fælge på sin bil, så ville der kun være én bil at beskæftige sig med, når ændringen var foretaget. Men hvis man ændrer på kildekode, så findes der i open source-verdenen praktisk taget altid to versioner: Den originale kode og den ændrede kode.
Det handler i korte træk om, at når man ændrer i en softwarepakkes kildekode og frigiver denne ændring, så er kildekoden med denne ændring en anden softwarepakke end den oprindelige kildekode. Der findes nu to versioner, og det er muligt at afgøre helt entydigt hvilken af de to, man vælger at benytte sig af i et bestemt system. Man får derfor ikke sat ondsindet kode i drift i sit system, bare fordi nogen ændrer i kildekoden.
Sikkerheden er først brudt, når det kritiske system vælger at bruge den sikkerhedskompromitterede softwarepakke. For at forhindre dette træder der en række mekanismer i gang, for så vidt der er tale om en ansvarligt drift af det pågældende system. Her er et udpluk af mekanismerne:
Open source har en svag fordel, der dog efter min mening ikke er helt skudsikker: Der opbygges et hierarki af tillid omkring de mere populære softwarepakker, hvor bestemte udviklere beviser deres troværdighed, og kan stå som garanter for, at softwaren lever op til deres standarder for sikkerhed m.v. Aktiviteten omkring de populære softwarepakker bevirker, at en nyudvikling i praksis bevæger sig gennem en række udviklingstrin mod toppen af troværdigheds-hierarkiet - og dermed en tilsvarende række muligheder for identifikation af sikkerhedsbrister - før den endeligt bliver accepteret af de troværdige udviklere. Et slående eksempel er Linux-kernen, hvor der mig bekendt kun én gang er sluppet ondsindet kode med - og det var i øvrigt ad helt andre kanaler, hvor den ondsindede person havde skaffet sig adgang til det sted, hvorfra man kunne hente den officielle Linux-kerne.
Falsk tryghedsfornemmelse
Risikoen for indførelse af ondsindet kildekode i closed source hævdes ofte at være elimineret, fordi kildekoden er under streng adgangskontrol. Men det er falsk tryghedsfornemmelse af to årsager:
For det første har softwarehuse kun begrænsede ressourcer til undersøgelse af sikkerhed og identifikation af fejl i kildekoden. En kommerciel softwarevirksomhed har ikke softwaresikkerhed som sit primære formål; det er et nødvendigt onde. Sikkerhedsforanstaltningerne udgør en del af virksomhedens omkostninger, og det er sjældent rentabelt at bruge "overdreven" tid på at finde de sidste 10% fejl i softwaren. End ikke Forsvarets Efterretningstjeneste har ressourcer til at sandsynliggøre, at betroet udvikling er fri for ondsindet kildekode, og må nøjes med at stole på de underleverandører, der udvikler koden. I modsætning til open source vil der derfor kun være ganske få øjne, hvis overhovedet nogen, der ser kildekoden efter for sikkerhedsbrister.
For det andet er IT-kriminalitet en profitabel forretning, og udviklere kan bestikkes. Sikkerhedstests alene er ikke tilstrækkelige overfor kompetente ondsindede personer, og skulle det ikke være tilstrækkeligt, er det formentlig også muligt at bestikke de personer, der udvikler softwaretesten. Kan man ikke bestikke enkeltpersoner i et udviklingshus, kan selve udviklingshuset også selv vælge den kriminelle løbebane - for når IT Factory kunne sælge store mængder vaporware, kan et ondsindet firma også sælge løsninger behæftet med bevidste sikkerhedsbrister.
Mens adgangskontrol kan have en afskrækkende virkning overfor en eventuelt ondsindet udvikler eller bidrage til en fornemmelse af, at man kan undgå indførelsen af ondsindet kode, er adgangskontrollen ikke i praksis nogen hindring. Selv om en bestemt ændring i kildekoden umiddelbart kan spores til en bestemt udvikler, skal det være en meget åbenlys "feature" i kildekoden, før man kan konkludere, at udvikleren havde ondsindede hensigter, og ikke blot havde lidt rigelig travlt i et arbejdsmiljø, der i forvejen er kendetegnet ved travlhed. Endvidere kan ondsindede ændringer være foretaget ad flere omgange, så aktiviteten sløres blandt en række venligtsindede ændringer i kildekoden. I et miljø med begrænsede ressourcer er det særdeles omkostningsfyldt at foretage en sporing af sådanne ondsindede ændringer, og en kompetent, ondsindet udvikler har ikke nogen væsentlig grund til at frygte for sit job, selv om den bevidst indførte sårbarhed kan spores til udvikleren.
Diskussion
Softwaresikkerhed afhænger af mange faktorer, herunder design, inspektion af kildekoden, konfigurationsstyring, driftspolitikker, m.v. Det er ikke væsentligt for nogen af disse dele, om kildekoden er open source eller closed source. Softwaren er i sig selv ikke mere sikker, bare fordi den bliver erklæret open source eller closed source.
Antallet af øjne, der får lov til at inspicere og teste såvel design af kildekoden som den endelige implementation, er imidlertid en af de væsentligste faktorer for forbedring af sikkerheden af kildekoden. Udgangspunktet for closed source er, at netop dette grundliggende udgangspunkt for sikkerhed skal begrænses til et minimum. Endvidere er closed source motiveret af økonomiske interesser, der af hensyn til omkostningerne yderligere begrænser denne vigtige faktor.
IT-angreb er uafhængige af, om softwaren bygger på open source eller closed source. Til gengæld har hvert open source-produkt en skare af hjælpsomme sikkerhedseksperter til rådighed, hvis antal kun i meget sjældne tilfælde kan matches af en tilsvarende closed source-virksomhed.
Folketinget har besluttet, at alle offentlige danske virksomheder fra 1. januar 2008 skal benytte den danske standard for informationssikkerhed, DS484. Denne standard kræver i pkt. 12.4.3, at adgangen til kildekode skal beskyttes, ikke blot mod ændringer, men også i forhold til læsning. I betragtning af, at open source som udgangspunkt har højere potentiale for sikkerhed end closed source på det ene punkt, der i væsentligst grad adskiller de to adgangspolitikker, er det bekymrende, at offentlige danske virksomheder er pålagt at udvikle closed source-software for at leve op til Folketingets krav om informationssikkerhed.
Det er nødvendigt at indse, at closed source ikke kun skjuler kildekoden. Closed source skjuler også den ene ting, der skal til for at styrke sikkerheden af kildekoden, idet der henvises til et trusselsbillede, der ikke stemmer overens med moderne IT-kriminalitet.
Der er nærliggende at tro, at den egentlige motivation for closed source ikke er trusselsbilledet, men at adgangen til kildekoden søges begrænset, så ingen opdager, hvor mangelfuld, closed source-virksomhedernes sikkerhed er med hensyn til såvel design, implementation som til test og drift. Så længe kildekoden og dens akkompagnerende dokumentation og processer holdes hemmelige, er det muligt at undgå de uprofitable sikkerhedsinspektioner, som open source til enhver tid udsættes for.
Nettoresultatet er, at ondsindede personer vil finde flere sikkerhedsbrister i closed source end neutrale personer, fordi de ondsindede personer beskæftiger sig langt mere indgående med closed source end neutrale personer. Interesse-misforholdet mellem open source og closed source stiller således ondsindede personer væsentligt stærkere overfor closed source end overfor open source i forhold til modvægten fra de neutrale personer.
Denne diskussion accepterer dog closed source-forsvarernes præmis om, at den åbne kode i sig selv er en sikkerhedstrussel, og tjener derfor blot til at svække præmissens argument for, at der kan identificeres flere sikkerhedsbrister i open source end i closed source.
I virkeligheden er selve præmissen fejlagtig: Det er langt nemmere at inspicere kildekode med henblik på at identificere mulige sikkerhedsbrister, end det er at identificere sikkerhedsbrister, der giver bestemte muligheder. Det er praktisk taget umuligt at læse kildekode og gennemskue hvilke muligheder, en given sikkerhedsbrist reelt åbner op for. Når ondsindede personer forsøger at bryde ind i software, sker det derfor i praksis ikke ved at nærlæse kildekoden for fejl. I stedet benytter hackere sig af automatiserede værktøjer til f.eks. port scanning, SQL injections, password-gæt, osv. Overfor angreb fra ondsindede personer har det således i praksis ingen betydning, om der er tale om open source eller closed source.
Til gengæld opdages sikkerhedsbrister forholdsvis nemt ved nærlæsning af kildekoden, for her er det tilstrækkeligt, at man konstaterer, at der er en mulighed for en uhensigtsmæssighed, uden at man behøver gøre sig de større tanker om, hvordan man helt specifikt kan udnytte uhensigtsmæssigheden. Sikkerhedstruslen er derfor den samme, uanset om softwaren bygger på open source eller closed source, men er kildekoden open source, er der flere øjne, der læser den, og som kan nedbringe sårbarheden.
Konfigurationsstyring
Det foregående afsnit beskæftigede sig med muligheden for at identificere sikkerhedsbrister i kildekoden. Open source giver dog også andre muligheder end at læse kildekoden; man kan også skrive ny kildekode eller ændre den eksisterende kildekode. Ondsindede personer har mulighed for at ændre i kildekoden og foreslå disse ændringer til de instanser, der måtte ønske at bruge softwaren.
Det siger sig selv, at ikke alle og enhver skal have mulighed for at ændre den kildekode, der driver kritiske systemer. Hvis f.eks. hospitalsvæsenets kildekode frit kunne ændres af alle og enhver, ville patientsikkerheden hurtigt blive kompromitteret. Dette er et andet ofte benyttet argument mod open source: Hvis enhver kan ændre koden, kan og vil også ondsindede personer ændre den.
Sådan fungerer drift af software imidlertid ikke. En ting er nemlig at ændre i kildekoden; det er nemt. En anden ting er, om det også er denne ændrede kildekode, der bliver sat i drift, og det er straks langt sværere at opnå. Der er nemlig ikke blot én kildekode. Hvis man f.eks. satte nye fælge på sin bil, så ville der kun være én bil at beskæftige sig med, når ændringen var foretaget. Men hvis man ændrer på kildekode, så findes der i open source-verdenen praktisk taget altid to versioner: Den originale kode og den ændrede kode.
Det handler i korte træk om, at når man ændrer i en softwarepakkes kildekode og frigiver denne ændring, så er kildekoden med denne ændring en anden softwarepakke end den oprindelige kildekode. Der findes nu to versioner, og det er muligt at afgøre helt entydigt hvilken af de to, man vælger at benytte sig af i et bestemt system. Man får derfor ikke sat ondsindet kode i drift i sit system, bare fordi nogen ændrer i kildekoden.
Sikkerheden er først brudt, når det kritiske system vælger at bruge den sikkerhedskompromitterede softwarepakke. For at forhindre dette træder der en række mekanismer i gang, for så vidt der er tale om en ansvarligt drift af det pågældende system. Her er et udpluk af mekanismerne:
- Der bliver ikke indført en rettelse, med mindre der er identificeret et behov for den ud fra grundsætningen: "Don't fix it if it ain't broke".
- Der eksisterer dokumenterede procedurer for indførelsen af ny funktionalitet, så man ved, hvordan og hvornår de bliver sat i drift i systemet.
- Udvikling, test og drift er adskilte, så systemet ikke kan tages i brug i halvfærdig eller utestet tilstand.
- Der udføres sikkerhedstest mod angreb fra ondsindede personer, før systemet tages i brug.
- Skulle systemet vise sig at være sårbart, er der etableret en mekanisme til at vende tilbage til det tidligere system, uden at der mistes informationer.
- Der foretages transaktionslogning af brugen af systemet, så man kan spore uregelmæssigheder og deres følger.
- Sideløbende og uafhængigt af det idriftsatte system foregår der løbende overvågning af unaturlig aktivitet, så det kan afsløres, om det nye system udviser mistænkelig adfærd i forhold til det gamle system og de ønskede rettelser.
Open source har en svag fordel, der dog efter min mening ikke er helt skudsikker: Der opbygges et hierarki af tillid omkring de mere populære softwarepakker, hvor bestemte udviklere beviser deres troværdighed, og kan stå som garanter for, at softwaren lever op til deres standarder for sikkerhed m.v. Aktiviteten omkring de populære softwarepakker bevirker, at en nyudvikling i praksis bevæger sig gennem en række udviklingstrin mod toppen af troværdigheds-hierarkiet - og dermed en tilsvarende række muligheder for identifikation af sikkerhedsbrister - før den endeligt bliver accepteret af de troværdige udviklere. Et slående eksempel er Linux-kernen, hvor der mig bekendt kun én gang er sluppet ondsindet kode med - og det var i øvrigt ad helt andre kanaler, hvor den ondsindede person havde skaffet sig adgang til det sted, hvorfra man kunne hente den officielle Linux-kerne.
Falsk tryghedsfornemmelse
Risikoen for indførelse af ondsindet kildekode i closed source hævdes ofte at være elimineret, fordi kildekoden er under streng adgangskontrol. Men det er falsk tryghedsfornemmelse af to årsager:
For det første har softwarehuse kun begrænsede ressourcer til undersøgelse af sikkerhed og identifikation af fejl i kildekoden. En kommerciel softwarevirksomhed har ikke softwaresikkerhed som sit primære formål; det er et nødvendigt onde. Sikkerhedsforanstaltningerne udgør en del af virksomhedens omkostninger, og det er sjældent rentabelt at bruge "overdreven" tid på at finde de sidste 10% fejl i softwaren. End ikke Forsvarets Efterretningstjeneste har ressourcer til at sandsynliggøre, at betroet udvikling er fri for ondsindet kildekode, og må nøjes med at stole på de underleverandører, der udvikler koden. I modsætning til open source vil der derfor kun være ganske få øjne, hvis overhovedet nogen, der ser kildekoden efter for sikkerhedsbrister.
For det andet er IT-kriminalitet en profitabel forretning, og udviklere kan bestikkes. Sikkerhedstests alene er ikke tilstrækkelige overfor kompetente ondsindede personer, og skulle det ikke være tilstrækkeligt, er det formentlig også muligt at bestikke de personer, der udvikler softwaretesten. Kan man ikke bestikke enkeltpersoner i et udviklingshus, kan selve udviklingshuset også selv vælge den kriminelle løbebane - for når IT Factory kunne sælge store mængder vaporware, kan et ondsindet firma også sælge løsninger behæftet med bevidste sikkerhedsbrister.
Mens adgangskontrol kan have en afskrækkende virkning overfor en eventuelt ondsindet udvikler eller bidrage til en fornemmelse af, at man kan undgå indførelsen af ondsindet kode, er adgangskontrollen ikke i praksis nogen hindring. Selv om en bestemt ændring i kildekoden umiddelbart kan spores til en bestemt udvikler, skal det være en meget åbenlys "feature" i kildekoden, før man kan konkludere, at udvikleren havde ondsindede hensigter, og ikke blot havde lidt rigelig travlt i et arbejdsmiljø, der i forvejen er kendetegnet ved travlhed. Endvidere kan ondsindede ændringer være foretaget ad flere omgange, så aktiviteten sløres blandt en række venligtsindede ændringer i kildekoden. I et miljø med begrænsede ressourcer er det særdeles omkostningsfyldt at foretage en sporing af sådanne ondsindede ændringer, og en kompetent, ondsindet udvikler har ikke nogen væsentlig grund til at frygte for sit job, selv om den bevidst indførte sårbarhed kan spores til udvikleren.
Diskussion
Softwaresikkerhed afhænger af mange faktorer, herunder design, inspektion af kildekoden, konfigurationsstyring, driftspolitikker, m.v. Det er ikke væsentligt for nogen af disse dele, om kildekoden er open source eller closed source. Softwaren er i sig selv ikke mere sikker, bare fordi den bliver erklæret open source eller closed source.
Antallet af øjne, der får lov til at inspicere og teste såvel design af kildekoden som den endelige implementation, er imidlertid en af de væsentligste faktorer for forbedring af sikkerheden af kildekoden. Udgangspunktet for closed source er, at netop dette grundliggende udgangspunkt for sikkerhed skal begrænses til et minimum. Endvidere er closed source motiveret af økonomiske interesser, der af hensyn til omkostningerne yderligere begrænser denne vigtige faktor.
IT-angreb er uafhængige af, om softwaren bygger på open source eller closed source. Til gengæld har hvert open source-produkt en skare af hjælpsomme sikkerhedseksperter til rådighed, hvis antal kun i meget sjældne tilfælde kan matches af en tilsvarende closed source-virksomhed.
Folketinget har besluttet, at alle offentlige danske virksomheder fra 1. januar 2008 skal benytte den danske standard for informationssikkerhed, DS484. Denne standard kræver i pkt. 12.4.3, at adgangen til kildekode skal beskyttes, ikke blot mod ændringer, men også i forhold til læsning. I betragtning af, at open source som udgangspunkt har højere potentiale for sikkerhed end closed source på det ene punkt, der i væsentligst grad adskiller de to adgangspolitikker, er det bekymrende, at offentlige danske virksomheder er pålagt at udvikle closed source-software for at leve op til Folketingets krav om informationssikkerhed.
Det er nødvendigt at indse, at closed source ikke kun skjuler kildekoden. Closed source skjuler også den ene ting, der skal til for at styrke sikkerheden af kildekoden, idet der henvises til et trusselsbillede, der ikke stemmer overens med moderne IT-kriminalitet.
Der er nærliggende at tro, at den egentlige motivation for closed source ikke er trusselsbilledet, men at adgangen til kildekoden søges begrænset, så ingen opdager, hvor mangelfuld, closed source-virksomhedernes sikkerhed er med hensyn til såvel design, implementation som til test og drift. Så længe kildekoden og dens akkompagnerende dokumentation og processer holdes hemmelige, er det muligt at undgå de uprofitable sikkerhedsinspektioner, som open source til enhver tid udsættes for.
Leave a comment