Miten tietoturvavaatimukset liittyvät ohjelmiston, järjestelmän tai palvelun kehitykseen? Usein ne nousevat esiin vasta siinä vaiheessa, kun tietoturvatarkastuksessa katselmoija kysyy: Mitkä ovat järjestelmän tai palvelun tietoturvavaatimukset? Valitettavasti tyypillinen vastaus on, että asiaa pitää tiedustella tietoturva-asiantuntijalta projektin ulkopuolelta. Että palataanpa niihin sitten myöhemmin.
Tämä paljastaa karulla tavalla, ettei tietoturvaa ole huomioitu suunnitteluvaiheessa, vaan se nähdään erillisenä vaiheena, joka toteutetaan jälkikäteen tai ”sitten joskus”. Usein tämä tarkoittaa, että tietoturvakonsultti tekee rajatun penetraatiotestauksen tai muun arvioinnin vasta kehityksen loppupuolella ja vasta näiden tulosten perusteella havahdutaan tietoturvapuutteisiin. Pahimmillaan tietoturvaa ei rakenneta järjestelmään lainkaan, eikä edes loppuvaiheen tietoturvavarmennuksia tehdä.
Yksi yleisimmistä selityksistä on ketterä kehittäminen – sen varjolla saatetaan ajatella, ettei projektin alkuvaiheessa vielä tiedetä tarkasti, mitä ollaan rakentamassa. Tämä voi johtaa harhakäsitykseen, että myös tietoturvan suunnittelua voidaan lykätä. Todellisuudessa, jos ei tiedetä, miten sovellus tai palvelu turvataan, ollaan jo lähtökohtaisesti heikolla pohjalla.
Tietoturvan tulisi olla kiinteä osa kehitysprosessia alusta alkaen, ei erillinen vaihe lopussa. Suunnittelemalla tietoturva jo alkuvaiheessa voidaan välttää kalliita korjauksia, parantaa palvelun luotettavuutta ja varmistaa, että se täyttää vaadittavat standardit.
Jälkikäteen lisätty tietoturva – kallista ja kompromisseja täynnä
Useat tutkimukset osoittavat, että tietoturvavaatimusten huomioiminen vasta kehityksen loppuvaiheessa voi vaikuttaa merkittävästi järjestelmän toiminnallisuuksiin ja käytettävyyteen. Kun tietoturvaa joudutaan lisäämään jälkikäteen, se voi rajoittaa käytettävyyttä tai pakottaa muuttamaan olemassa olevia rakenteita tavalla, joka ei palvele alkuperäistä tarkoitusta (1)(2).
Lisäksi jälkikäteen toteutetut tietoturvaparannukset ovat lähes poikkeuksetta kalliimpia kuin ne, jotka olisi voitu suunnitella mukaan jo varhaisessa vaiheessa. Koska projektit etenevät tiukkojen aikataulu- ja budjettiraamien sisällä, tietoturvaparannukset jäävät helposti puolinaisiksi. Usein niitä ei toteuteta niin huolellisesti kuin olisi tarpeen, vaan ne tehdään kiireellä, jotta järjestelmä saadaan mahdollisimman nopeasti tuotantoon (1).
Ulkopuolisen silmin tämä voi näyttää huonolta käytännöltä – ja sitä se myös on. Tietoturva ei ole irrallinen lisäosa, joka voidaan liimata palvelun päälle myöhemmin, vaan sen tulisi olla osa järjestelmän perustuksia. Kun tietoturva rakennetaan järjestelmään jo alusta lähtien, saavutetaan parempi lopputulos niin toiminnallisuuden, kustannustehokkuuden kuin käyttäjäkokemuksenkin kannalta.
Tietoturva osana kehityskulttuuria
Jotta tietoturva saadaan osaksi kehitysprosessia, se vaatii kulttuurinmuutosta. Tietoturva ei voi olla vain tietoturvahenkilöiden vastuulla, vaan sen täytyy olla koko kehitystiimin yhteinen prioriteetti. Turvallinen koodauskäytäntö, jatkuva riskien arviointi ja systemaattinen testaus ovat kaikki keinoja, joilla tietoturva voidaan sisällyttää kehitysprosessiin ilman, että siitä muodostuu ylimääräinen taakka.
Kun tietoturva on mukana alusta asti, sen toteuttaminen on sujuvampaa, edullisempaa ja ennen kaikkea lopputulos on huomattavasti laadukkaampi ja turvallisempi.
Mitä tietoturvavaatimukset ovat?
Tietoturvavaatimukset mielletään usein pelkästään kriteeristöjen, kuten NIST CSF tai PiTuKri, täyttämiseksi. Todellisuudessa ne tulisi kuitenkin nähdä ohjelmistokohtaisina, kyseisen järjestelmän tai palvelun tarpeista johdettuina vaatimuksina.
Hyvin määritellyn tietoturvavaatimuksen keskeiset ominaisuudet (4):
1. Rajoittava luonne – Estää tietoturvariskien toteutumisen asettamalla rajoituksia järjestelmän toiminnallisuuksille.
- Esimerkki: ”Järjestelmän on varmistettava, että käyttäjän tunnistautuminen tapahtuu ennen kuin käyttöoikeus myönnetään.”
2. Organisaation turvallisuustavoitteista johdettu – Perustuu organisaation tietoturvaperiaatteisiin ja hallintajärjestelmään.
3. Kolmijakoinen näkökulma:
- Tekninen (salaus, pääsynhallinta, varmuuskopiointi)
- Fyysinen (laitteiston ja infrastruktuurin suojaaminen)
- Prosessuaalinen (käyttöoikeuksien hallinta, tietoturvakoulutus)
4. Kontekstiin sidottu – Perustuu järjestelmään kohdistuviin uhkiin ja niihin tehtyihin uhka-analyyseihin.
Miten tietoturvavaatimukset voidaan toteuttaa?
Yksi tapa on käyttää SQUARE-menetelmää (5), jossa käydään läpi yhdeksän askelta vaatimusten määrittämiseksi. Alla ovat SQUARE:n yksinkertaistetut askeleet yksinkertaistettuna:
1. Määrittele keskeiset termit
Ensin sidosryhmien tulee sopia yhteisistä käsitteistä, kuten ”uhka”, ”haavoittuvuus” ja ”tietoturvavaatimukset”. Yhtenevä käsitteistö helpottaa viestintää myöhemmissä vaiheissa.
2. Määrittele tietoturvan tavoitteet
Tässä vaiheessa sidosryhmät tunnistavat ja sopivat projektin liiketoiminnalliset ja tietoturvallisuuteen liittyvät tavoitteet. Näitä voivat olla vaikkapa tietojen luottamuksellisuus ja järjestelmän saatavuus.
3. Luo tukimateriaaleja
Tuotetaan tarpeellisia avustavia materiaaleja, kuten dokumentoidut uhkamallit ja hyökkäyspuut, jotka auttavat tunnistamaan mahdollisia tietoturvauhkia ja -vaatimuksia.
4. Suorita riskianalyysi
Riskianalyysissä arvioidaan mahdollisia uhkia ja niiden vaikutuksia järjestelmään. Riskit luokitellaan niiden todennäköisyyden ja vakavuuden perusteella.
5. Valitse vaatimusmäärittelytekniikat
Vaatimusmäärittelyn toteutukseen voidaan valita eri tekniikoita, kuten haastattelut, kyselyt, mallipohjainen analyysi ja asiakirjakatselmukset.
6. Määrittele tietoturvavaatimukset
Käytettävän vaatimusmäärittelytekniikan avulla kerätään ja dokumentoidaan alustavat tietoturvavaatimukset.
7. Luokittele vaatimukset
Vaatimukset luokitellaan sen perusteella, ovatko ne järjestelmätason, ohjelmistotason vai arkkitehtuurisia rajoituksia. Tämä auttaa niiden hallinnassa ja toteutuksen suunnittelussa sekä arkkitehtuurissa.
8. Priorisoi vaatimukset
Kaikkia vaatimuksia ei välttämättä voida toteuttaa, joten ne priorisoidaan riskien, liiketoiminnallisten tarpeiden ja toteutettavuuden perusteella.
9. Tarkasta vaatimukset
Viimeisenä vaiheena suoritetaan tarkastus, jossa arvioidaan vaatimusten täsmällisyys, kattavuus ja toteutettavuus. Tämä voidaan tehdä vertaisarvioinnilla tai systemaattisella katselmoinnilla.
Muitakin tapoja on: esimerkiksi STORE (Security Threat Oriented Requirements Engineering) -menetelmä on tietoturvavaatimusten määrittelymenetelmä, joka keskittyy järjestelmällisesti tietoturvauhkien tunnistamiseen ja niiden pohjalta vaatimusten määrittelyyn. Se auttaa varmistamaan, että tietoturva otetaan huomioon ohjelmistokehityksen alkuvaiheista lähtien (3).
Yhteenveto
Tietoturvavaatimukset eivät ole vain tarkistuslistoja tai pakollisia sääntöjä, vaan ne muodostavat perustan turvalliselle ohjelmistokehitykselle. Niiden varhainen huomioiminen säästää aikaa, rahaa ja varmistaa, että järjestelmä on turvallinen ja toimiva heti käyttöönotosta lähtien. Tietoturva ei ole lisäosa, vaan olennainen osa modernia ohjelmistokehitystä.
Lähteet:
(1) Khan, R. A., Khan, S. U., Khan, H. U., & Ilyas, M. (2022). Systematic literature review on security risks and its practices in secure software development. ieee Access, 10, 5456-5481.
(2) Rindell, K., Ruohonen, J., Holvitie, J., Hyrynsalmi, S., & Leppänen, V. (2021). Security in agile software development: A practitioner survey. Information and Software Technology, 131, 106488.
(3) Ansari, M. T. J., Pandey, D., & Alenezi, M. (2022). STORE: Security threat oriented requirements engineering methodology. Journal of King Saud University-Computer and Information Sciences, 34(2), 191-203.
(4) Haley, C. B., Moffett, J. D., Laney, R., & Nuseibeh, B. (2006, May). A framework for security requirements engineering. In Proceedings of the 2006 international workshop on Software engineering for secure systems (pp. 35-42).
(5) Mead, N. R., & Stehney, T. (2005). Security quality requirements engineering (SQUARE) methodology. ACM SIGSOFT Software Engineering Notes, 30(4), 1-7.