TTKK / J.Koskinen / Tietoturvallisuuden perusteet, 2002

Tietoturvatieto

Sisältö

Tietoturvan arviointi

[1] Common Criteria, CC

[2] CC:n kriteerit

Tiedon lähteitä

Tietoturvan arviointi Motivointia Monet tällä kurssilla esitetyt tietoturvamekanismit ovat hyviä. Jotkut ovat jo periaatteessa vahvempia kuin toiset, mutta kokonaisuus riippuu myös siitä, miten mekanismit on toteutettu ja hallinnoitu ja miten ne toimivat yhteen toistensa kanssa. Tietoturvasuunnitelmaa laadittaessa tutkitaan, millä tasolla tietoturva on ja päätetään millaiseksi se rakennetaan ja millä tavoin. Mistä suunnittelijat tietävät, miten hyviä käytetyt mekanismit oikeasti ovat käytännössä? Toisaalta mistä yritysjohto, asiakas tai jokin muu kiinnostunut taho tietää, että kokonaisuus on hyvä ja toteutuuko tietoturvapolitiikka. Tällaisissa tilanteissa on hyödyksi, jos on olemassa valmiita malleja siitä, millä perusteilla tietoturvaa voidaan arvioida. Sisältöä ja tavoitetta Tämän sivun tarkoituksena on toimia johdantona ja tarjota laajempaa asiayhteyttä Common Criterialle esittelemällä sen taustaa sekä arviointiprosessin luonnetta. Tavoitekysymyksiä ei tästä ole erikseen.

Tietoturvan arviointi

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

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 on mainittu toisaalla. 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.

Arviointiprosessi: Common Criterian tai vastaavan implementointi

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). Näiden puitteissa evaluoiduista tuotteista ja esille tulleista oranssin kirjan luokista saa käsityksen historialistalta. Lista ei ole pitkä, mutta siihen verrattuna CC-lista on huomattavan lyhyt. Sivu on päivitetty 25.4.2000 ja sieltä löytyy kolmen palomuurin arviot (28.8.2002).

Common Criteria Motivointia Common Criteria on melko uusi standardi ja sen mukaisia arvioita saattaa ruveta ilmaantumaan. Sen vuoksi CC:n periaate on hyvä tuntea. Monipolvisen kriteeristön ruodinta ei ehkä olisi perusteltua, jos tavoitteena olisi sisällön sellaisenaan omaksuminen. Tässä sen avulla on mahdollista saada aikaan jonkinlainen kertaus likimain kaikista kurssin aiheista. Yhtä hyvin luetteloita voi katsoa johdattelevana tiivistelmänä. Sisältöä ja tavoitetta Alkupuolella esitellään Common Criterian periaate, jossa kriteerit ensin jaetaan toiminnallisuuteen ja vakuuttavuuteen ja nämä edelleen luokkiin, ryhmiin ja komponentteihin, ja sitten yhdistellään paketeiksi, joista muodostuu (mm.) suojaprofiileja. Lopuksi luetellaan kriteerejä, osittain komponenttien tasolle asti. Tavoitekysymyksinä on neljä aiempaa tenttikysymystä. Kaksi ensimmäistä ovat melko yleisluonteisia, neljäs on varsin yksityiskohtainen. Mihin tarvitaan CC:n (Common Criteria for Information Technology Security Evaluation) kaltaista standardia? Minkä tyyppisiä seikkoja on otettava huomioon jonkin yritykselle hankittavan järjestelmän tai tuotteen tietoturvan arvioinnissa, ja miten jokin Common Criterian kaltainen standardi voi auttaa evaluoinnissa? (Ensimmäisen osan vastaus ei ole oikein, jos siitä muodostuu pitkä luettelo.) Common Criteria-standardissa vakuuttavuuteen vaikuttavat tekijät on jaoteltu seitsemään luokkaan, kukin niistä useisiin ryhmiin ja ryhmät puolestaan komponenteiksi. Valituista komponenteista on pantu kokoon seitsemän erilaista evaluoinnin vakuuttavuustasoa EAL 1 - EAL 7 (evaluation assurance levels). (a) Selitä ensin yleisesti, mitä vakuuttavuus tässä oikeastaan tarkoittaa? (b) Millaisia ne vakuuttavuuteen vaikuttavat tekijät sitten ovat? Mainitsitpa sitten komponentteja, ryhmiä tai luokkia, ainakin kolmeen luokkaan kuuluvia asioita pitäisi tulla esille, pienen selityksen kera. (c) Kuten a- ja b-kohdan vastauksistasi varmaan käy ilmi, vaativakaan EAL-paketti ei sellaisenaan riitä tietoturvan kriteeriksi. Mitä muita palasia standardi tarjoaa tietoturvan arvioimiseksi? (d) Mitä tekemistä vakuuttavuudella tai yleensä arvioidulla tietoturvalla voisi olla vakuutettavuuden kanssa (siis sen kanssa mitä vakuutusyhtiöt tarjoavat)? Common Criteriassa (CC for Information Technology Security Evaluation) vakuuttavuuteen vaikuttavat tekijät jaotellaan seuraaviin luokkiin: konfiguraation hallinta -- järjestelmän toimitus ja toiminta -- kehitystyö -- ohjemateriaali -- elinkaaren tuki -- testit -- haavoittuvuuden arviointi. Näistä ainoastaan viimeinen näyttäisi nimensä puolesta liittyvän turvallisuuteen. Miten muiden kuuden sisältämät komponentit sitten edistävät vakuuttumista eli antavat perusteita luottaa siihen että evaluoinnin kohteena oleva tuote tai järjestelmä täyttää sille asetetut tietoturvatavoitteet? (Selitä jokaisesta ainakin yksi asia.)

Common Criteria

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 (package). Ne muodostavat hierarkian, jonka tarkoitus (toisesta tasosta alkaen) on tarjota osittaista vastaavuutta aiempiin malleihin nähden, erityisesti oranssin kirjan luokkiin (siis C1, C2, B1, B2, B3 ja A1) verrattuna. Arvioinnin vakuuttavuustasot eli EAL-paketit (evaluation assurance levels) ovat:

• 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.

Valituista toiminnallisista komponenteista (jotka nekin yhdessä muodostavat ns. paketin, 'package') kootaan suojaprofiili (protection profile) yhdistämällä niihin jokin EAL-paketti. 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 suojaprofiilia, ja on tyypillisesti tuotteen valmistajan laatima.

Suojaprofiileja 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ä suojaprofiilista voi tutustua sovellustason palomuureille matalan riskitason ympäristöissä laadittuun 64-sivuiseen profiililuonnokseen.

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 erikseen esitettyyn tietoturvan rakentamisen prosessiin, joka on mukaeltu CC:stä.

Toiminnallisuuden ja vakuuttavuuden luokat, ryhmät, komponentit

Toiminnallisuus

• turva-auditointi eli tapahtumakirjanpito: auditoitavien tapahtumien valinta (1), tietojen keruu (2), tallennus (4), (automaattinen) analyysi (4), automaattinen reagointi (1), tietojen tarkastelu (ihmisen toimesta) (3).
• kryptografinen 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 mm. Bell-LaPadula-mallissa toisaalla)), 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 prosessin 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ä luokassa "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).

Vakuuttavuus

1. konfiguraation hallinta: automatisointi (2), kyvykkyys (5), laajuus (3).
2. järjestelmän toimitus ja toiminta: toimitus ja jakelu (3), asennus, generointi ja aloitus (2).
3. 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),
4. ohjemateriaali: ylläpitäjälle (1), käyttäjälle (1).
5. 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).
6. testit: kattavuus (3), syvyys eli yksityiskohtaisuus (3), toiminnallinen testaus - miten tehdään ja miten osoitetaan tulokset (2), riippumaton testaus arvioijan toimesta (3).
7. 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).

Tiedon lähteitä Motivointia Aina ei tarvitse tietää itse asiaa, varsinkin jos se muuttuu koko ajan tai ei ole kaikkein tarpeellisinta. Voi riittää tuntea sen teoria, mutta erityisesti on syytä tietää, mistä tarkempaa tietoa saa. Tämä pätee tietenkin myös tietoturvan alalla, mutta tällä alalla on toinenkin tiedon lähteiden merkitys: tietämättömyys koko ajan keksittävistä uudenlaisista hyökkäyksistä ei välttämättä ole häpeäksi edes tämän kurssin laatijalle. Se voi toki olla sivistymättömyyttä, mutta tietynlaisista asioista vastuussa oleville se voi olla tuhoisaa. Sisältöä ja tavoitetta Millainen merkitys tietoturvan kentässä on CERT:n (Computer Emergency Response Team) kaltaisilla järjestöillä?

Tiedon lähteitä

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 on kaksi CERT-ryhmää, Funet CERT (1995-) ja Viestintävirastossa toimiva CERT-FI (2002-). 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 ollut Buqtraq, jonka arkisto nykyään löytyy virallisemmasta osoitteesta www.securityfocus.com/. 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ät mitä ovat ja miltä näyttävät CERT Advisories, Incident Notes, Vulnerability Notes, Security Improvement Modules.