"Prevention is ideal, detection is a must" on Dr. Eric Colen tunnettu lausahdus, joka alun perin liittyi tietoverkkojen turvallisuuteen. Kaikkea pahaa ei voi estää tapahtumasta, joten tärkeintä on havaita niin käyneen ja reagoida siihen suunnitellulla tavalla. Ajattelumalli on tuttu paloturvallisuudesta: emmehän pyri kaikin keinoin estämään tulipaloa syttymästä, vaan keskitymme havaitsemaan palon nopeasti ja estämään sen leviämisen.
Kun tietoturvatyötä tehdään, olipa kyse riskienhallinnasta tai uhkamallinnuksesta, tavoitteena on usein uhkien torjuminen tai estäminen. Tämä on kuitenkin epärealistista: emme voi estää esimerkiksi rikollista lähettämästä kalasteluviestejä, mutta voimme pyrkiä tunnistamaan ne, ja toimimaan suunnitellusti tunnistamisen jälkeen.
Tietoturvahaavoittuvuudet voidaan rinnastaa kyteviin paloihin, jotka voivat roihahtaa ilmiliekkeihin sopivissa olosuhteissa. Ohjelmointivirheet ovat väistämättömiä, mutta olennaista on havaita ne ajoissa ja korjata ne tehokkaasti. Testaaminen on keskeinen keino havaita virheet. Korjaamisen tulee kuitenkin olla muutakin kuin yksittäisen virheen paikkaamista: on tärkeää selvittää, miten ja miksi virhe syntyi, ja varmistaa, ettei vastaava ongelma toistu muualla. Näin virheistä opitaan ja edistetään ennaltaehkäisyä.
Korjaaminen ei ole ilmaista
Ohjelmistokehityksessä tuotepäällikön näkökulmasta kehittäjien aika tulisi käyttää liiketoiminnallisesti merkityksellisten ominaisuuksien kehittämiseen. Uuden koodin tuottamisen ja virheiden korjaamisen välillä tasapainoilu on jatkuvaa. Siksi prosessitasolla kannattaa panostaa ehkäisyyn, jotta samoja virheitä ei tarvitse korjata yhä uudelleen.
Turvallisuudesta laadunvarmistamiseen
Tietoturvan ja laadunvarmistuksen prosesseissa on kyse jatkuvasta oppimisesta ja parantamisesta. Erojakin on. Esimerkiksi paloturvallisuudessa lopputuotetta ei arvioida samalla tavoin kuin ohjelmistokehityksessä: tulipalon syttyminen on joko-tai-ilmiö, kun taas ohjelmiston laatuun liittyy tiettyjä toleransseja. Ohjelmistourvallisuudessa ehkäisy tarkoittaa dynaamista suodatusmekanismia tai laadunvalvontaa, joka itseään arvioiden kehittyy ajan myötä.
Palovaroitin voi epäsuorasti kertoa, kuinka hyvin olemme onnistuneet ehkäisemään tulipaloja – samoin ohjelmistokehityksessä havaitsevat mekanismit voivat raportoida myös oman toimivuutensa tasosta.
"Turvallisuus on jatkuvan parantamisen prosessi – ja laadunvarmistus sen ytimessä."
Tietoturvallisen ohjelmiston tuottaminen on vaikeaa, joten tietoturvaa on tarkasteltava ajoissa ja usein. Kuten tietokonepeleissä sanotaan: "Save early, save often" – ohjelmistokehityksessä sama pätee testaukseen: "Test early, test often."
Tietoturva ei ole pelkästään tekninen ongelma. Einsteinia mukaillen: "Emme voi ratkaista ongelmia samalla ajattelulla, joka ne synnytti." Kun havaitaan puutteita virheiden korjaamisessa, ongelma ratkeaa usein vain tarkastelemalla prosessia uudelta tasolta.
Turvallisuus ei siis ole ole "pelkästään" riskienhallintaa, vaan se on sisäisiltä periaatteiltaan laadunvarmistamista. Toisin päin ilmaistuna, laadunvarmistuksen edellyttäminen on osa riskienhallintaa. Tämä linkki turvallisuuden ja laadunvarmistuksen välillä tavoittaa jotain niitä isompaa: jatkuvan parantamisen mallin.