Risiko og tiltak forbundet med bruk av biblioteker i forretnings systemkonstruksjon

I dagens samfunn er systemkomponenten kjent som “biblioteket” blitt essensielt i konstruksjonen av forretningssystemer. Imidlertid er det også risiko forbundet med bruk av biblioteker. Ubevisst bruk av disse kan utløse problemer, og i verste fall kan det til og med føre til alvorlige skader som informasjonslekkasje. I denne artikkelen vil vi forklare risikoene forbundet med bruk av biblioteker og hvordan man kan håndtere dem.

Hva er et bibliotek?

Ved bygging av forretningssystemer, er det sjelden at IT-selskaper lager alle nødvendige programmer selv. I stedet er det vanlig å bygge en grunnmur med “ferdige programvaredeler”, og fylle inn manglende deler med egenprodusert programvare. Disse ferdige programvaredelene kalles “biblioteker”. Det er vanlig å bruke biblioteker for å utvikle generelle funksjoner. Generelle funksjoner er funksjoner som “innloggingsfunksjon” eller “funksjon for å hente data fra en database”, som er i høy etterspørsel i alle bransjer og i alle land. Det finnes biblioteker som støtter slike høy etterspørselsfunksjoner. På den annen side, for funksjoner som ikke er generelle, som å oppfylle unike kundekrav, vil IT-selskaper måtte lage dem selv, da det ikke finnes ferdige biblioteker.

For øvrig er det et ord som ligner på bibliotek, nemlig rammeverk. Det er også et ord som heter OSS (Open Source Software). I konteksten av forretningssystemer, er OSS det samme som biblioteket nevnt i denne artikkelen, og kan være et mer kjent begrep. Men i denne artikkelen vil vi bruke ordet bibliotek konsekvent.

Fordelene med biblioteker: Raskt og sikkert

Det er to hovedgrunner til at systemfirmaer foretrekker å bruke biblioteker fremfor å lage egne løsninger.

• Det er raskere enn å lage egne løsninger
• Det gir høyere sikkerhet enn å lage egne løsninger

At det er raskere er selvsagt når man bruker ferdige produkter, men en stor fordel er også at det gir bedre sikkerhet. Grunnen til dette er at kjente biblioteker kontinuerlig blir utviklet, testet og brukt i produksjonsmiljøer av dyktige ingeniører og selskaper over hele verden. Dette betyr at det er tiltak på plass mot kjente angrepsmetoder, og at det kan forventes raske oppdateringer hvis nye angrepsmetoder blir oppdaget. På den annen side, hvis man prøver å lage egne løsninger uten å bruke biblioteker, kan det være nødvendig å involvere ekspertvurderinger for å vurdere sikkerhetsproblemer, noe som kan medføre ekstra arbeid. I slike tilfeller kan det også være at det koster mer å forbedre sikkerheten. På grunn av disse forholdene blir bruken av biblioteker viktig hvis man ønsker å utvikle systemer raskere og sikrere.

Ulemper med biblioteker

Bruk av biblioteker kan være svært fordelaktig for både kunder og systemfirmaer, da det tillater rask og sikker systemutvikling. På den annen side, medfører bruk av biblioteker også visse kostnader. I tillegg finnes det en dilemma: hvis du ikke oppdaterer, kan det være en risiko for “sårbarheter”, og hvis du oppdaterer, kan systemet slutte å fungere.

Sårbarheter hvis du ikke oppdaterer

Kriminelle som planlegger å stjele personlig informasjon, kredittkortinformasjon, eller bedriftshemmeligheter, leter kontinuerlig etter sikkerhetssvakheter i alle typer programvare, inkludert biblioteker. Disse sikkerhetssvakheter kalles “sårbarheter” i IT-terminologi. Det er mange eksempler på skade forårsaket av utnyttelse av sårbarheter i brukte biblioteker. For eksempel, ble omtrent 200 000 kundeopplysninger lekket etter et angrep på en sårbarhet i Struts2-biblioteket som ble brukt på en spørreundersøkelsesside for det japanske transportdepartementet. Det er også et eksempel der en billettsalgsnettsted som brukte Struts2, kan ha lekket 32 187 kredittkortinformasjoner. Sårbarheter i biblioteket som var ukjente på leveringstidspunktet for systemet, kan også bli avslørt senere.

Oppdatering innebærer risiko for systemstopp

I praksis kan det være tilfeller der du ikke kan oppdatere til tross for sårbarheter. Dette skyldes risikoen for at systemet midlertidig kan slutte å fungere på grunn av oppdateringen. Biblioteker er ikke programmer skrevet av systemfirmaer, så det er praktisk talt umulig å fullt ut forstå innholdet. Derfor er det uunngåelig at det er en risiko for uventede feil i systemet på grunn av oppdateringen, noe som kan føre til at systemet midlertidig slutter å fungere. Som kunde kan du bli frustrert over systemfirmaet for ikke å forstå innholdet i det leverte systemet. Men det er også en realitet at bibliotekene som brukes i moderne systemer, både i kvalitet og kvantitet, er mer enn hva et enkelt systemfirma kan håndtere. For eksempel, er det et bibliotek kalt “React” som er svært populært for å bygge brukergrensesnitt. Dette biblioteket er av høy kvalitet, laget av Facebook-ingeniører, og er enormt i kvantitet, med 195 486 linjer med kode (※1).

Saker der sårbarhet har blitt rettslig

Når skade oppstår på grunn av sårbarhet i et bibliotek, oppstår spørsmålet om hvem som bærer ansvaret. En referanse til dette er dommen fra Tokyo District Court den 23. januar 2014 (Heisei 26). Saksøkeren hadde kontraktet systemfirmaet, som er saksøkte, for å bygge et salgssystem. Imidlertid, etter at systemet ble operativt, lekket kredittkortinformasjonen til sluttbrukerne på grunn av systemets sårbarhet, og saksøkeren led skader på omtrent 32 millioner yen på grunn av unnskyldninger og undersøkelser, noe som førte til en tvist. I kontrakten som saksøkeren og saksøkte inngikk, var det en ansvarsfraskrivelsesklausul som begrenset erstatningsbeløpet til kontraktbeløpet i tilfelle skade oppstod på grunn av saksøktes uaktsomhet. Om denne ansvarsfraskrivelsesklausulen kunne brukes eller ikke, ble et stridspunkt. Dommen beordret saksøkte til å betale erstatning som oversteg kontraktbeløpet, da det ble funnet grov uaktsomhet hos saksøkte.

Saksøkte, som et selskap som driver virksomhet ved å bruke spesialisert kunnskap om programmering, som planlegging av informasjonsbehandlingssystemer, produksjon av hjemmesider, utvikling av forretningssystemer, etc., og som leverte denne webapplikasjonen som en del av sin virksomhet, kan det antas at saksøkeren inngikk denne systembestillingskontrakten ved å stole på den spesialiserte kunnskapen, og graden av forsiktighet som kreves av saksøkte kan anses for å være relativt høy. Som nevnt ovenfor, hvis SQL-injeksjonstiltak ikke er tatt, kunne det forutses av saksøkte at personlig informasjon kunne lekke fra denne databasen ved at en tredjepart utfører en SQL-injeksjonsangrep, og i tillegg, gitt at det japanske økonomi-, handels- og industridepartementet og IPA har oppført SQL-injeksjonsangrep som en representativ angrepsmetode mot webapplikasjoner, og har oppfordret til forsiktighet, kunne det lett forutses at en slik situasjon kunne oppstå. I tillegg, ved å bruke bindemekanismen eller utføre escape-behandling, kunne resultatet av denne lekkasjen ha blitt unngått, og det er ingen bevis som antyder at det ville ta mye arbeid eller kostnader å utføre denne behandlingen for å unngå lekkasjen, så det kan sies at det var lett å unngå dette resultatet. Derfor, det kan sies at det er grov uaktsomhet hos saksøkte.

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

En tolkning av denne presedensen i konteksten av bibliotekssårbarhet er beskrevet i følgende dokument fra Software Information Center Foundation.

Basert på tankegangen i denne presedensen, selv om skade oppstår for brukeren på grunn av en feil (sårbarhet, etc.) i OSS, hvis det er anerkjent at leverandøren har forsømt å håndtere sårbarheten med vilje eller grov uaktsomhet, er det høy sannsynlighet for at ansvarsfraskrivelsesklausulen (ansvarsbegrensningsklausulen) vil bli begrenset i sin anvendelse, og det vil ikke være mulig å oppnå effekten av ansvarsfraskrivelse. Imidlertid, hvis et angrep mottas umiddelbart etter at sårbarhetsinformasjon for OSS er publisert, kan det være fullt mulig at grov uaktsomhet ikke vil bli anerkjent, for eksempel ved å nekte lettheten av å unngå resultatet.

Samling av juridiske problemer ved bruk av OSS i IoT-tiden Q&A [PDF] (side 84)

Således, selv om det er en sårbarhet som skyldes et bibliotek, hvis det er en kjent sårbarhet og det er lett å forutsi et angrep, er det sannsynlig at det vil bli behandlet som et ansvar for systemfirmaet.

Hva er mer realistiske tiltak mot sårbarheter?

Hvis det oppstår en informasjonslekkasje på grunn av systemfirmaets forsett eller grov uaktsomhet, kan det forventes at kompensasjon kan oppnås gjennom søksmål. Men fra et praktisk synspunkt, er det viktigste å forhindre lekkasjen i utgangspunktet. Selv om du mottar kompensasjon gjennom en rettssak, kan du ikke gjenopprette tilliten fra sluttbrukerne som ble tapt på grunn av informasjonslekkasjen. For dette er følgende to ting viktige:

1. Inngåelse av vedlikeholdsavtaler, inkludert biblioteksoppdateringer
2. Sårbarhetsvurdering

Inngåelse av vedlikeholdsavtaler, inkludert biblioteksoppdateringer

Det er to typer kontrakter for bygging av forretningssystemer: de som kun tildeler utvikling, og de som også tildeler vedlikehold. Hvis du ikke har en spesialist som kan utføre vedlikehold i din egen bedrift, er det passende å inngå en vedlikeholdsavtale. I kontrakten kan du be systemfirmaet om å ta hånd om sårbarhetstiltak, inkludert biblioteksoppdateringer, og forhindre problemer ved å klargjøre systemfirmaets forpliktelser og kundens betalingsforpliktelser. Det kan sies at det er nødvendig å ha en kontrakt der kunden også bærer tilstrekkelige kostnader for å be en spesialist om å håndtere det.

Sårbarhetsvurdering

Mens mengden data som systemet håndterer og kravene til UI øker hver dag, fortsetter antallet nyoppdagede sårbarheter å øke. Derfor er det en vanskelig situasjon å fullstendig forhindre innføring av sårbarheter bare med systemfirmaet. Derfor er det nødvendig med en sårbarhetsvurdering. Ifølge IPA, utfører mer enn 50% av alle bedrifter og 80% av store bedrifter sårbarhetsvurderinger.

Det er mange forskjellige typer sårbarhetsvurderinger, fra gratis verktøy til dyre manuelle vurderinger. Spesielt når du håndterer informasjon som det ville være katastrofalt å lekke, vil det være nødvendig å tildele tilstrekkelige kostnader og ta tiltak ved å tildele sårbarhetsvurderingen til en spesialisert operatør. I tillegg oppdages sårbarheter hver dag, så det er viktig å fortsette å utføre sårbarhetsvurderinger (P15) ikke bare ved levering, men også etter levering.

Oppsummering

I denne artikkelen har vi diskutert risikoene forbundet med bruk av biblioteker og hvordan man kan håndtere dem. Selv om biblioteker er svært nyttige, kan det oppstå sikkerhetssårbarheter og skader som informasjonslekkasje hvis de ikke oppdateres, noe som også innebærer risiko. Juridisk sett kan det forventes at man kan motta kompensasjon for informasjonslekkasje hvis det er grov uaktsomhet fra systemfirmaets side, men i praksis er det viktig å ta forholdsregler for å forhindre informasjonslekkasje i utgangspunktet. For å gjøre dette, bør du bli enig om arbeidstiden for bibliotekoppdateringer og sårbarhetsvurderinger i kontrakten. Hvis du ikke bruker biblioteket, er det nesten umulig å oppnå det nødvendige nivået av både leveringstid og funksjonalitet. For å unngå problemer og dra nytte av fordelene med biblioteker, er det nødvendig å komme til enighet om kostnadene for oppdateringer og tiltak mot sårbarheter mellom deg og systemfirmaet. For å unngå å påføre virksomheten din en fatal slag gjennom informasjonslekkasje, er det viktig å være oppmerksom på sikkerhet fra kontraktstidspunktet, ikke bare på elementer som funksjonalitet, skjermlayout og pris.