Turvallisuus lopussa vastaan turvallisuus alusta asti: päätös, joka määrittää toimitusriskin

Kaksi tiimiä. Sama tavoite. Hyvin erilaiset lopputulokset.

Tiimi A rakentaa ratkaisun eristyksissä ja ottaa tietoturvavastaavan mukaan vasta, kun kehitys on suurelta osin valmis, kun taas Tiimi B tuo Tietoturvan keskusteluun siinä vaiheessa, kun ratkaisua vielä muotoillaan ja arkkitehtuuria, tietovirtoja sekä käyttöoikeusmalleja määritellään.

Pintapuolisesti molemmat tiimit näyttävät tavoittelevan samaa päämäärää, eli toimivan ohjelmiston toimittamista, joka lopulta täyttää tietoturvavaatimukset, mutta käytännössä valittu etenemistapa vaikuttaa suoraan ja mitattavasti kustannuksiin, riskiin ja toimitusaikatauluun.

Kun turvallisuus tulee mukaan vasta lopussa

Tiimi A osoittaa yleensä vahvaa alkunopeutta, koska päätökset tehdään ilman rajoitteita, arkkitehtuuri määritellään nopeasti ja ominaisuuksia toteutetaan ilman tarvetta huomioida ulkoista validointia; tämä koettu nopeus on kuitenkin väliaikaista, sillä kun järjestelmä altistetaan muodolliselle tietoturvatarkastukselle, alkaa paljastua ongelmia, jotka eivät ole pinnallisia vaan rakenteellisia siinä tavassa, jolla järjestelmä on suunniteltu.

Tunnistautumismallit eivät ehkä täytä vaadittuja standardeja, tiedonkäsittelyn lähestymistavat voivat tuoda vaatimustenmukaisuusriskejä, pääsynhallintamekanismit voivat olla riittämättömiä, ja monissa tapauksissa kyse ei ole yksittäisistä virheistä vaan suunnittelutason ongelmista, jotka vaativat uudelleentyötä useissa järjestelmän osissa yksinkertaisten korjausten sijaan.

Tässä vaiheessa tietoturva nähdään usein esteenä, mutta todellisuudessa se toimii korjaavana voimana, joka tunnistaa aukkoja, jotka syntyivät aiemmin, kun päätöksiä tehtiin ilman täydellistä kontekstia; seuraukset ovat ennustettavia: viivästyksiä, kasvavia kustannuksia, päällekkäistä työtä ja lisääntyvää kitkaa kehitys- ja tietoturvatiimien välillä toimituspaineen kasvaessa.

Kun turvallisuus muovaa suunnittelua

Tiimi B toimii perustavanlaatuisesti erilaisella mallilla integroimalla Tietoturvan suunnitteluvaiheeseen ja varmistamalla, että uhkamallinnus, tietojen luokittelu, käyttöoikeusrajat ja vaatimustenmukaisuuteen liittyvät näkökohdat käsitellään samanaikaisesti toiminnallisten vaatimusten kanssa eikä vasta jälkikäteen.

Tämä ei vähennä kehitysnopeutta millään merkittävällä tavalla, vaan muuttaa itse kehityksen luonnetta, koska päätökset tehdään täydellisessä ymmärryksessä rajoitteista, kompromissit ovat eksplisiittisiä sattumanvaraisten sijaan ja arkkitehtuurivalinnat linjataan alusta alkaen sekä operatiivisten että tietoturvavaatimusten kanssa.

Tämän seurauksena toimituksesta tulee ennustettavampaa, uudelleentyö vähenee merkittävästi ja tuotantoon päätyvä järjestelmä ei ole vain toimiva vaan myös kestävä, auditoitava ja kykenevä toimimaan todellisissa olosuhteissa ilman tarpeetonta organisatorista riskiä.

Ero on toimintamallin kypsyydessä

Ero näiden kahden lähestymistavan välillä ei ole prosessimieltymys vaan toimintamallin kypsyys, jossa Tiimi A kohtelee Tietoturvaa lopullisena tarkastuspisteenä, joka validoi jo rakennetun, kun taas Tiimi B kohtelee Tietoturvaa suunnittelukumppanina, joka muovaa sitä, mitä rakennetaan.

Vain toinen näistä malleista skaalautuu tehokkaasti järjestelmien monimutkaistuessa ja organisaatioiden tullessa yhä riippuvaisemmiksi ohjelmistojensa luotettavuudesta ja eheydestä.

Jos organisaatiosi toimii yhä kuten Tiimi A, kysymys ei ole siitä vaikuttaako tämä toimitukseen, vaan milloin.

Ota yhteyttä Libertas Software Researchiin nähdäksesi, miten voimme auttaa sinua siirtymään malliin, joka toimittaa turvallisesti, ennustettavasti ja mittakaavassa.