Tämä kurssi on jo päättynyt.

Periaatteet

Erilaisia turvallisuuteen liittyviä periaatteita ja hyviä käytäntöjä on useita. Ne läpäisevät useita tietoalueita ja yhdessä ne auttavat muodostamaan kokonaisvaltaisen lähestymistavan turvallisten järjestelmien suunnitteluun, kehittämiseen ja käyttöönottoon.

Saltzer ja Schroeder -periaatteet

Vaikka tietojenkäsittely näyttää nykyään varsin toisenlaiselta kuin vuonna 1975, monet yleiset periaatteet ovat edelleen voimassa. Seuraavassa on Saltzerin ja Schroederin julkaisemia suunnitteluperiaatteita tuolta vuodelta. Sujuvuuden vuoksi tässä käytetään termiä turvatoimi tarkemman termin turvavalvontatoimenpide (security control) sijasta.

Mekanismin taloudellisuus (economy of mechanism): Turvatoimen tulisi olla niin yksinkertainen kuin mahdollista. Yksinkertaisuus auttaa ymmärtämään toimiiko mekanismi niin kuin on ajateltu. Lisäksi toteutus on yksinkertainen, jolloin luotettavuus ja toimiminen on helpompaa todentaa.

Sisäänrakennettu vikaturvallisuus (fail-safe defaults): Turvatoimen tulisi määritellä ja mahdollistaa toimet, jotka ovat yhteensopivat turvapolitiikan kanssa, ja hylätä kaikki muut tavat toimia. Erityisesti tulisi varoa mekanismeja, jotka yrittävät poistaa haitallisen toiminnan. Tämä on virheille altis tapa, koska haitallinen toiminta kehittää aina uusia muotoja. Keinojen ja mekanismien tulisi perustua oikean ja hyvän käytöksen tunnistamiseen. Tässä voi huomata, että useat yleiset turvatoimet rikkovat tätä periaatetta, esim. anti-virus ohjelmat ja tunkeutumisen havainnointi.

Täydellinen tarkastus (complete mediation): Kaikista järjestelmän objekteista ja operaatioista tulisi tarkastaa, että ne ovat turvapolitiikkojen mukaisia. Tämä tarkoittaa, että esim. tarkastetaan, onko toimijalla oikeudet suorittaa aikomansa toiminto.

Avoin rakenne (open design): Turvatoimen turvallisuuden ei tulisi perustua siihen, että sen toimintaperiaate pysyy salaisena. Usein turvallisuus edellyttää, että turvatoimia voidaan tutkia, niiden oikeellisuus todeta ja virheet löytää, ilman että samalla mitätöidään turvatoimien turvallisuus. Vastakkainen näkemys, salassapitoon perustuva turvallisuus (security by obscurity), on haavoittuvampi, koska se rajoittaa turvatoimien tarkastamista, eikä poista sisäpiiristä tulevia uhkia.

Oikeuksien erottaminen (separation of privilege): Turvatoimet, joissa tarvitaan useamman toimijan valtuutus ennen toiminnan hyväksymistä, ovat luotettavampia kuin toimenpiteet, joissa yhden tahon antama valtuutus riittää. Tässä on kuitenkin huomioitava, että useiden toimijoiden hyväksynnän vaatiminen saattaa haitata saavutettavuutta.

Vähimpien oikeuksien periaate (least privilege): Toimijoiden suorittamat operaatiot tulisi hoitaa mahdollisimman vähin oikeuksin, esim. jos täytyy vain lukea jokin tieto, ei tarvitse antaa oikeuksia myös tiedon kirjoittamiseen ja poistamiseen. Vähimpien oikeuksien periaate varmistaa, että esim. virheelliset ohjelmat tekevät vahinkoa mahdollisimman vähän.

Vähimpien yhteisten mekanismien periaate (least common mechanism): On suositeltavaa minimoida resurssien ja mekanismien jakaminen eri osapuolten välillä. Periaate on tarpeen esim. monen käyttäjän järjestelmien turvallisuudelle, joissa esim. jaettu muisti, levytila tai prosessori voivat mahdollistaa luottamuksellisen tiedon vuotamisen käyttäjältä toiselle.

Psykologinen hyväksyttävyys (psychological acceptability): Turvatoimien tulisi olla luonnostaan käytettäviä, jotta käyttäjät automaattisesti toimisivat niiden mukaan. Kun käyttäjän mielikuvamalli turvallisuustavoitteista vastaa turvallisuuteen käytettävää mekanismia tai turvatoimea, virheiden todennäköisyys vähenee.

NIST-periaatteet ja yleiskaavio

National Institute of Standards and Technology (NIST) määrittelee turvaperiaatteita järjestelmien suunnitteluun. Ne on järjestetty laajoihin ryhmiin, jotka ovat Turvallisuusarkkitehtuuri ja -suunnittelu (security architecture and design) sisältäen organisaatiot, rakenteet ja käyttöliittymät; Turvallisuuskyvykkyydet ja käyttäytyminen (security capability and intrinsic behaviours) eli mitä turvallisuus oikeastaan on; ja Elinkaariturvallisuus (life cycle security) liittyen prosesseihin ja hallintaan.

Osa NIST-periaatteista pohjaa suoraan Saltzer ja Schroeder -periaatteisiin. Uudemmat periaatteet liittyvät nykyisten järjestelmien monimutkaisuuteen ja painottavat esim. moduulirakennetta, kerroksellisuutta, osastoittain järjestettyjä riippuvuuksia ja turvallisuuden evolvoimista muun systeemin päivitysten mukana. Periaatteissa huomioidaan myös, että turvallisessakaan järjestelmässä kaikki osat eivät ole yhtä turvallisia. Tällöin turvattomammat osat hyötyvät hierarkkisesta luottamusrakenteesta (hierarchical trust), jossa joidenkin osien turvallisuushäiriöt eivät kaada koko järjestelmän turvallisuutta. Inverse modification threshold -periaatteen mukaan turvallisuudelle kriittisimpien osien tulisi olla kaikkein suojatuimpia valtuuttamattomia muutoksia ja peukalointia vastaan.

NIST-periaatteet huomioivat myös, että modernit järjestelmät ovat kytkettyjä toisiinsa. Verkoissa tulisi käyttää luotettuja kommunikointikanavia (trusted communication channels). Niiden pitäisi toteuttaa secure distributed composition -periaate, joka tarkoittaa, että kun yhdistetään kaksi saman politiikan toteuttavaa järjestelmää, niiden tulisi yhdistettynäkin vähintään toteuttaa sama politiikka. Self-reliant trustworthiness -periaate puolestaan toteaa, että turvallisen järjestelmän tulisi säilyttää turvallisuutensa vaikka yhteys muihin järjestelmän osiin katkeaisi.

NIST-periaatteet määrittävät minkälaiset mekanismit ovat hyväksyttäviä oikeissa, käytössä olevissa järjestelmissä (real world systems). Erityisesti turvatoimien tulisi olla kustannustehokkaita (economic security), olla suorituskykyisiä (performance security), olla käytettäviä (human factored security) ja olla käyttäjien hyväksyttäviä (acceptable security). Tällä ajetaan takaa sitä, että turvallisuus tukee järjestelmien varsinaista toimintaa, eikä ole yksinään tavoitteena.

Periaatteiden lisäksi NIST hahmottelee kolme turvallisuusarkkitehtuuristrategiaa. Viitemonitori (reference monitor) on abstrakti turvatoimi, joka tuo voimaan systeemin turvaominaisuudet. Kerroksellinen turvallisuus (defence in depth) kuvaa turvallisuusarkkitehtuuria, jossa turvallisuus rakentuu useista päällekkäisistä turvatoimista. Eristys (isolation) on strategia, jossa eri komponentit ovat fyysisesti tai loogisesti erotettu häiriöiden tai tietovuotojen minimoimiseksi.

Sekä NIST että Saltzer ja Schroeder korostavat, että arkkitehtuurien ja turvatoimien periaatteet ovat vain ohjeellisia, ja niitä sovellettaessa tarvitaan myös osaamista ongelmista, joihin niitä sovelletaan. Poikkeaminen periaatteista ei automaattisesti johda ongelmiin, mutta tällaiset poikkeamat on tunnistettava sen varmistamiseksi, että mahdollisia ongelmia voidaan lieventää asianmukaisesti.

Edellä on käsitelty kahta turvaperiaatteiden kokoelmaa. NIST:n kokoelma on laadittu useiden muiden periaateluetteloiden pohjalta, ja se ottaa huomioon ilmiöitä, joita Saltzer ja Schroeder eivät olleet vielä nähneet 1970-luvulla. Seuraavassa periaatteita on jäsennetty vielä eri tavalla käsitekartan muotoon. Lähteinä on käytetty paitsi NIST-kokoelmaa, myös dokumenttia Cybersecurity Curricula 2017 ja kahta kirjaa: Rick E. Smith: Elementary information security (2012) ja Paul van Oorschot: Computer security and the internet (2020). Näistä kaikista on päätelty 10 korkeimman tason periaatetta, jotka on merkitty kartassa oranssilla värillä. Muita periaatteita on 30. Kokonaisuus on jaettu seitsemään luokkaan, joiden tarkoituksena on tehdä asioista helpompia ymmärtää ja muistaa. Suurimmassakin luokassa on vain 7 periaatetta.


Käsitekartta suunnitteluperiaatteista

Useita korkeimman tason periaatteita on koottu luokkaan Sovella mielessäsi. Nämä ajattelumallit täytyy oppia ja omaksua osaksi luontaista käyttäytymistä, mutta on silti hyvä pystyä tunnistamaan ne nimillä. Yksi niistä koostuu kolmesta näkökulmasta, jotka edellyttävät keskinäistä tasapainoa: riskit, kustannukset ja politiikka. Tämän yhdistäminen hyökkäävään ajatteluun johtaa periaatteeseen, että suojausten pitää olla vahvempia kuin hyökkääjä. Tämä on ilmeistä, mutta se on muistettava erityisesti valittaessa kryptografiaa.

Organisoi työsi sisältää kaksi korkean tason periaatetta, jotka käsittelevät suunniteltavan järjestelmän elinkaarta. Tietyssä mielessä niille voitaisiin käyttää nimiä “start” ja “restart”. Myös riski-kustannus-politiikka -periaate on nähtävissä hallinnollisesta näkökulmasta ja siksi siihen on lisätty katkoviiva.

Luokkana Sovella mielessäsi on selvästi korkeimmalla tasolla ja sitä lähellä on organisoinnin luokka yhdessä Minimoinnin kanssa. Jälkimmäisessä periaatteet nimeävät asioita, joita suunnittelussa pitäisi minimoida. Minimointi pitää kuitenkin ymmärtää sidottuna rajoitteisiin, joita kaikki muut periaatteet asettavat. Tähän luokkaan kuuluu yksi korkeimman tason periaate: Minimoi hyökkäyspinta. Kaikki muut minimoinnit voidaan nähdä tämän toteutumisena. Jopa käyttäjälle koituvien yllätysten minimointi vähentää tilanteita, joissa hyökkäykset ovat mahdollisia. Minimoi yhteisten välineiden määrä vastaa Saltzerilta ja Schroederiltä lähtöisin olevaa periaatetta “least common mechanism”. Sen motiivina on, että tällainen minimointi vähentää myös mahdollisuuksia tahattomaan viestintään tai häiriöihin prosessien tai käyttäjien välillä. Sanaa väline käytetään tässä, koska se on yleisempi kuin mekanismi ja voi helpommin tuoda mieleen koodin lisäksi myös muuttujat ja tiedostot.

Neljäs luokka koskee järjestelmän arkkitehtuuria: Käytä rakenteita. Siitä löytyy kaksi korkean tason periaatetta. Ne voitaisiin karkeasti merkitä syvyydeksi ja leveydeksi. Kahdessa periaatteessa mainitaan kerrokset, mutta ne ovat erillisiä rakenteellisia näkökohtia. Sama koskee moduuleja ja eristystä.

Ainoa jäljellä oleva korkean tason periaate kuuluu luokkaan Salli vähemmän. Tämä luokka edustaa toiminnan rajoituksia ja siinä on kyse enimmäkseen hyvin erilaisista asioista kuin minimointiluokassa. Vähemmän salliminen koskee pääasiassa suunnitteilla olevan järjestelmän resurssien käyttöä, ja ne johtuvat korkean tason periaatteesta Tarkista ennen luottamista. Tästä periaatteesta on useita versioita, jotka täsmentävät alunperin Saltzerilta ja Schroederin peräisin olevaa periaatetta “complete mediation”. Myös muilla tämän luokan periaatteilla on useita ilmaisuja. Kahdessa esiintyy termi oikeudet ja näissä käytetään englanniksi myös termiä privileges. Vaikka nimi on samankaltainen, merkitys eroaa. Kitsaan tai vastahakoisen allokoinnin periaate on hyödyllinen palvelunestotilanteiden välttämisessä. Sitä voisi pitää myös minimointitavoitteena, jolloin se pitäisi muotoilla esimerkiksi “Minimoi resurssien allokointi-into”.

Kartassa on kaksi luokkaa ilman oransseja laatikoita: Tee enemmän ja Sisällytä erityisominaisuuksia. Molemmat luokat suosittelevat lisäämään joitain ominaisuuksia, jotka palvelevat turvallisuutta ja ovat melko kaukana järjestelmän tavallisesta toiminnasta. Kumpikin luokka perustuu vain yhteen lähteeseen: Sisällytä erityisominaisuuksia tulee Cybersecurity Curricula 2017:stä, Tee enemmän van Oorschotilta. Erityisominaisuudet - paitsi tunnistaminen - voivat monimutkaistaa toimintaa melko paljon, mutta kaikki ovat motivoituja ja siksi hyvä muistaa. Kaksi “Enemmän tehtävää” asiaa ovat täysin ylimääräisiä tavallisten toimintojen ulkopuolella mutta välttämättömiä tulevaisuuden kannalta (“siivoaminen” ja “lokitus”). Jäljelle jäävä ristiintarkastus on ylimääräistä puuhaa sisäpuolella eli osana normaalia toimintaa. Siinä yhdistyvät van Oorschotin kaksi melko yksityiskohtaista periaatetta “Riippumaton vahvistus” ja “Pyyntö-vastaus -rakenteen eheys”. Ensimmäinen niistä täydentää Tarkista ennen luottamista -periaatetta ulottamalla sen vähemmän luotettuihin tilanteisiin, joissa on syytä epäilyihin, ja jälkimmäinen muistuttaa, että yksi tällainen tapaus on, kun sovellus saa vastauksen pyyntöönsä. Ristiintarkastus on tehtävä sen varmistamiseksi, että vastaus vastaa pyyntöä. Nämä asiat ovat tuttuja niille, jotka jo suunnittelevat protokollia, mutta huomautus muille voi olla hyödyllinen.

Lopuksi on syytä muistuttaa, että tässä on käsitelty turvallisten järjestelmien luomista eikä niiden turvallisia käyttämistä. Asiat ovat tässä myös abstraktimpia kuin turvamekanismit tai hyvät turvallisuustavat, sellaiset kuin:

  • Päivitykset
  • Varmuuskopiot
  • Virustorjunta
  • Palomuurit
  • Monitekijäautentikointi
  • Hyvät salasanat
  • “Selaushygienia”
  • Tietoisuuskoulutus
  • Turvallinen alustus
  • Salaus

tai edes politiikan luominen ja sen noudattaminen. Monet näistä ovat kuitenkin melko suoria seurauksia suunnitteluperiaatteista. Ja tietysti järjestelmän suunnittelijan ja toteuttajan tuotantoympäristön ja työtapojen tulee olla turvallisia—juuri tässä mainittujen käytäntöjen avulla.

Valitse yksi tai useampi vaihtoehto.

Mitä hyötyä on suunnitteluperiaatteista?
Monet suunnitteluperiaatteet pyrkivät yksinkertaistamaan järjestelmää eri tavoin. Miksi tämä on tärkeää turvallisuuden kannalta?

Piilevät suunnitteluehdot (syventävä)

Yhä useammat kyberfyysiset järjestelmät on kytketty muihin järjestelmiin ja Internetiin. Tällaiset laajamittaiset yhteydet ovat luonnostaan monimutkaisia ja joidenkin kyberfyysisten järjestelmien turvallisuuskriittisyys merkitsee sitä, että turvallisuusperiaatteiden merkitys kasvaa. Yksi tällainen periaate liittyy piileviin suunnitteluehtoihin (latent design conditions). Kyberturvallisuuden yhteydessä piilevät suunnitteluehdot johtuvat aiemmista järjestelmää (tai järjestelmiä) koskevista päätöksistä. Ne jäävät usein piiloon tai huomioimatta ja tulevat esiin vain, kun tietyt tapahtumat tai asetukset ovat voimassa. Tärkeintä on huomata, että tietoturvaloukkausten seurauksina ei riitä ainoastaan tarkastella tietojen kohtaloa vaan täytyy miettiä myös esim. henkilöturvallisuutta. Lisäksi sisäänrakennettu turvallisuus (security by design) ei aina ole mahdollista ja kun vanhat järjestelmät yhdistetään muihin verkkoympäristöihin, täytyy kiinnittää huomiota piileviin suunnitteluehtoihin ja siihen, miten niiden vaikutuksia voidaan lieventää.

Varotoimiperiaate (syventävä)

Osallistava datatalous johtaa monenlaisiin tuotteisiin ja palveluihin, joihin liittyy myös yhä enemmän huolta yksityisyydestä ja mahdollisesta tietojen väärinkäytöstä. Tällöin tulee ajankohtaiseksi myös varotoimiperiaate (precautionary principle), joka tarkoittaa mahdollisten haitallisten vaikutusten arvioimista ennen kuin teknologia tulee laajamittaiseen käyttöön. Suunnittelijoiden tulee jatkuvasti arvioida valintojensa turvallisuus- ja yksityisyysvaikutuksia esim. mallintamalla, ylläpitämällä ja tarvittaessa poistamalla käytöstä verkkoja ja infrastruktuuria, joiden varassa yhteiskunta on yhä enemmän. Tietojen mahdollista käyttöä alkuperäistä vastaamattomiin tarkoituksiin järjestelmän (pitkän) elinkaaren aikana ja tämän vaikutuksia koko yhteiskuntaan tulisi myös arvioida.

Palautusta lähetetään...