Virksomhedsledere lukker øjnene for it-sikkerhedskrav

I 2017 blev Gitlab, en online remote collaboration-tjeneste til styring af kildekoder, ramt af en katastrofal sikkerhedshændelse, der resulterede i tab af produktionsdata.

Ingen onde hackere, ingen APT'er, bare en ganske almindelig, gammeldags, menneskelig fejl, hvor data blev overskrevet.

Heldigvis havde Gitlab sikkerhedskopier af hele deres 300 gigabyte store database. Altså indtil de forsøgte at gendanne den overskrevne produktionsdata, og det viste sig, at ingen af de fem implementerede backup- og replikationsteknikker fungerede - eller endda var opsat korrekt.

Næsten alle data gik tabt, og kunderne var vrede, triste og forvirrede. Burde en kode-samarbejdsplatform, der bruges af titusinder af slutbrugere, ikke udføre gendannelsestests?

Og hvad med slutbrugerne; antog de alle bare, at tjenesten til at styre udviklingen af deres missionskritiske projekter ville have disse slags grundlæggende funktioner på plads?

Sikkerhed, privatliv, pålidelighed. Utroligt ladede og tvetydige termer, men en ting er sikkert: Hvad vi end laver i vores daglige liv, så vil vi have dem alle, vi vil have dem i går, og de har bare at være gratis.

Vi ved, hvordan vi sikrer os i dagligdagen

I de fleste situationer i vores daglige liv ved vi, hvordan vi kan sikre os sikkerhed, privatliv og pålidelighed, eller i det mindste ved vi, hvad de tre ord betyder.

Enten ud fra vores egne personlige oplevelser eller fra en person tæt på os.

Det kunne være at fjerne værdigenstande fra din bil, fordi du ved, at der ikke er noget, du kan gøre for at forhindre et indbrud, hvis nogen virkelig gerne vil ind i bilen.

Det kunne også være at sikkerhedskopiere dine filer, fordi du ved, at computeren i sidste ende vil gå i stykker. Eller det kunne være at investere i et alarmsystem, låse din cykel eller sørge for at have en ekstra nøgle til din lejlighed i dine forældres hus.

Alle disse eksempler er investeringer i den helt tætte eller nærmeste fremtid. De spiller en grundlæggende rolle i ens liv, idet de vejer risikoen op mod resultatet, når det kommer til personligt og fælles ansvar.

Men det gælder normalt kun, når det værste allerede er sket, og når vi eller nogen, vi kender, er blevet personligt påvirket og vi kan vurdere skaden direkte. Eksemplerne ovenfor kræver ikke de store begrundelser.

Du er ganske simpelt nødt til at fjerne dine værdigenstande fra din bil, fordi du ikke kan forvente, at nogen ikke bryder ind i den, hvis der er noget, der er værd at bryde ind for.

Du kan heller ikke forvente, at en ekstra nøgle dukker op ud af det blå, eller at filer magisk gendanner sig selv, når din harddisk til sidst går i stykker. At ræsonnere mod disse eksempler er intet andet end naivitet og bevidst uvidenhed.

»Vores framework tager sig af det«

Når det kommer til software og IT-arkitektur, ser situationen ud til at være vendt.

Organisationer og virksomheder glemmer normalt, at det at finde ud af kravene til, hvad de har brug for, er en del af de samlede omkostninger, og det fejes normalt ind under gulvtæppet eller overlades til en person, der er ansvarlig for at se på, hvad alle andre bruger.

Når man spørger ind til, hvordan disse organisationer reducerer risikoen for brud på sikkerheden, hvordan de overvåger systemer og hvordan de sørger for, at der er en tilgang til sikkerhed i flere lag, er svaret som regel en lyd et sted mellem en dæmpet hoste og en akavet pause, der ender med en lidt forvirret knytnæve i bordet og en besked om, at sikkerhed er 'af største betydning'.

I virkeligheden bruges it- og udviklings-framework, og deres sikkerhedserklæringer samt anbefalinger på hjemmesiden kopieres til formelle requirement-dokumenter hos virksomhederne.

Når man spørger ind til, hvordan visse angrebsscenarier ville blive opdaget og reageret på, er svaret normalt kort:

»Vi bliver ikke ramt af den slags angreb, fordi vores software-framework tager sig af det. Ikke at vi har testet det eller har set på, hvordan disse angreb ville se ud, så vi kan genkende dem senere.«

Det er i det øjeblik under mødet, at smil bliver til nervøse trækninger.

Du får, hvad du betaler for

God sikkerhedsarkitektur, der er modstandsdygtig over for angreb eller misbrug, er først og fremmest baseret på en række krav og baseret på, hvad der kunne ske nu og i fremtiden - derefter udfylder man forventningerne i overensstemmelse hermed og ikke omvendt.

Det er for let at vælge en tilfældig feriedestination og derefter klage over, at hotelværelset ikke ligner billedet i brochuren.

Desværre vil de fleste virksomheder basere deres krav på de produkt- eller tjenesteydelser, der findes på markedet, snarere end at se på deres egne forretnings- og sikkerhedskrav.

Og i modsætning til, at du måske bliver nødt til at lide på den elendige hoteldestination i en uge, når du drikker den spanske frostvæske, som hotellet kalder vin, så har det meget større konsekvenser sikkerhedsmæssigt, når det kommer til produkter og tjenester, hvis de eksempelvis indeholder oplysninger om os selv, vores liv, eller når de repræsenterer en virksomheds liv eller død.

»Vi antog, at ...«

Den første sætning, der vender tilbage igen og igen, når vi taler med virksomheder og spørger dem om brud på sikkerheden både i fortiden og fremtiden er: »Vi antog, at«.

Vi antog, at hostingudbyderen ville patche softwaren for os hver uge. Vi antog, at telekonferencesystemerne, vi havde fået installeret og konfigureret af vores leverandør, havde fået ændret standardadgangskoden.

Vi antog, at vi ikke var et mål, og nu er vores intellektuelle ejendom stjålet. Vi antog, at vi havde sikkerhedskopier. Vi antog, at dette ikke ville ske, fordi det aldrig var sket før.

Og hvad ville softwareverdenen være uden dens foretrukne falske ækvivalens-erklæring: »Dette andet firma, der er større end os, købte det, så hvis det er godt nok for dem, er det godt nok for os.«

Det lyder måske velkendt og endda uskadeligt, men det er desværre stadig en af de mest brugte metoder for virksomheder, der skal udvikle eller købe software eller IT-tjenester. Og desværre også en af de grundlæggende årsager til brud på sikkerheden.

Mottoet i 1970’erne og 1980'erne var: 'Ingen blev fyret for at købe IBM'. Du kan erstatte IBM i dag med Microsoft, Amazon, Google og flere andre giganter, når det kommer til konstruktion og vedligeholdelse af IT-tjenester.

Jeg siger ikke, at man ikke bør bruge disse virksomheder, men at vælge en af disse it-giganters tjenester vil ikke på magisk vis sikre ens egen virksomhed datasikkerhed.

Det samme gælder, hvis man køber noget af en ven eller et familiemedlem. Det handler om at være i stand til at definere sine specifikke behov ud fra den brede vifte af tilbudte tjenester.

Desuden, jo mere funktionalitet en tjeneste har, som du ikke bruger eller glemmer, desto større angrebsoverflade og flere muligheder giver du en potentiel angriber, og desto flere kræfter skal du selv bruge for at sikre, at ingen vil udnytte eller misbruge disse muligheder.

Er skaden sket, kan man nemt forudsige, hvordan overraskelse og forundring bliver vævet ind i fremtidige pressemeddelelser. Uanset om det har været et målrettet hack eller et tilfældigt opgraderingsuheld. Det lyder som regel noget henad, at 'det var et yderst sofistikeret angreb' eller 'en hidtil ukendt situation'.

Jeg formoder, at sandheden i disse udsagn afhænger af øjnene, der ser, hvis der ikke var nogen krav, og der ikke blev udført nogen validering. Hvis du ikke forventer noget, er alt en overraskelse.

At købe er let, vedligeholdelse er svært

Det er nemt at lægge penge på bordet og købe noget internationalt - uanset om det er et stykke software, en service eller et hus. Det meste software, der anvendes af virksomheder i dag, er endda gratis.

Men ligesom med ethvert hus, gratis eller ej, så er vedligeholdelsen og det at være i stand til at se ud over i dag, dér, hvor tingene normalt begynder at gå galt. Malingen skaller af, der er mug på væggene, låsene er rustne, og vinduerne har ikke været i stand til at lukke i de sidste ti år.

Det svarer til at miste overblikket over, hvilke data, der er tilgængelige for andre på nettet, eller overblikket over, hvor du gemmer dine data.

Det er ikke at patche software i rette tid. Det er ikke at vide, hvor dine IT-leverandørers ansvar slutter, og hvor dit eget begynder.

Alt dette lyder trivielt og ligetil, men hvis ulven kan puste din dør omkuld, som var den lavet af strå, så starter the blame game og tidligere antagelsers spøgelser kommer frem for at hjemsøge én.

En streg i sandet

Den eneste rigtige måde at styre forventningerne på, når det kommer til it-produkt- eller serviceindkøb eller udvikling af disse, er konstant engagement. Fra udvikling til nedlukning og til at undgå data rot.

Og heri ligger problemet.

Sikkerhedsrådgivere arbejder ikke gratis, og virksomheder er tilbageholdende med at investere i partnerskaber til at hjælpe dem med denne del af ligningen.

Virksomheder bruger meget tid og projektstyring på, hvor lang tid udviklingen af projektet skal tage, hvad det skal koste, hvor meget funktionalitet kunden bad om, og hvornår tidsfristen er.

Når det kommer til validering af information security og afprøvning af summen af alle dele, kommer de fleste virksomheder dog ikke længere end user acceptance testing og de er bange for at enhver form for test i produktionen vil resultere i problemer.

Men hvis en test ikke kan udføres i produktionen med nærmest ingen reelle slutbrugere, hvordan kan man så forvente, at den har nogen modstandskraft mod reelle angreb?

Og ikke kun det, hvis dit flagskibsprodukt eller -tjeneste virkelig er så vigtig for dig, så vil du sandsynligvis bruge lidt tid og kræfter på redningsbåde og sørge for, at de passer på dækket, før du begynder at bygge skibet.

Og nej: Ikke at have testbrugerkonti i produktionen burde ikke være en blokerende faktor, da der også er krav til den del.

Stil de ubehagelige spørgsmål

Så på det næste møde, hvor du deltager, og hvor I taler om behovet eller kravet om et nyt IT-produkt eller -tjeneste:

Spørg om, hvad det vil blive brugt til.

Spørg om, hvem der bruger det nu og i fremtiden.

Spørg om, hvor længe I skal bruge IT-produktet eller -tjenesten, og hvornår I har det næste møde som dette.

Spørg om, hvad der vil ske, hvis den givne leverandør bliver insolvent eller forsvinder, og hvordan listen over risici skal se ud.

Hvis du ikke er en beslutningstager, kan du i det mindste påvirke beslutningen, og din stemme skal høres - enten under et møde eller på skrift.

Og hvis du synes, at du er for lille en fisk og ikke kan påvirke noget større end dig selv, så prøv at sove på et hotelværelse med en myg …