TTKK / Tietoliikenne / J.Koskinen : Tietoturvallisuuden perusteet

7. viikko, ke 13.10.1999

Tällä kerralla tutustutaan ensin tietoturvan arvioinnissa käytetyistä malleista uusimpaan eli Common Criteria-dokumenttiin. Tämä muodostaa samalla jonkinlaisen kertauksen kurssin aiheista. Sitten katsotaan lyhyesti, millaisia tietolähteitä tietoturvan kanssa tekemisissä oleva tarvitsee työssään. Pohditaan yhdessä, mitä kenenkin pitäisi tietää tietoturvasta, ja erityisesti, miten tietoturva-asioita pitäisi tai kannattaisi tuoda esiin tietotekniikan koulutusohjelmassa - millaista olisi tietoturvan didaktiikka. Lopuksi suoritetaan evaluointia eli katsotaan, miten tämä kurssi vastasi tavoitteitaan. Tenttikin tulee siinä vaiheessa esille.

Tietoturvan arviointi

Aiemmin olivat jo esillä tietoturvan mallintamisen yhteydessä kriteerimallit. Ne ovat sellaisia ohjeistoja tai standardeja, joiden mukaan voidaan arvioida tuotteiden tai järjestelmien tietoturvallisuutta ja esittää tulos jotenkin tiiviissä ja tekniikkaa vähemmän tuntevien ymmärtämässä muodossa, joka kuitenkin riittää vakuuttamaan heidät siitä, että jokin tietoturvapolitiikka toteutuu.

Arviointi voi koskea myös yksityiskohtaisempaa luottamusta. PolicyMaker, KeyNote ja myös REFEREE ovat automatisoituja luottamuksenhallinnan työkaluja, joilla voi tutkia, onko jokin toiminta asetetun turvapolitiikan mukaista. Syötteenä on tyypillisesti julkisia avaimia ja niiden varmenteita, ja työkalun tehtävänä on vastata sellaisiin kysymyksiin kuin: "Saako varmenteen V haltija suorittaa toimen T resurssille R?". Tähän aiheeseen ei mennä nyt syvemmälle, vaan katsotaan vain yleisiä arviointiperusteita:

Hieman taustaa Common Criterialle

Common Criteria on erittäin laajan työn tulos. Joitakin kehitysvaiheita:

TCSEC eli oranssi kirja (USA, 1985, alkujuuret jo 60-luvun lopulla) ==>
Saksan "Vihreä kirja", (1988), Ison-Britannian useat julkaisut, Ranskan, Australian ja Kanadan omat luonnokset ==>
eurooppalaisten yhdistelmä ITSEC (1991) ==>
Common Criteria (1996).

TCSEC:n seitsemän luokkaa mainittiin jo aiemmin. Kukin niistä yhdisti joitakin toiminnallisia vaatimuksia tietyn tasoiseen vakuuttavuuteen (siis esim. testauksiin ja verifiointeihin). ITSEC erosi TCSEC:stä oleellisesti siinä, että nämä kaksi näkökulmaa erotettiin toisistaan. Tämä oli perua jo Saksan vihreästä kirjasta, jossa oli 10 toiminnallista luokkaa ja 8 laatuluokkaa (vakuuttavuuden tasoa) eli periaatteessa 80 erilaista luokitusta. ITSEC säilytti vihreän kirjan toiminnalliset luokat, mutta yhdisti niihin brittiläisten kriteerien joustavan metakielen (claims language), jolla valmistaja saattoi esittää väitteitä tuotteen toiminnallisuudesta. ITSECin uudistuksia oli myös mahdollisuus käyttää kaupallisia arvioijia.

Common Criteria

Aiempien standardien ja luonnosten tuloksena syntynyt maailmaanlaajuiseksi tarkoitettu malli tunnetaan CC:nä, vaikka se oikeastaan on "Common Criteria for Information Technology Security Evaluation" (CCITSE) ja sittemmin ISO-standardina IS 15408 vielä oikeammin "Evaluation Criteria for Information Technology Security".

Turvallisuutta koskevat vaatimukset / tavoitteet muodostavat hierarkkisen rakenteen, jonka osasilla on kuitenkin keskinäisiä riippuvuuksia. Päätason muodostavat yksitoista toiminnallista ('functional') ja seitsemän vakuuttavuusluokkaa ('assurance classes'). Luokkajaon alla on kolme tasoa: ryhmä ('family'), komponentti ja alkio.

Toiminnallinen komponentti on eräänlainen peruspalikka: se määrittelee, mitä kohdejärjestelmän täytyy pystyä tekemään, esimerkiksi haaste-vaste-mekanismit kuuluvat toiminnalliseen komponenttiin, joka kuuluu ryhmään "käyttäjän autentikointi", joka puolestaan on luokassa "tunnistus ja autentikointi". Toiminnallisista komponenteista kootaan erilaisiin tarpeisiin paketteja, mutta arviointikriteeri niistä muodostuu vasta kun pakettiin yhdistetään myös vakuuttavuutta:

Vakuuttavuuskomponentteja käytetään ilmaisemaan vaatimuksia ensinnäkin kohdejärjestelmän kehittäjän (siis esim. ohjelmistotalon) toimille ja niiden järjestykselle - koskien erityisesti suunnittelua, implementointia, testausta, operointia ja ylläpitoa. Toiseksi näillä komponenteilla ilmaistaan vastaavantyyppisiä vaatimuksia arvioijalle, ja kolmanneksi vaatimuksia turvallisuutta koskevan todistusaineiston sisällölle ja esitystavalle. Tämä kolmijako tuodaan esille vakuuttavuuskomponenttien alkioiden tasolla.

Vakuuttavuuskomponenteista on koottu valmiiksi seitsemän pakettia. Ne muodostavat hierarkian, jonka tarkoitus (toisesta tasosta alkaen) on tarjota osittaista vastaavuuttaa aiempiin malleihin nähden, erityisesti oranssin kirjan luokkiin (siis C1, C2, B1, B2, B3 ja A1) verrattuna. Nämä paketit esitellään jäljempänä.

Toiminnallisuuden jaottelu on seuraavanlainen. Luokkiin kuuluvat ryhmät on dokumenteissa mainittu niiden lyhenteiden mukaisessa aakkosjärjestyksessä. Tässä järjestystä on muutettu (ehkä) loogisemmaksi. Kunkin ryhmän jäljessä on mainittu siihen kuuluvien komponenttien määrä ja muutamassa tapauksessa komponentit on lueteltu:

turva-auditointi eli tapahtumakirjanpito: auditoitavien tapahtumien valinta (1), tietojen keruu (2), tallennus (4), (automaattinen) analyysi (4), automaattinen reagointi (1), tietojen tarkastelu (ihmisen toimesta) (3).
kryptograafinen tuki: avaintenhallinta (4: avainten generointi, avainten jakelu, pääsyoikeudet avaimiin, avainten hävittäminen), krypto-operaatiot, ts. algoritmien asianmukainen käyttö (1).
tietoliikenne: alkuperän kiistämättömyys (2), vastaanoton kiistämättömyys (2).
käyttäjän tietojen suojaaminen: pääsynvalvonnan politiikka (2) ja toimet (1), datan autentikointi (2), talletetun tiedon eheys (2), takaisinkierto (rollback) eli "undo"-mahdollisuus (2), hävitetyn eli jäännöstiedon (residual information) "suojaus" eli varmistuminen sen häviämisestä (2), tiedon virtauksen politiikka (2) ja toimet (6, tässä on kyse samasta kuin aikanaan mm. Bell-LaPadula-mallissa), kohdejärjestelmän sisäinen tiedonsiirto (4), kohdejärjestelmän erillisten osien välisessä siirrossa suojattava luottamuksellisuus (1) ja eheys (3), vienti kohdejärjestelmän turvan ulottumattomiin (2), tuonti sieltä (2),
tunnistus ja autentikointi: käyttäjän tunnistaminen (2) ja autentikointi (7: ennen mitään muita toimia, mahdollisesti vasta joidenkin toimien jälkeen, väärennetyn/kopioidun autentikointidatan havaitseminen, kertakäyttöinen autentikointimekanismi, usean mekanismin salliminen tai vaatiminen, uudelleenautentikointi määrättyjen tapahtumien jälkeen, käyttäjälle annettavan tiedon rajoittaminen), autentikoinnin epäonnistumis(t)en seuraukset (1), käyttäjän turva-attribuuttien määrittely (1), käyttäjän ja käyttäjän prossesin turva-attribuuttien välinen kytkentä (1), salaisuuksien (esim. salasanojen) spesifiointi (2: laadun arviointi jollain metriikalla, hyvien salaisuuksien generointi).
turvahallinto: turva-attribuutit (3), niiden peruuttaminen (1) ja niiden voimassaolon päättyminen (1), turvamekanismit (1), niihin liittyvä tiedot, esim. kirjanpito (3), tietoturvaan liittyvien (erilaisia oikeuksia antavien) roolien määrittelyt (3).
yksityisyys: nimettömyys (anonymiteetti, 2), peitenimisyys (pseudonymity, 3), kytkemättämyys (unlinkability, 1), resurssin tai palvelun käytön havaitsemattomuus (unobservability, 4).
luotettujen toimintojen suojaaminen: taustalla olevan abstraktion testaus (1), kaatuessaan turvallinen (1), luotettava toipuminen (4), fyysinen suoja (3), toistojen havaitseminen (1), viittausten välitys (1), vyöhykkeiden erottelu (3), tilojen synkronointiprotokolla (2), aikaleimat (1), sisäinen tiedon siirto (3), tiedon yhdenmukaisuus kohdejärjestelmän erillisten osien välisessä siirrossa (1), ulosviedyn tiedon luottamuksellisuus (1), eheys (2) ja saatavuus (1), toisintojen yhdenmukaisuus (1), itsetesti (1). [Tässä ryhmässä "tieto" tarkoittaa turvatoimintoihin liittyvää, ei käyttäjän tietoa.]
resurssien hyödyntäminen: vikasietoisuus (2), prioriteettien käyttö (2), palvelun eston torjuminen resurssien jaolla (2).
käyttäjän istuntojen muodostaminen: istunnon muodostamisen estäminen (1), käyttäjälle näytettävät tiedotteet ja varoitukset (1), tiedot aiemmista istunnoista (1) käyttäjän valittavissa olevien turva-attribuuttien rajoittaminen (1), saman käyttäjän samanaikaisten istuntojen määrän rajoittaminen (2), istunnon lukitseminen (jomman kumman toimesta) tai päättäminen järjestelmän toimesta (3).
luotettu polku tai kanava: käyttäjän ja järjestelmän välillä (1) järjestelmän erillisten osien välillä (1).

Sen lisäksi mitä turva-auditointi yleisesti vaatii, jokaisen komponentin kohdalla mainitaan, mistä siihen liittyvistä tiedoista täytyy tarpeen vaatiessa voida pitää kirjaa. Tämä vaatimus esitetään kolmella tasolla: minimaalinen, perustaso ja yksityiskohtainen.

Vakuuttavuuden jaottelussa kaikki tietyn ryhmän komponentit muodostavan hierarkkian vaativuutensa suhteen (useat toiminnalliset komponentit ovat rinnakkaisia):

konfiguraation hallinta: automatisointi (2), kyvykkyys (5), laajuus (3).
järjestelmän toimitus ja toiminta: toimitus ja jakelu (3), asennus, generointi ja aloitus (2).
kehitystyö: turvapolitiikan mallintaminen (3), toiminnallinen spesifikaatio (4), korkean tason suunnittelu (5), matalan tason suunnittelu (3), toteutuksen esitys (3), turvamekanismien sisäiset ominaisuudet (3: modulaarisuus ja kerroksellisuus, kompleksisuuden vähentäminen ja sen minimointi), esitysten keskinäinen vastaavuus (3),
ohjemateriaali: ylläpitäjälle (1), käyttäjälle (1).
elinkaaren tuki: kehitysympäristön (fyysinen, henkilöstö-, menetelmä-, …) turvallisuus (2), vikojen korjaaminen (3), elinkaaren määrittely (3), työkalut ja tekniikat (ohjelmointikielistä ja kirjastoista alkaen … ) (3).
testit: kattavuus (3), syvyys eli yksityiskohtaisuus (3), toiminnallinen testaus - miten tehdään ja miten osoitetaan tulokset (2), riippumaton testaus arvioijan toimesta (3).
haavoittuvuuden arviointi: piilokanavien analyysi (3), havaitsematta jäävän väärinkäytön torjunta (3), turvamekanismien vahvuus suoran hyökkäyksen kannalta (1), haavoittuvuusanalyysi (4).

Valituista komponenteista (jotka yhdessä muodostavat ns. paketin, 'package') kootaan suojaprofiili (protection profile) yhdistämällä niihin jokin seuraavista arvioinnin vakuuttavuustasoista (evaluation assurance levels):

EAL1: toiminnallisesti testattu;
EAL2: rakenteellisesti testattu;
EAL3: metodologisesti testattu ja tarkastettu;
EAL4: metodologisesti suunniteltu, testattu ja referoitu (reviewed);
EAL5: puolimuodollisesti (semiformally) suunniteltu ja testattu;
EAL6: puolimuodollisesti verifioitu suunnitelma ja testattu;
EAL7: muodollisesti verifioitu suunnitelma ja testattu.

Nämä tasojen nimet ovat kuvaavia, mutta kuten edellä jo todettiin, vakuuttavuustasot on varsinaisesti määritelty tiettyinä komponenteista koostuvina paketteina. Puolimuodollinen tarkoittaa, että asia on ilmaistu kielellä, jolla on rajattu syntaksi ja määritelty semantiikka. Kokomuodollinen tästä tulee, jos taustalla on vielä eksakti matemaattinen käsitteistö.

Suojaprofiili on toteutuksesta riippumaton joukko vaatimuksia ja sen on tarkoitus olla uusiokäytettävissä, ts. sovellettavissa kokonaiseen kategoriaan tuotteita tai järjestelmiä. Profiileja onkin kehitteillä erityyppisille tuotteille, mm. tietokannoille. Kohdejärjestelmä voidaan arvioida suhteessa johonkin olemassaolevaan suojausprofiiliin (jossa siis on ennalta määrätty komponenttipaketti) tai mihin tahansa komponenttipakettiin, johon on liitetty jokin EAL.

Tiettyä kohdejärjestelmää voidaan arvioida myös pelkästään suhteessa sen omaan turvatavoitteeseen ('security target'). Sellainen vastaa rakenteeltaan turvaprofiilia, ja on tyypillisesti tuotteen valmistajan laatima.

Turvaprofiileja ei toistaiseksi ole paljonkaan, mutta niiden laatijoille löytyy jo "haastatteleva" työkalupakki, joka oleellisesti käy läpi kaikki luokat ja tarpeen vaatimat alaluokat, ts. ei juurikaan tuo lisätietoa itse CC:hen verrattuna (Sparta Inc.).

Esimerkkinä turvaprofiilista voi tutustua sovellustason palomuureille matalan riskitason ympäristöissä laadittuun 64-sivuiseen profiililuonnokseen.

Arviointiprosessi: CC:n (tms.) implementointi

Perushavainto: Arviointi on hidasta ja kallista.

Erityisongelma: jos ohjelmisto on joskus saanut luokituksen, pitääkö uuden version tuottamisen tai jonkin turvallisuuteen ehkä liittymättömän bugin paikkaamisen jälkeen arvioida tuote läpikotaisin uudestaan vai voidaanko ottaa huomioon vain muutokset? Miten tiedetään, ettei sinänsä turvalliselta näyttävä muutos heikennä jotain aivan muuta kohtaa järjestelmässä?

RAMP, "Ratings Maintenance Phase" on lähinnä oranssin kirjan mukaisten arviointien päivittämiseen liittyvä ohjelma, jonka tavoitteena on vaivan ja kustannusten säästäminen. Vastuu tästä ei ole erillisillä arviointilaitoksella, vaan niillä tahoilla jotka järjestelmää tai tuotetta kehittävätkin. Myös CC ottaa tämän ongelman huomioon, mutta vastaava hanke sen puitteissa on vasta kehitteillä.

Evaluoinnin suorittaminen ei ole edennyt tietotekniikan markkinoiden tahtiin ja sitä varten NIST ja NSA perustivat NIAP-hankkeen (National Information Assurance Partnership, 1997), jonka tarkoituksena on yhdessä teollisuuden kanssa kehittää arviointimenetelmiä ja edistää niiden käyttöönottoa. Tämä ei ollut ensimmäinen hanke. Aiempia ja yhä jatkuvia, hieman eri näkökulmista lähteviä hankkeita ovat mm. Trusted Product Evaluation Program (TPEP, tähtää korkean tason, eli vähintään EAL5:n mukaiseen vakuuttumiseen) ja Trust Technology Assessment Program (TTAP, tähtää perustason vakuuttumiseen). Kahden CC-version 1 mukaisesti tasolle EAL2 arvioidun palomuurin arviointitiivistelmät: Lucent Managed Firewall Version 3.0 ja Cisco PIX Firewall 520 Version 4.3(1).

LUE: NIST:n tiivis esite CC:stä (kaikkiaan n. 8 sivua, joista historian voi hypätä yli); Suhteuta suojaprofiilin (eli PP:n) sisällön kuvaus kurssilla aiemmin esitettyyn tietoturvan rakentamisen prosessiin, joka oli mukaeltu CC:stä.

Tiedon lähteitä

Tämän kurssin materiaalissa on ollut useita viittauksia tuoreisiin artikkeleihin, joissa on esitelty tietoturvamekanismeja. Useimmat näistä lähteistä ovat vain yleissivistäviä, eivätkä riitä jonkin järjestelmän tietoturvasta vastaavan henkilön, esim. lähiverkon ylläpitäjän, tarpeisiin. Hänen täytyy saada nopeasti tieto, jos joku jossain löytää vastaavanlaisesta järjestelmästä uudenlaisen tietoturva-aukon. Tällöin hän voi paikata sen omassa järjestelmässään, toivottavasti ennen kuin kukaan ehtii käyttää sitä pahaksi. Toisaalta hyökkäyksistä ei pitäisi levittää sellaista tietoa, joka tekee mahdolliseksi uusien yrittäjien toteuttaa samaa tekniikkaa toisiin kohteisiin. Lisäksi yleensä tarvitaan myös tietoa siitä miten uudenlainen hyökkäys voidaan torjua. Usein tämä edellyttää ohjelmiston valmistajan laatimaa korjauspakettia.

Hyökkäyksistä tiedottaminen on siis paitsi tärkeä myös hyvin arkaluontoinen tehtävä. Tietojen pitää olla riittävän yksityiskohtaisia, jotta ei jäisi epäselväksi onko oma järjestelmä haavoittuva, mutta riittävän yleisiä, että niiden perusteella ei voi toteuttaa hyökkäystä. Lisäksi on annettava aikaa, jotta "vastalääke" ehditään kehittää. CERT, Computer Emergency Response Team, toteuttaa tätä periaatetta. Se on hajautettu järjestelmä, jonka koordinaatiokeskus (CERT/CC) on Carnegie-Mellon-yliopistossa, jonne USA:n puolustusministeriö sen perusti vuonna 1988. Suomessa ainoa CERT-ryhmä on vuonna perustettu 1995 Funet CERT. Tietoturvatiimejä on monia muitakin kuin CERTit. Niitä on akateemisia, kaupallisia ja hallitusten valvomia. Forum of Incident Response and Security Teams, FIRST, on monien tällaisten yhteistyöelin.

Hakkerointiin taipuvaisilla yksilöillä ja yhteisöillä on myös omia julkaisuja ja seittisivuja uusista hyökkäyksistä. Vaikka sieltä ei yleensä ole saatavilla paikkausohjeita, näidenkin kanavien seuraaminen saattaa olla hyödyllistä. Yksi tällainen on Bugtraq.

Yksi ongelma hyökkäysten raportoinnissa on se, ettei sitä aina haluta tehdä. Hyökkääjällä harvemmin on intressiä siihen, mutta myös kohteeksi joutunut yritys saattaa mieluummin välttää negatiivista julkisuutta (ja kurssilaskua, joka ei kuitenkaan tutkimusten mukaan ole merkittävä). Toinen seuraus tästä on se, ettei tietorikollisia usein edes yritetä saada vastuuseen teoistaan. Tätäkin varten on kehitelty anonymisoivaa palvelua, jossa FBI toimii luotettuna osapuolena.

LUE: CERTin pääsivua ja sen takana olevia dokumentteja sen verran että tiedä mitä ovat ja miltä näyttävät CERT Advisories, Incident Notes, Vulnerability Notes, Security Improvement Modules.

Vastuu ja tietoturva

Käytännössä ei ole kysymys vain riskien minimoimisesta vaan vastuun siirrosta jonkun toisen harteille - sen perusteella että on itse tehnyt ohjeiden mukaan. Jotta tällainen voisi onnistua, pitää noudattaa seuraavanlaisia periaatteita, jotka ovat artikkelista R.J. Anderson: "Liability and Computer Security: Nine Principles", Computer Security - ESORICS'94, Springer LNCS 875, 1994, 231-245.

Turvajärjestelmä, jonka tarkoituksena on vakuuttaa (toimia todisteena), pitää suunnitella ja sertifioida ottaen huomioon, että sen analysointi tosipaikan tullen tapahtuu vihamielisessä ympäristössä - vastustajan asiantuntijan toimesta.
On varauduttava siihen, että todelliset ongelmat syntyvä sovellussuunnitelman möhläyksistä ja siitä miten järjestelmää käytetään.
Ennenkuin alkaa rakentaa mitään tietoturvajärjestelmää, pitää varmistua siitä, että ymmärtää, mikä sen todellinen tarkoitus on - erityisesti jos tarkoitus poikkeaa mainostetusta.
On ymmärrettävä, miten vastuu siirtyy niissä järjestelmissä, joita rakennetaan tai joiden perustalle rakennetaan.
Saattaa kestää vuosia, ennenkuin uudenaikaisten teknisten todisteiden merkitys oikeudelliselta kannalta vakiintuu, eikä kehitys välttämättä suppene mitään ristiriidatonta kohti.
Tietoturvalainsäädäntö on hyvin altis "arvaamattomien seurauksien laille".
Ei pidä luottaa teknisiin standardeihin, kun tarkoituksena ratkaista oikeudellisia kysymyksiä.
Turvallisuusoletukset ja -tavoitteet tulisi perustaa kunkin sovellusalan teollisuusstandardeihin, ei yleisiin tietojenkäsittelyn käsitteisiin.
Luotettu komponentti tai järjestelmä on sellainen, jonka voi vakuuttaa.

Tietoturvatietämyksen tarpeen arviointi. Kurssin evaluaatio

Nämä ovat keskusteluasioita, eikä niitä ole käsikirjoitettu.