TTKK / Tietoliikenne / J.Koskinen : Tietoturvallisuuden perusteet
2. viikko, ma 6.9.1999
Tietoturvauhkien jäsentelyä
Tutustutaan lyhyesti saksalaisen
tietoturvakäsikirjan uhkaluetteloon, joka on jaoteltu seuraaviin osiin
(suluissa on uhkien määrä)
Nämä luettelot ovat sellaisinaan liian pitkiä, jotta niistä olisi paljon
hyötyä lukijalle. Käsikirja tuokin uhkat esille useassa
eri yhteydessä, jotka jaottelevat tietojenkäsittelyn kenttää:
Keskeisiä osia ovat
- infrastruktuuri (lähinnä fyysinen)
- erilliset ja asiakkaan asemassa olevat laitteet
- tietoliikennejärjestelmät
- verkot ja palvelimet
Näiden osa-alueiden sisällä jaottelu tarkentuu ja tuo esille myös
nimettyjä järjestelmiä (Unix, MS-Windows ja Novell). Lisäksi on joitakin
osa-alueita, joissa vastaavaa tarkempaa jakoa ei tehdä, tärkeimpinä organisaatio
ja henkilöstö.
Osa-alueittaiset uhkalistat eivät enää olekaan toisensa poissulkevia. Esimerkiksi
hallinnollinen puute "Lack of evaluation of protocol data" esiintyy useassa
kohdassa, mm. "Monen käyttäjän DOS-PC" ja "Heterogeeninen verkko". Toisaalta
osa-alueiden uhkaesittelyt ovat vain tyypillisiä skenaarioita, eikä mainittu uhka
esiinny kaikissa kohdissa, joissa voisi. Pitäisihän esimerkkinä oleva
protokollatieto (eli yleisemmin auditointitieto tai tapahtumalogi) tutkia kaikissa
järjestelmissä, joihin ulkopuolinen tai asiaton voi tunkeutua ja joissa tämä
voitaisiin havaita kerätyn tiedon perusteella.
Taksonomia on sellainen luokittelu, joka jakaa koko kentän toisensa
poissulkeviin luokkiin. Tällaista luokittelua voidaan käyttää vaikkapa
toteutuneiden tietoturvauhkia tilastointiin, jolloin niiden esiintymisen
tiheydestä voidaan tehdä johtopäätöksiä esim. uhkien todennäköisyyksistä. Tätä
tietoa taas voidaan soveltaa riskianalyysin kautta tietoturvasuunnitteluun. Näitä
asioita käsitellään tämän kerran jälkipuoliskolla.
Hyökkäysten taksonomia
John D. Howard esittää väitöskirjasssaan
:
An Analysis of Security Incidents on the Internet 1989-1995
määritelmän tietoturvalle:
"Computer security is preventing attackers from achieving objectives
through unauthorized access or unauthorized use of computers and networks."
Sen pohjalta hän tiivistää
(luvussa 6)
alla olevaan taulukkoon taksonomian, jossa
tietokoneeseen tai verkkoon hyökkäävä voidaan luokitella ensimmäisen
sarakkeen mukaisesti ja tavoite (motivaatio), johon hän tähtää, on jokin
viimeisessä sarakkeessa mainituista. Tavoitteeseen päästään jonkin
tietoon liittyvän tuloksen kautta.
Tulos muodostuu siitä, että jollain välineellä pääsee käsiksi tietoon.
Pääsy on jaoteltu neljään vaiheeseen.
Ideana on siis, että erilaisia hyökkäyksiä voidaan mallintaa
valitsemalla kustakin sarakkeesta yksi (tai usea) vaihtoehto.
Attackers |
|
Tools |
|
----------------- Access ----------------- |
|
Results |
|
Objectives |
Hackers |
|
User Command |
|
Implementation Vulnerability |
|
Unauthorized Access |
|
Files |
|
Corruption of Information |
|
Challenge, Status |
Spies |
==> |
Script or Program |
==> |
Design Vulnerability |
=> |
Unauthorized Use |
=> |
Processes |
=> |
Data in Transit |
==> |
Disclosure of Information |
==> |
Political Gain |
Terrorists |
|
Autonomous Agent |
|
Configuration Vulnerability |
|
Theft of Service |
|
Financial Gain |
Corporate Raiders |
|
Toolkit |
|
Denial-of-service |
|
Damage |
Professional Criminals |
|
Distributed Tool |
|
|
Vandals |
|
Data Tap |
|
|
Muita taksonomioita
Howard referoi joitakin muita taksonomioita, mm. sitä joka on esitetty
artikkelissa Landwehr C.E., Bull A.R., McDermott J.P., Choi W.S.:
A taxonomy of computer program security flaws.
ACM Computing Surveys, Vol.26, No. 3 (Sept. 1994), pp. 211-254. Tässä on
katkelma tämän artikkelin tiivistelmästä
: "An organized record of actual flaws can be useful to computer system
designers, programmers, analysts, administrators, and users. This
survey provides a taxonomy for computer program security flaws, with
an Appendix that documents 50 actual security flaws."
Aihetta on käsitelty myös diplomityön tasolla: Taimur Aslamin MS-thesis vuodelta 1995:
A Taxonomy of Security Faults in the Unix Operating System
(ks. erityisesti sivu 39). Lyhyempi
versio samasta aiheesta (vuodelta 1996, 10 sivua).
LUE: Tutustu (lyhyesti) em. saksalaisen käsikirjan luetteloihin
suojakeinoista:
Nämä on käytännön työn kannalta esitelty tietojenkäsittelyn
osa-alueiden yhteydessä vastaavalla tavalla kuin uhkatkin.
Pohdi, voisiko tätä jäsennystä tehostaa tai jopa "taksonomisoida" jollain yhtä
yleisellä tavalla kuin em. Howardin taksonomia.
Hallinnollinen näkökulma
Tietoturvan rakentamisen prosessi
Aiemmin oli jo esillä perusmalli tietoturvatyölle, eli karkeasti ottaen vaiheet:
uhka-analyysi --> turvapolitiikka --> turvamekanismit. Garfinkelin
ja Spaffordin kirjassa vaihejaottelu on tällainen: suunnittelu - riskien arviointi
- kustannus-hyöty-analyysi - politiikkojen luominen - implementointi - tarkkailu
(auditointi) ja ongelmiin puuttuminen.
Common
Criteria-standardi ("CC", jonka varsinaisesta olemuksesta myöhemmin) esittää
yhdeksi mahdolliseksi malliksi seuraavan tarkennetun vaiheistuksen ja tasojaon
tietojärjestelmän "T" (tai tuotteen, tms.) turvallisuutta työstettäessä.
Lähtökohdat:
- Mikä on T:n tarkoitus ja tavoite;
- Millainen on T:n fyysinen ympäristö;
- Mitä on T:n arvokas sisältö, arvoasiat ('assets'), joka vaatii suojaamista.
Näiden perusteella määritellään turvallisuusympäristö, jolla on osina:
- Oletukset, jotka ympäristölle voidaan asettaa ja joita ei tarvitse enempää
kyseenalaistaa ;
- Uhkat, jotka yksilöidään esittämällä uhkaaja, oletettu hyökkäysmenetelmä ja
sen pohjana oleva heikkous ja mitä sisältöä uhka koskee.Riskianalyysi
varustaa
lisäksi jokaisen uhkan todennäköisyydellä, jolla hyökkäys toteutuu ja onnistuu
sekä arviolla vahingon suuruudesta.
- Organisaation turvapolitiikka, eli sääntökokoelma siitä mikä on sallittua ja
mikä ei.
Näiden perusteella asetetaan turvatavoitteet. Näiden tarkan
olemuksen CC-ehdotus jättää varsin hämäräksi. Seuraavana vaiheena
tavoitteita hienontamalla saadaan aikaan turvavaatimukset, jotka koskevat
sekä T:tä että sen ympäristöä. Jos vaatimukset täyttyvät, niin silloin T:n on
mahdollista saavuttaa turvatavoitteetkin.
Turvavaatimukset, jotka koskevat T:tä ovat kahdenlaisia:
- toiminnalliset, jotka määräävät turvallisuutta edistävän käyttäytymisen, ja
- vakuuttavuutta edistävät.
Edellisiä koskee standardin osa 2 ja jälkimmäisiä osa 3. Näiden
vaatimusten perusteella muodostuu T:n turvaspesifikaatio ja viimein myös
toteutus.
Riskianalyysi
Riskillä tarkoitetaan toisiinsa yhdistettynä mahdollisen vahingon vakavuutta ja
todennäköisyyttä (usein mallina käytetään näiden kahden tuloa).
Valtionhallinnon tietoturvallisuuskäsitteistön mukaan
riskianalyysi = "Etukäteen laadittujen suunnitelmien ja täsmällisten menetelmien
mukaisesti tehtävä uhkien sekä niiden toteutumisen todennäköisyyksien ja
aiheuttaman vahingon suuruuden selvitys ja analysointi. Usein synonyymi
käsitteille uhka-analyysi ja haavoittuvuustutkimus."
Kun mukaan otetaan vahinkojen aiheuttamien kustannusten minimointi
(suojautumisen hintaa unohtamatta), puhutaan riskien hallinnasta ('risk
management'). Tosiasiahan on, että eliminointi ei tule kysymykseen.
Riskianalyysi suoritetaan, jotta saataisiin jokin pohja päätöksille siitä, mitkä
suojautumismenettelyt ovat taloudellisesti järkeviä. Nykyiset riskianalyysin
menetelmät ovat karkeita, mutta parempia kuin ei mitään. Epätarkkuudesta ja
epätieteellisyydestä huolimatta riskianalyysia ei kannata jättää käyttämättä
hyväksi (siis varsinkaan hyllyttämällä jo tehty analyysi), jos kohta pitää myös
varoa väärää täsmällisyyden tunnetta.
Riskianalyysi etenee kutakuinkin seuraavasti:
- kartoitetaan, mikä on arvokasta ('assets').
- kartoitetaan uhkat näitä arvoja kohtaan, esimerkiksi
skenaarioittain, "mitä voisi tapahtua", ja laatimalla hierarkkinen
jaottelu esimerkiksi rakentamalla vaiheittain "uhkapuu", jossa kunkin solmun
edustama yleisempi uhka jakautuu yksityiskohtaisemmin määriteltyihin uhkiin (myös
AND-tyyppistä jakautumista voi esiintyä). Amoroson kirja käsittelee uhkapuita
pitkälti, mutta menetelmä ei ole yleinen (vrt. A.J.Korhosen
tiivis esitys
aiheesta.) Oleellista on saada kaikki mahdollisuudet katetuiksi.
- kutakin uhkaa kohti - esim. tietyn (lajin) luottamuksellisen tiedon
paljastuminen - arvioidaan, minkä suuruinen menetys siitä koituisi.
Kustannukset arvioidaan kuten yleensä vahingoissa: jälleenhankinta, työ, hukattu
aika, kulut, muut arvot (esim. maineen heikkenemisen vaikutus liiketoiminnalle).
- arvioidaan todennäköisyys, jolla kukin tapaus voisi sattua;
tuloksena esimerkiksi odotusarvo, montako kertaa vuodessa.
- arvioidaan suojautumismenetelmien hinta sekä tehokkuus, jolla ne torjuvat
uhan. Tässä vaiheessa pitää siis viimeistään myös tuntea menetelmät eikä vain
kohdejärjestelmää, jota puolestaan eivät turva-asiantuntijat yleensä hallitse
ilman käyttäjien mukanaoloa.
- tehdään laskelmat ja vertailu;
vuotuinen tappio uhkien vuoksi, suojautumisen aiheuttamat kustannukset ja sen
tuottama säästö (odotusarvot).
Arvoasioiden tunnistaminen on näistä helpointa eikä sekään ole aina helppoa.
Laskentaa voidaan toki automatisoida ja jonkin verran aiempiakin vaiheita, ainakin
siltä osin kuin niihin muodostuu rakenteisuutta (esim. juuri uhkapuun
muodossa).
Sen lisäksi että saadaan perustelu kustannuksille, saavutetaan parempi tietoisuus
tarkastelun kohteena olleista aiheista. Tällä on yleensä myönteistä vaikutusta
(myös) turvallisuuteen.
Harjoitus: (1) Ajattele, millaista omaisuutta, aineellista tai aineetonta,
yrityksellä voi olla. Keksi jotakin, joka on arvokasta (ei kannata luovuttaa pois)
mutta ei ole sitä tietoturvan kannalta. (2) Mikä taas tuntuu vähäarvoiselta, mutta
tietoturvan kannalta onkin otettava huomioon. (3) Mitä muuta tietojärjestelmä
tarvitsee kuin laitteet, ohjelmat ja käsiteltävän/talletettavan/siirrettävän
tiedon?
(1) Esim. toimitilojen sijainti, LVI-laitteet, hyvä siivoushenkilöstö, ...,
tyypillisesti kai infrastruktuuri ja sellaiset asiat joita ei voi helposti edes
menettää tai joista jo perinteisesti pitää huolta jokin muu taho kuin
tietoturva-ammattilainen. (2) käytöstä poistetut tietokoneet, vanhat sisäiset
puhelinluettelot, roskiksen sisältö, ... (3) ihmiset, dokumentaatio,
materiaalit, tarvikkeet, ...
James W. Meritt: Risk Management
käsittelee hieman myös riskin numeerista arviointia (artikkeli ICSA:n
sivuilla).
Riskianalyysi tuottaa turvasuunnitelman, jota myöhemmät analyysit
päivittävät ja laajentavat. Turvasuunnitelman ensimmäinen osa muodostuu
turvapolitiikasta ja muut osat siitä, miten politiikka toteutetaan.
Tutustutaan ensin politiikan olemukseen ja katsotaan suunnitelmaa
tarkemmin sen jälkeen.
Tietoturvapolitiikka
Tietoturvapolitiikka on keskeinen käsite. Edellä nähtiin millaisen prosessin
tuloksena sellainen voidaan laatia. Seuraavaksi määritellään hieman sitä itseään
ja otetaan esille myös tietoturvamallin käsite.
Edellä mainitun käsitteistön
mukaan tietoturva[llisuus]politiikka =
"Niiden päätösten kokonaisuus, joilla vaikutetaan tietoturvallisuuden
muodostumiseen ja kehitykseen. Organisaation valitsema
tietoturvallisuuperiaatteiden soveltamistapa. Organisaation johdon hyväksymä
periaatteellinen näkemys turvallisuuskäytännöistä, jotka toiminnot huomioivat
päivittäisissä rutiineissa."
Hieman konkreettisemmin: tietoturvapolitiikka on tietoturvallisuutta koskevien
päätösten dokumentaatio, joka pohjimmiltaan määrittelee, kenellä on oikeus, mihin
resursseihin, miten pääsyä säännellään, kenellä on siitä vastuu ja mihin toimiin
ryhdytään, jos todetaan rikkomuksia.
Politiikkoja on monentasoisia. NIST-käsikirja (An Introduction to Computer
Security) esittelee seuraavat tasot ja korostaa että jaottelu on lukijan
ymmäryksen edistämiseksi, ei tarkkojen rajojen vetämiseksi:
- ohjelmapolitiikka (program policy) tai tietoturvastrategia:
organisaation tavoitteet tietoturvan suhteen, yleiset vastuukysymykset. Politiikan
olisi myös syytä tuoda esille organisaation sitoutuminen tietoturvaan.
- asiakohtainen politiikka, (issue-specific), esimerkkeinä
aihealueista Internet-yhteys (keille, missä asioissa, miten
autentikoituna, ...), sähköpostin yksityisyyskysymykset (organisaation
sisällä) tai epävirallisten ohjelmistojen käyttö.
- järjestelmäkohtainen politiikka, järjestelmänä esim. jokin
tietokoneverkko kuten Lintula.
Politiikka koostuu turvatavoitteista (vrt. CC:n ehdottama prosessi) ja
toiminnallisista turvasäännöistä. Esimerkkitavoitteista voisi olla,
että palkkatietoja saa käsitellä vain kirjanpidon ja henkilöstöhallinnon väki,
jolloin vastaavat säännöt voisivat olla, mitä palkkatietojen kenttiä kukin näiden
osastojen henkilö saa muokata, ja lisäksi se ettei kukaan saa muokata omia
tietojaan. Tällä tasolla toteutus tapahtuukin tyypillisesti
pääsynvalvontasääntöjen perusteella. Niiden täydennyksenä voidaan esittää
ohjeistoja ja työntekijöiden omaksuttavaksi tarkoitettuja menettelyjä.
Alimmalla tasolla politiikka alkaa olla hyvin yksityiskohtainen ja
vaikeaselkoinen. Sitä varten olisi hyvä, jos se ilmaistaan jollain
täsmällisellä, ehkä jopa muodollisella kielellä.
Turvamalleista voi olla hyötyä tässä. Mallin ja politiikan ero
ei tosin yleensä ole kovin selvä (eri lähteissä on erilaisia
painotuksia). Mallilla tarkoitetaan järjestelmien arbstraktia
kuvausta, joka saa alkunsa käytännön tapauksista ja toisaalta voi
vaikuttaa omien lainalaisuuksiensa ja ilmaisuvoimansa kautta siihen,
miten käytäntöä kannattaa työstää - huono malli voi olla toki
kahlitsevakin. Hyvillä malleilla voidaan saavuttaa vastaavaa hyöty
kuin käsitteellisellä ajattelulla yleensäkin. Malleista jatketaan
ensi kerralla. Mainittakoon nyt vain esimerkkinä politiikan ja mallin
erosta, että luonnollisen kielen kielioppia voidaan pitää mallina
kielessä esiintyville ilmiöille. Politiikkana voisi olla esim.
kokoelma oikeakielisyysohjeita, mutta luetteloa voidaan tiivistää
huomattavasti kuvaamalla ohjeet kieliopin avulla.
Tietoturvasuunnitelman laatiminen
Tietoturvasuunnitelma on tavallaan laajennettu ja konkretisoitu yksityiskohtaisen
tason tietoturvapolitiikka. Politiikkadokumentin lisäksi siihen
kuuluu:
- nykytila, eli suunnitelman laadinta-ajankohtana vallinneen
turvallisuuden kuvaus. Se saadaan esim. riskianalyysin pohjalta. Se
sisältää erityisesti arvoasiat, arvioidut uhat ja (prosessin tässä vaiheessa)
asennetut turvamekanismit.
- suositukset ja vaatimukset politiikassa asetettujen tavoitteiden
saavuttamiseksi; ne ottavat huomioon myös laajennettavuuden - tilanteet,
joissa huomataan uusi aukko, tai uusi data/ohjelma/laite tuo sellaisen tullessaan.
- suunniteltujen toimien aikataulu, varsinkin mikäli suojamekanismeja ei
asenneta kaikkia samalla kertaa. Myös koulutukseen voidaan tarvita aikaa.
- suunnitelmat ajoittaisista tarkistuksista ja päivityksistä, milloin tehdään
(eli tavallaan osa aikataulua). Uudelleenarviointi (sen lisäksi mitä edellä
sanottiin suosituksista) on tärkeää, koska käyttäjät vaihtuvat, toiminnot
muuttuvat tai laajenevat, järjestelmän tietojen luonne muuttuu,
hyökkäyksiä keksitään uusia,...
Suunnitelmaan pitäisi sisällyttää myös valmiussuunnittelu eli varautuminen
katastrofeihin (sisältäen mm. harjoittelun).
Yhteenvetoa
Jos politiikalla kuvataan päätökset siitä, kuka saa tehdä mitäkin ja
millaista tietoturvaa tavoitellaan, niin suunnitelma esittää, miten politiikka
toteutetaan, ja välineitä politiikan implementointiin ovat
- organisaation standardit,
- ohjeistot ('guidelines'),
- mekanismit, eli työkalut ja varusteet, jotka asennetaan suunnitelman
mukaisesti, sekä
- proseduurit eli menettelyt, jotka käyttäjät omaksuvat osaksi omaa
työtään.
Miten hyvin tämä kaikki toimii, vaatii arviointia ja siihen palataan ensi kerralla
kriteerimallien yhteydessä ja vielä myöhemmin näiden mallien tarkemman esittelyn
yhteydessä. Edellä mainittu CC eli Common Criteria on tällainen malli.