1.
Järjestelmässä käsiteltävät ei-julkinen tieto ja henkilötiedot on tunnistettu ja niiden käsittelyperiaatteet on määritelty
Tunnistetaan, mitä ei-julkista tietoa ja henkilötietoja järjestelmässä käsitellään, ja niille määritellään käsittelyyn liittyvät tietoturva- ja tietosuojavaatimukset. Erityisiä suojatoimia vaativat henkilötiedot, kuten erityisiin henkilötietoryhmiin kuuluvat tiedot, tunnistetaan. Näiden vaatimusten tulisi päätyä tuotteen tehtävälistalle, jotta vaatimukset voidaan ottaa huomioon uhkamallinnuksessa.
2.
Palvelun keskeiset käyttötilanteet on tunnistettu
Tunnistetaan palvelun käyttötapaukset (use case) ja käyttökokemus (user experience). Erityisen kiinnostavia ovat poikkihallinnolliset käyttötilanteet, joissa tietoa siirretään organisaatioiden välillä, sekä ylläpito- ja hallintakäyttötilanteet. Tiedot välitetään ohjelmistokehittäjille käyttötapauskuvauksissa, jotta vaatimukset voidaan ottaa huomioon uhkamallinnuksessa.
4.
Arkkitehtuuri on modulaarinen
Arkkitehtuuri rakentuu määritellyin rajapinnoin eriytetyistä komponenteista tai palveluista, jotka toteuttavat itsenäisesti tietyn toiminnallisuuden tai tarjoavat pääsyn palvelun tarvitsemaan tietoon.
Esimerkki: Mikropalvelut (microservices) ovat yksi tapa tuottaa tämänkaltainen arkkitehtuuri. Niitä kutsutaan tarkasti määritellyn rajapinnan kautta, eikä esimerkiksi niiden hallitsemiin tietoihin ole pääsyä kiertoteitse.
5.
Arkkitehtuuri eriyttää palveluntarjoajista riippuvat osat selkeillä rajapinnoilla
Jatkuvuussuunnittelun helpottamiseksi erityisesti pilvipalveluiden tietystä tarjoajasta riippuva toiminnallisuus on eriytettävä selkeillä rajapinnoilla. Rajapintojen tietoturvallisuus on huomioitava suunnittelussa ja toteutuksessa. Apuna voi käyttää esimerkiksi OWASP API Security Top 10 -listaa (https://owasp.org/www-project-api-security/).
Esimerkki: Palvelussa päätetään käyttää pilvialustan omaa serverless-toteutusta tai vaikkapa valmista pilvitietokantapalvelua. Arkkitehtuuri on suunniteltava niin, että näiden korvaaminen eri toteutuksella ei pakota muuttamaan koko ympäröivää arkkitehtuuria.
6.
Tietojen käsittely ja rajapintojen syntaktinen monimutkaisuus on minimoitava
Palvelun osan tulee toteuttaa vain halutun toiminnallisuuden kannalta välttämättömät toiminnot. Tämä pätee sekä tiedon käsittelyyn että rajapintojen toiminnallisuuteen ja ilmaisuvoimaan.
Henkilötietoja saa käsitellä vain siinä laajuudessa, kuin palvelun tekniseen toteuttamiseen vaaditaan.
Esimerkki: REST-rajapinnat määritellään OpenAPI-dokumentteina ja niiden kautta vastaanotetun tiedon syntaktinen oikeellisuus varmistetaan tiukasti. Esimerkiksi DDD (Domain-Driven Design) saattaa auttaa tässä ajattelussa, katso Johnsson et al., Secure by Design (Manning Publications, 2019) (https://www.manning.com/books/secure-by-design).
7.
Arkkitehtuurissa on selvää, mikä osa on vastuussa tietojen pysyvästä tallennuksesta
Se palvelun osa, joka tallentaa tietoja pysyvästi (persistence), on myös vastuussa tietojensa pääsynhallinnasta ja niiden poistamisesta elinkaaren aikana. Näiden osien määrä kannattaa minimoida.
Esimerkki: Arkkitehtuurisuunnittelu ja teknologiavalinnat mahdollistavat sen, että palveluiden osia voidaan ajaa read-only -tiedostojärjestelmistä niin laajalti kuin mahdollista. Tällöin tietoja käsitellään vain muistinvaraisesti.
8.
Arkkitehtuuriin on luotava selvät luottamusalueet, jotka on dokumentoitu tietoturva-arkkitehtuurissa
Jokaisen komponentin osalta on määriteltävä, mihin muihin komponentteihin se luottaa, ja tämä määrittelee luottamusalueet. Eri luottamusalueiden välille on suunniteltava verkko- ja ajoympäristöjen riittävä erottaminen ja tietovirtojen sisällön oikeellisuuden tarkistus ja todennus.
Komponentit, joilla on rajapinta loppukäyttäjään tai kolmannen osapuolen palveluun eriytetään omaan luottamusalueeseensa.
Jos luottamusalueilla on keskinäinen hierarkia (esimerkiksi suojaustaso), suojaustasojen väliset eheys- ja luottamuksellisuusvaatimukset on määriteltävä.
Esimerkki: Kubernetes-klusterissa ajettavat mikropalvelut luokitellaan eri nimiavaruuksiin esimerkiksi sen mukaan, palvelevatko ne suoraan Internetissä olevaa asiakasta vai muita taustapalveluita ja onko mikropalveluilla hallussaan pääsyavaimia taustapalveluihin (esim. tietokantoihin). Niiden välinen kommunikointi rajataan esimerkiksi NetworkPolicy -määrittelyllä siten, että vain toiminnan kannalta oleelliset yhteydet ovat mahdollisia.
9.
Tietovarannot on eriytettävä luottamusalueiden välillä
Kaikki tietovirrat luottamusalueiden välillä on toteutettava rajapinnoilla. Suorat tietovarantopääsyt luottamusalueelta toisille (esimerkiksi vapaamuotoiset tietokantakyselyt tai tiedostojärjestelmän luku) on arkkitehtuurin tasolla estettävä.
Luottamusalueella, jolla on suora yhteys loppukäyttäjään tai kolmannen osapuolen palveluun ei saa sijaita tietovarantoja, vaan tiedot on noudettava tarvittaessa rajapinnan kautta.
Esimerkki: Useat erilaiset mikropalvelut tarvitsevat tietoa samasta tietokannasta. Sen sijaan, että kaikille eri mikropalveluille annetaan suora tietokantapääsy, ne kutsuvat erillistä rajapintaa, joka tarjoaa niille tarpeellisen pääsyn (mutta ei mitään muuta). Itse tietokantaan annetaan pääsy vain tämän rajapinnan toteutukselle.
10.
Tietovirtojen tietoturvavastuut on selkeästi määritelty
Vastuu tietovirtojen sisällön oikeellisuuden tarkistamisesta ja niihin luottamisesta on aina vastaanottajalla. Vastuu siitä, että tietoja ei luovuteta toiselle komponentille lain vastaisesti, on aina lähettäjällä.
Esimerkki: Jos komponentti hakee tietoa rajapinnasta esitettäväksi esimerkiksi käyttöliittymässä, on rajapinnan kutsujan vastuulla varmistaa, että tiedon sisällyttäminen esimerkiksi web-sivun kontekstissa on turvallista. Tietokannalla tai sinne tietoa tallentavilla tahoilla ei voi olla tietoa kaikista niistä konteksteista, joissa tietoa joskus tullaan esittämään ja mitä erityistarpeita esimerkiksi syntaksille tuolloin on.
Esimerkki: Jos henkilötietoja lähetetään kolmannen osapuolen rajapintaan, lähettäjän on poistettava siitä ne tiedot, joita vastaanottajalla ei ole tarvetta tai oikeutta käsitellä. Jos vastuu tästä siirrettäisiin vastaanottajalle, on se lakiteknisesti jo liian myöhäistä.
11.
Järjestelmän saatavuustavoitteiden on oltava selkeitä vaatimuksia
Saatavuustavoitteet on määriteltävä ja niille on löydettävä tekninen ratkaisu esimerkiksi hajauttamalla ja automaattisella skaalautumisella. Erityishuomiota on kiinnitettävä vanhojen järjestelmien integraatiopisteisiin ja komponentteihin, joita voi käsitteellisesti olla vain yksi kappale.
12.
Valmiita toteutuksia ja ohjelmistoriippuvuuksia käytettäessä tietoturvavastuu on määriteltävä
Jos käytetään jonkin muun tahon kirjoittamia ohjelmistoja, tietoturvavastuu kuuluu sille komponentille, joka valmista toteutusta käyttää. Vastuun voi siirtää sopimuksellisesti, mikäli käyttö perustuu sopimukseen. Tyypillisessä avoimen lähdekoodin tapauksessa käyttö perustuu vain rajoitettuun lisenssiin, jolloin tietoturvavastuuta ei voida siirtää.
Esimerkki: Halutaan ottaa käyttöön kirjasto, joka säästää kehitysaikaa arviolta henkilötyökuukauden. Arvion mukaan kirjaston tietoturvatestaus ja haavoittuvuusseuranta kuitenkin aiheuttaisi elinkaaren aikana tätä enemmän lisätyötä, joten kirjastoa ei oteta vain tämän projektin vuoksi käyttöön.
13.
Kolmannen osapuolen komponenttien laatu on selvitettävä ja seurattava
Ohjelmistokehityksessä käytettävien, ulkopuolelta hankittavien (esim. avoin lähdekoodi tai valmis ostettu komponentti) haavoittuvuustilannetta on seurattava jatkuvasti. Tämä tulisi tehdä automatisoidulla järjestelyllä. Käyttöön otettaessa ulkopuolisen komponentin tausta ja ylläpitotilanne on selvitettävä ja siihen liittyvät riskit on hallittava.
Esimerkki: Halutaan ottaa käyttöön kirjasto, mutta sen taustatarkistuksessa ilmenee, että sillä on vain yksi aktiivinen kehittäjä ja tietoturvaongelmia on korjattu ilman, että niille on haettu CVE-numeroa tai mainittu versiodokumentaatiossa. Tutkitaan, olisiko muita vaihtoehtoja olemassa.