Risici og foranstaltninger forbundet med brug af biblioteker i forretnings systemopbygning

I den moderne verden er det essentielt at inkludere ‘biblioteker’ som en del af systemopbygningen i forretningsprocesser. Men der er også risici forbundet med brugen af biblioteker. Hvis man er ligeglad med disse risici og fortsætter med at bruge dem, kan det udløse problemer, og i værste fald kan det endda føre til alvorlige skader som datalækager. I denne artikel vil vi forklare de risici, der er forbundet med brugen af biblioteker, og hvordan man kan imødegå dem.

Hvad er et bibliotek?

Ved opbygning af forretningssystemer er det sjældent, at et systemfirma skaber alle de nødvendige programmer selv. I stedet er det almindeligt at skabe en grundlæggende struktur ved hjælp af “færdiglavede softwarekomponenter” og derefter skabe de manglende dele selv. Disse færdiglavede softwarekomponenter kaldes “biblioteker”. Generelle funktioner er typisk udviklet ved hjælp af biblioteker. Generelle funktioner er høj efterspørgselsfunktioner, der er almindelige i alle brancher og systemer i alle lande, såsom “login-funktioner” og “funktioner til at hente data fra databaser”. Der findes biblioteker, der understøtter disse høj efterspørgselsfunktioner. På den anden side, for funktioner, der ikke er generelle, såsom at opfylde unikke kundebehov, vil systemfirmaet skulle skabe dem selv, da der ikke findes færdiglavede biblioteker.

Det skal bemærkes, at der også er et ord, “framework”, der har en lignende betydning som bibliotek. Der er også et ord, OSS (Open Source Software). I konteksten af forretningssystemer er OSS de samme som biblioteker, som nævnt i denne artikel, men det kan være et mere velkendt udtryk. Men i denne artikel vil vi bruge ordet bibliotek konsekvent.

Fordele ved biblioteker: Hurtigt og sikkert

Der er to grunde til, at systemfirmaer prioriterer brugen af biblioteker frem for at bygge deres egne.

• Det er hurtigere end at bygge selv
• Det er mere sikkert end at bygge selv

At det er hurtigere er en selvfølge, når man bruger færdiglavede produkter, men en stor fordel er også, at det er mere sikkert. Dette skyldes, at kendte biblioteker er under konstant udvikling, verifikation og brug i produktionen af dygtige ingeniører og virksomheder over hele verden. Derfor er der allerede truffet foranstaltninger mod kendte angreb, og hurtige opdateringer kan forventes, hvis nye angreb opdages. Omvendt, hvis man forsøger at bygge selv uden at bruge et bibliotek, kan det være nødvendigt at inddrage en ekspertvurdering for at overveje sikkerhedsspørgsmål, hvilket kan være tidskrævende. I sådanne tilfælde kan det ende med at være dyrt at forsøge at forbedre sikkerheden. På grund af disse omstændigheder bliver brugen af biblioteker vigtig, hvis man ønsker at fremskynde og sikre systemudviklingen.

Ulemper ved biblioteker

Brugen af biblioteker kan være meget fordelagtig for både kunder og systemfirmaer, da det gør det muligt at opbygge systemer hurtigt og sikkert. På den anden side er der også visse omkostninger forbundet med brugen af biblioteker. Der er også et dilemma, hvor der er en risiko for, at “sårbarheder” kan blive indført, hvis der ikke opdateres, og en risiko for, at systemet kan stoppe med at fungere, hvis der opdateres.

Hvis du ikke opdaterer, er der sårbarheder

Kriminelle, der planlægger at stjæle personlige oplysninger, kreditkortoplysninger og virksomhedshemmeligheder, leder dagligt efter sikkerhedsmangler i alle slags software, herunder biblioteker. Disse sikkerhedsmangler kaldes “sårbarheder” i IT-terminologi. Der er mange eksempler på skader forårsaget af sårbarheder i de anvendte biblioteker. For eksempel blev omkring 200.000 kundeoplysninger lækket, da en sårbarhed i et bibliotek kaldet Struts2, der blev brugt på det japanske Ministerium for Land, Infrastruktur, Transport og Turismes (国土交通省) spørgeskemaside, blev angrebet. Der er også et eksempel, hvor en billetsalgsside, der også brugte Struts2, muligvis har lækket 32.187 kreditkortoplysninger. Der kan også være tilfælde, hvor sårbarheder i biblioteket, der var ukendte på tidspunktet for systemlevering, senere bliver opdaget.

Opdatering indebærer risiko for systemnedetid

I praksis kan der være tilfælde, hvor det ikke er muligt at opdatere, selvom der er sårbarheder. Dette skyldes, at der er en risiko for, at systemet midlertidigt kan stoppe med at fungere på grund af opdateringen. Da biblioteker ikke er programmer, som systemfirmaet har skrevet, er det praktisk talt umuligt at fuldt ud forstå indholdet. Derfor er det uundgåeligt, at der er en risiko for, at uforudsete fejl kan opstå i systemet på grund af opdateringen, og at systemet midlertidigt kan stoppe med at fungere. Som kunde kan du måske føle dig frustreret over systemfirmaet, hvis du ikke forstår indholdet af det leverede system. Men det er også en kendsgerning, at de biblioteker, der bruges i moderne systemer, både i kvalitet og mængde, er mere end hvad et enkelt systemfirma kan håndtere. For eksempel er der et bibliotek kaldet “React”, som er meget populært for opbygning af brugergrænseflader. Dette bibliotek er meget avanceret, da det er blevet oprettet af Facebooks ingeniører, og det er også enormt i mængde, med 195.486 linjer af kode (※1).

Sager hvor sårbarheder har ført til retssager

Der er et spørgsmål om, hvem der bærer ansvaret, når der opstår skader på grund af sårbarheder i biblioteker. En reference til dette er dommen fra Tokyo District Court den 23. januar 2014 (Heisei 26). Sagsøgeren havde outsourcet opbygningen af et salgssystem til sagsøgte, et systemfirma. Men efter systemet blev sat i drift, lækede kreditkortoplysninger fra slutbrugere på grund af systemets sårbarhed, og sagsøgeren led skader på omkring 32 millioner yen på grund af undskyldninger og undersøgelser, hvilket førte til en tvist. I kontrakten, som sagsøgeren og sagsøgte havde indgået, var der en ansvarsfraskrivelsesklausul, der begrænsede erstatningsbeløbet til kontraktbeløbet, hvis skader opstod på grund af sagsøgtes uagtsomhed. Spørgsmålet var, om denne ansvarsfraskrivelsesklausul kunne anvendes. Dommen beordrede sagsøgte til at betale erstatning ud over kontraktbeløbet, idet det blev fastslået, at sagsøgte havde grov uagtsomhed, og at ansvarsfraskrivelsesklausulen ikke kunne anvendes i tilfælde af grov uagtsomhed.

Sagsøgte, som driver en virksomhed, der udnytter specialiseret viden om programmering, såsom planlægning af informationssystemer, oprettelse af hjemmesider og udvikling af forretningssystemer, og som leverede denne webapplikation som en del af sin virksomhed, kan antages at have indgået denne systemordrekontrakt i tillid til denne specialiserede viden. Det kan anerkendes, at den grad af omhu, der kræves af sagsøgte, er relativt høj. Som nævnt ovenfor, hvis der ikke er truffet foranstaltninger mod SQL-injektion, kunne det forudses af sagsøgte, at personlige oplysninger kunne lække fra denne database som følge af en tredjeparts SQL-injektionsangreb, og da både Ministeriet for Økonomi, Handel og Industri og IPA har nævnt SQL-injektionsangreb som en typisk angrebsmetode mod webapplikationer og har opfordret til forsigtighed, kunne det let forudses, at en sådan situation kunne opstå. Desuden, ved at bruge bind-mekanismen eller udføre escape-behandling, kunne resultatet af denne lækage have været undgået, og der er ingen beviser for, at det ville have krævet stor indsats eller omkostninger at tage tekniske foranstaltninger for at undgå dette, så det kan siges, at det ville have været let at undgå resultatet af denne lækage. Derfor bør det siges, at sagsøgte kan anerkendes at have grov uagtsomhed.

Dom fra Tokyo District Court den 23. januar 2014 (Heisei 26)

Den følgende beskrivelse i materialet fra den almennyttige stiftelse Software Information Center er en fortolkning af denne præcedens i konteksten af sårbarheder i biblioteker.

Forudsat at vi følger tankegangen i denne præcedens, selvom der opstår skader på brugeren på grund af fejl (sårbarheder osv.) i OSS, hvis det kan anerkendes, at leverandøren forsømte at håndtere sårbarheder med vilje eller grov uagtsomhed, er det sandsynligt, at ansvarsfraskrivelsesklausulen (ansvarsbegrænsningsklausulen) vil blive begrænset i sin anvendelse, ligesom i dette tilfælde, og det vil være svært at opnå effekten af ansvarsfraskrivelse. Men hvis du bliver angrebet lige efter at oplysningerne om sårbarheder i OSS er blevet offentliggjort, er det fuldt muligt, at det ikke vil blive anerkendt som grov uagtsomhed, da det vil være svært at undgå resultatet.

Q&A om juridiske problemer ved brug af OSS i IoT-tiden [PDF][ja] (side 84)

Således, selvom det er en sårbarhed, der skyldes et bibliotek, hvis det er en kendt sårbarhed, og det er let at forudse et angreb, er det sandsynligt, at det vil blive behandlet som et systemfirma’s ansvar.

Hvad er mere realistiske sårbarhedsforanstaltninger?

Hvis der opstår en informationslækage på grund af systemfirmaets forsætlige eller grove uagtsomhed, kan det forventes, at kompensation kan opnås gennem retssager. Men fra et praktisk synspunkt er det vigtigste at forhindre lækagen i første omgang. Selvom du modtager kompensation gennem en retssag, kan du ikke gendanne tilliden fra slutbrugeren, der blev tabt på grund af informationslækagen. Derfor er følgende to punkter vigtige:

1. Indgåelse af en vedligeholdelsesaftale, inklusive biblioteksopdateringer
2. Sårbarhedsvurdering

Indgåelse af en vedligeholdelsesaftale, inklusive biblioteksopdateringer

I kontrakter om opbygning af forretningssystemer er der tilfælde, hvor kun udvikling er outsourcet, og tilfælde, hvor vedligeholdelse også er outsourcet. Hvis du ikke har en specialist, der kan udføre vedligeholdelse i din egen virksomhed, er det passende at indgå en vedligeholdelsesaftale. I kontrakten kan du forhindre problemer ved at anmode systemfirmaet om at tage sårbarhedsforanstaltninger, inklusive opdatering af biblioteket, og ved at gøre kundens betalingsforpligtelse i overensstemmelse med systemfirmaets forpligtelser klart. Mens systemfirmaet er forpligtet til at reagere som en specialist, skal kunden også indgå en kontrakt, der kræver, at de bærer tilstrækkelige omkostninger til at anmode om en specialist.

Sårbarhedsvurdering

Mængden af data, der håndteres af systemet, og kravene til UI stiger dag for dag, mens antallet af nyopdagede sårbarheder fortsætter med at stige. Derfor er det svært for systemfirmaet alene at forhindre fuldstændig indførelse af sårbarheder. Det er her, sårbarhedsvurdering bliver nødvendig. Ifølge IPA har over halvdelen af alle virksomheder og 80% af store virksomheder gennemført sårbarhedsvurderinger.

Sårbarhedsvurderinger spænder fra gratis værktøjer til dyre manuelle vurderinger. Især når man håndterer information, hvis lækage ville være katastrofal, ville det være afgørende at tildele tilstrækkelige omkostninger til at tage foranstaltninger ved at outsource sårbarhedsvurdering til specialiserede virksomheder. Desuden opdages sårbarheder dagligt, så det er vigtigt at fortsætte med at udføre sårbarhedsvurderinger[ja] (P15) ikke kun ved leveringstidspunktet, men også efter levering.

Opsummering

I denne artikel har vi diskuteret risiciene forbundet med brugen af biblioteker og hvordan man håndterer dem. Biblioteker er meget praktiske, men de kan også medføre risici, såsom sårbarheder og datalækager, hvis de ikke opdateres. Juridisk set kan man forvente kompensation for datalækager, hvis der er grov uagtsomhed fra systemfirmaets side, men i praksis er det vigtigt at træffe foranstaltninger for at forhindre datalækager i første omgang. Det vil være hensigtsmæssigt at blive enige om arbejdstiden for biblioteksopdateringer og sårbarhedstest i kontrakten. Hvis du ikke bruger biblioteker, er det næsten umuligt at opnå det nødvendige niveau af både leveringstid og funktioner. For at nyde fordelene ved biblioteker uden problemer, er det nødvendigt at blive enige om omkostningerne ved opdateringer og foranstaltninger mod sårbarheder med systemfirmaet. For at undgå at lide en fatal slag mod din virksomhed på grund af datalækager, er det vigtigt at være opmærksom på ikke kun funktioner, skærm layout og pris, men også sikkerhed fra kontraktens start.